[Gelöst] Windows (Legacy vs. UEFI), OCLP/macOS und Boot-Probleme auf dem Mac

wie vermutet. Du hast keine entsprechende Konfiguration mit OCLP und Legacy-Windows .
Nicht ganz richtig vermutet, denn auf dem 3.1 ist schon länger eine Win-Legacy-Installation vorhanden und zwischenzeitlich hatte ich vor dem 5.1 auch dort mit OCLP (aber nicht dauerhaft) experimentiert.
Und ich habe halt nicht noch zusätzliche Win-Abteilungen wie Du, da ich meine Datenablage anders organisiere..
Bzgl. OCLP reicht der 5.1 doch - 3.1 & 2.1 brauchen nicht auch OCLP-abhängige macOS. Dosdude & seine Vorgänger wie MLPF, Pike etc. reichen doch da, um die OS X-/macOS-Limitierung zu überwinden. ;)
Von der Lizenz von Windows10, die mit der Hardware des Rechners verbandelt ist, auf dem es installiert und aktiviert wurde.
Der Vorgang ist mir bekannt.
Da aber immer auf allen Kisten - ob Mac oder Hackintosh oder reiner PC - immer seit Jahren ein WinOS vorhanden war, war es wurscht, wenn ich WinOS neu installiere (gerade vorgestern beim 3.1 erneut gemacht), weil die ganzen Kisten MS bekannt sind und automatisch digital aktiviert werden.

War sogar kürzlich bei einer Win10-Installation, der ein Win11 vorangegangen war (digital aktiviert) und das wiederum hatte ein Win10 als Vorgänger und das dann Win8.1, Win7 etc. etc.
Ich musste mich da nicht drum kümmern und habe auch bislang nichts "zerschossen". ;)

Sonst wirds verwirrend wenn man das vermischt
Ganz wichtig - Ähnliches passiert z. Bsp. auch, wenn um die Unterscheidung von Sata- & NVMe-SSD geht. Alles redet von SSD, womit man, wenn beides möglich ist, als Leser nie genau weiß, was Derjenige meint.
 
Und ich habe halt nicht noch zusätzliche Win-Abteilungen wie Du, da ich meine Datenablage anders organisiere..
Bei nur einer Partition C: gibt es trotzdem noch eine weitere.
Die müsste dann eigentlich auch bei Dir im OpenCore BootMenü auftauchen ...
Windows Partitionen.png

Da aber immer auf allen Kisten - ob Mac oder Hackintosh oder reiner PC - immer seit Jahren ein WinOS vorhanden war, war es wurscht, wenn ich WinOS neu installiere (gerade vorgestern beim 3.1 erneut gemacht), weil die ganzen Kisten MS bekannt sind und automatisch digital aktiviert werden.
War sogar kürzlich bei einer Win10-Installation, der ein Win11 vorangegangen war (digital aktiviert) und das wiederum hatte ein Win10 als Vorgänger und das dann Win8.1, Win7 etc. etc.
Ich musste mich da nicht drum kümmern und habe auch bislang nichts "zerschossen". ;)
Na, dann bist Du ja ein Sonntagskind. :cake:
Aber es lesen vllt andere hier mit, die unter Umständen Schiffbruch beim "Rumwechseln" von Windows-Festplatten erleiden ...
 
die unter Umständen Schiffbruch beim "Rumwechseln" von Windows-Festplatten erleiden
Und wie sieht so ein "Schiffbruch" aus?
Maximal wird Win10/11 am neuen Standort (weil erkennbar völlig andere/neue HW) nicht aktiviert. Dann steckt man die Platte wieder in die vorherige Kiste. ;)
 
Bei nur einer Partition C: gibt es trotzdem noch eine weitere
Nein - eine weitere gibt es hier nicht.

Ich habe die vorgestrige Win-Installation für den MP3.1 mal in den MP5.1 eingehängt (wurde auch im 5.1 mit einer digitalen Lizenz aktiviert) und das stellt sich in der Datenträgerverwaltung so dar:

Datenträgerverwaltung-01.jpg


Platte 0 ist erkennbar Windows, Platte 1 macOS, Platte 2 der OCLP-Stick.

Der Boot schaut so aus: zuerst ALT und dann nach OCLP...Das mittlere Icon ist der Stick.

OCLP-Boot-01.jpg


OCLP-Boot-02.jpg


Wie zu sehen nur ein Windows (legacy)
 
Und wie sieht so ein "Schiffbruch" aus?
Maximal wird Win10/11 am neuen Standort (weil erkennbar völlig andere/neue HW) nicht aktiviert. Dann steckt man die Platte wieder in die vorherige Kiste. ;)
Hmm, wenn ich mich nicht irre, war in so einer Situation die Aktivierung auch für die alte Hardware deaktiviert.
Musste dann nochmal den Weg über Win7Pro & Win10Pro-Upgrade gehen, um nochmal die Aktivierung zu erreichen.

Aber egal - hatte damals/habe noch immer keine Lust auf irgendwelche weitere Experiemente, um das nochmal zu überprüfen,
weil der grösste Teil der Win10Pro aus einem Win7/8 Upgrade stammen und ich froh bin, dass die im Netzwerk klaglos laufen.
Zumindest bis zur Abkündigung von Win10 zu Ende 2025.

Überlasse Dir das Feld für weitere Spitzfindigkeiten zum Thema "zerschiessen", "Schiffbruch" etc.
 
weil der grösste Teil der Win10Pro aus einem Win7/8 Upgrade stammen
So hat sich das auch bei mir und sicher unzähligen anderen Win-Nutzern ergeben.
Und das, was ich oben schrieb, sind doch keine Spitzfindigkeiten, sondern ich erzähle nur wie Du auch, wie es sich bei mir zugetragen hat. Eben auch, weil vielleicht Andere hier mitlesen. ;)
 
Nein - eine weitere [Edit: "System-reserviert"-Partition] gibt es hier nicht.
Ich habe die vorgestrige Win-Installation für den MP3.1 mal in den MP5.1 eingehängt (wurde auch im 5.1 mit einer digitalen Lizenz aktiviert) und das stellt sich in der Datenträgerverwaltung so dar:
Platte 0 ist erkennbar Windows, Platte 1 macOS, Platte 2 der OCLP-Stick.
Der Boot schaut so aus: zuerst ALT und dann nach OCLP...Das mittlere Icon ist der Stick.
Wie zu sehen nur ein Windows (legacy)
Äpfel und Birnen ...
Du hast Win11 und ich ein Win7pro-nach-Win10pro-Upgrade. Und das läuft jetzt auch (wieder).
Muss eben direkt über den Apple-BootPicker gestartet werden und nicht, nachdem OCLP-BootMenü gestartet wurde.
Kannst Du Windows(Legacy) auch aus dem OCLP-BootMenü zuverlässig/reproduzierbar starten?

Warum das beim ersten Lauf nach OCLP-Installation nicht ging, ist mir schleierhaft und letztendlich jetzt auch wurscht.

Bin aber interessiert daran, wie Win11 bei Dir läuft, weil das ggf. Ende 2025 bei mir relevant sein könnte ...
 
Zuletzt bearbeitet:
Dann wird die vermutlich im MBR-Modus installiert sein. Vermutlich ist OC so schlau und identifiziert anhand Partitionierung oder der Startdateien, wenn ein Windows mittels MBR gestartet ("legacy") wird.

In der Datenträgerverwaltung in Windows (ab Vista möglich) kann man relativ leicht feststellen, nach welchem Schema das Laufwerk initialisiert wurde und welcher Startmodus (MBR oder UEFI) aktiv ist, selbst wenn die Partitionierung nicht dem üblichen Stand entspricht.

Eine EFI-Systempartition (enthält den/die Urlader) muss FAT32-formatiert sein, das ist übergreifend für alle Betriebssysteme, weil man sich darauf so geeinigt hat.
Das Volume 0 aus Beitrag #24 (Win11-MP3.1) wird ganz eindeutig per MBR gebootet, auch wenn es etwas speziell ist, dass es nur eine einzelne Partition ist. Die Startdateien befinden sich darauf ("System"), es ist NTFS-formatiert, Schlussfolgerung: wenn es das einzige Laufwerk ist und sich selbst starten muss, geht nur MBR.
Es könnte aber trotzdem problemlos im UEFI-Betriebsmodus gestartet werden, wenn man den Urlader auf einem anderen Laufwerk hätte (das seinerseits GUID-Schema voraussetzt und eine ESP hat) und man die Startdateien austauscht.
 
Du hast Win11 und ich ein Win7pro-nach-Win10pro-Upgrade.
Nix Äpfel & Birnen, sondern Win & Win. ;)
Denn Win 7, 8.1, 10 & 11 haben den gleichen Stamm.
Äpfel & Birnen gehören zwar zur Obergruppe Obst, haben aber einen ganz anderen Ursprung - eher vergleichbar mit macOS & WinOS: beides zwar Betriebssysteme, aber verschiedener Herkunft.

Mein mit Win11-MP3.1 bezeichnetes WinOS ist noch ein Win10, denn ich habe Win10 von der DVD installiert (merke MBR), habe aber noch nicht mit dem Win11-Stick aus laufendem Win10 heraus nachgelegt.

Im Übrigen sind alle meine rundum verteilten Win11 aus Win7 entstanden - damals gab es die vergünstigten Upgrades von Win7 auf das unsägliche Win8 , dann kam das richtig gute Win8.1 usw.

Du bist aber heute doch auf dem Weg zu Deinem Win10 nicht über eine Win7-DVD mit nachfolgenden Upgrade gegangen, weil Du den Ursprung so betonst, sondern hast direkt eine aktuelle Win10-Iso auf DVD gebrannt und damit installiert. Oder doch nicht?
Ich vermute doch, Du sprichst jetzt nicht mehr von der Installation, sondern jetzt von der Aktivierung.
Auch da habe ich eine nachvollziehbare Historie meiner Produkt-Keys bei den diversen Geräten angelegt, um nicht die Übersicht zu verlieren - eine Art Stammbaum. ;)

Kannst Du Windows(Legacy) auch aus dem OCLP-BootMenü zuverlässig/reproduzierbar starten?
Warum sollte ich den Weg gehen? Testweise stelle ich aber fest, dass es fast immer nicht funktioniert.

Muss eben direkt über den Apple-BootPicker gestartet werden und nicht, nachdem OCLP-BootMenü gestartet wurde.
Du könntest das Gleiche machen, was ich beim MP5.1 wegen der NVMe-SSD-UEFI-Installation gemacht habe: Ich war es nämlich leid, immer dran zu denken, beim Booten ALT zu drücken, um WinOS vernünftig zu erreichen. In 50% der Fälle habe ich es verpasst. :rolleyes:

Dein MBP ist doch noch jünger als mein MP5.1, aber die Ausgangslagen gleichen sich: macOS & WinOS auf getrennten Datenträgern.
Wenn eh schon OCLP wegen macOS Ventura vor Ort ist, dann auch den OCLP-Schutzschirm nutzen und Alles nach der OCLP-Schranke angeboten bekommen: eine Ebene und "bequem".

Und um sicher zu sein, dass der Schutzschirm aktiviert ist, bin ich von meiner sonstigen Methode - OCLP auf separatem Stick - abgewichen und habe OCLP direkt in die ESP des Win-Datenträgers platziert.
Der Bootvorgang geht automatisch bis zum OCLP-Menü durch und präsentiert das volle Programm. ;)

Ist der WinOS-Datenträger mal nicht eingesetzt, gibt es auch kein OCLP. Oder anders herum betrachtet: OCLP & WinOS bedingen sich im MP5.1: das Eine gibt es nur mit dem Anderen. ;)
ich nehme die NVMe auch schon mal raus, wenn ich rumprobiere, laufe aber damit auch nicht in die mögliche Zertifikatsfalle, weil ich den sonst üblichen Stick mal vergessen habe.
Wird bei Deinem MBP sicher immer drin sein.

Das Volume 0 aus Beitrag #24 (Win11-MP3.1) wird ganz eindeutig per MBR gebootet, auch wenn es etwas speziell ist, dass es nur eine einzelne Partition ist. Die Startdateien befinden sich darauf ("System"), es ist NTFS-formatiert, Schlussfolgerung: wenn es das einzige Laufwerk ist und sich selbst starten muss, geht nur MBR.
Richtig analysiert. ;)
Und es lässt sich alleine starten, wenn ansonsten nichts im MP3.1 drin steckt.
 
Der Windows ESP kann man auch den Boot Ordner entziehen, dann kann das (bis zum nächsten Windows Update) nur noch von OpenCore gestartet werden.

https://dortania.github.io/OpenCore...-the-windows-option-from-the-stock-bootpicker

Dann ist man einigermaßen auf der sicheren Seite, wenn man einen alten Mac mit schmalen NVRAM hat.

Man könnte auch ein Tool oder Skript bauen was regelmäßig in MacOs die Windows ESP entschärft...

Wäre noch was für die ESP Tools…
 
Der Windows ESP kann man auch den Boot Ordner entziehen
Nett gedacht, aber das wäre mir als Schutz zu riskant, denn - wie festgestellt - hält diese Maßnahme mal gerade bis zum nächsten Update und die kommen häufiger als man denkt. Jedesmal dann das Editieren ...

Ich denke, dass ich mit der physischen Kopplung von Uefi-WinOS & OCLP eher auf der sicheren Seite bin. Der Schutz wird auch durch ein zufälliges Update nicht ausgehebelt. ;)
 
Sicher? Macht m.E. keinen Unterschied; Windows findet die EFI-Partition auf einem anderen Laufwerk und trägt sich da entsprechend ein (boot-Ordner mit bootx64.efi). Nach einem Reset des NVRAM wird ja nicht mehr über OC als erstes gestartet.

Mir ist keine 100% sichere Lösung bekannt, wie man Windows das automatische Eintragen auf die ESP abgewöhnen kann.
 
Das wäre eine Aufgabe für den Bootlader, ist dann auch nicht 100%, aber das was am häufigsten den ESP sieht.

Das schützt mich aber auch nicht nach einem vollen nvram reset mit neu setzen von BootOrder.

Man kann, wenn man die Wahl hat, experimentieren welche ESP welchen Laufwerks an erster Stelle gestartet wird. Das variiert dummerweise. Ganz gut fahr ich am Mac Pro mit dem ersten Sata Port, nicht die Bays, sondern die Ports der DVD Laufwerke. Wenn nicht sowieso belegt, dann im zweiten DVD Port eine kleine SSD nur für den Bootlader. Winzige SSDs gibts fast geschenkt.


Denn, was bringt mir ein Script im MacOs wenn beim User zu 90% Windows läuft. Und wie Udo schon schrieb, nach vollem nvram reset wird u. U. Die Windows ESP gestartet.

Auch für die nicht Mac Pros gilt natürlich: Bootrom Backup ziehen, wenn Uefi Win im Spiel ist. Der belegte Platz im nvram durch die Zertifikate triggert die Garbage Collection mehr und die alten Flash Chips kommen dann schneller an ihre Verschleißgrenze.

Das kann u. A. mein Dumper. Flashen von nicht Mac Pros nicht, den schwarzen Peter geb ich an DosDude weiter :p … nein, was ich nicht austesten kann bau ich nicht in meine Tools ein.
 
  • Gefällt mir
Reaktionen: dg2rbf
Nach einem Reset des NVRAM wird ja nicht mehr über OC als erstes gestartet.
Guter Punkt - könnte auch das Konstrukt aushebeln, aber via ALT komme ich nicht an mein Uefi-WinOS ran, soweit ich das bis dato erlebt habe.

Erneuter Test:
Nach Wiedereinbau der beiden MVMe-SSD mit macOS & WinOS plus der gemischten Sata-SSD lande ich hinter der OCLP-Schranke.
Den NVRAM-Reset (4x Gong) habe ich auch gleich ausgetestet: da lande ich ohne ALT direkt bei EC, also vor der OCLP-Schranke.
Mit ALT komme ich (nach dem tiefen Reset) an WinOS nicht ran - ein Windows (legacy) gibt es mangels Vorhandensein nicht.
Bei welcher Gelegenheit könnte also Gefahr drohen?
 
Guter Punkt - könnte auch das Konstrukt aushebeln, aber via ALT komme ich nicht an mein Uefi-WinOS ran, soweit ich das bis dato erlebt habe.

Erneuter Test:
Nach Wiedereinbau der beiden MVMe-SSD mit macOS & WinOS plus der gemischten Sata-SSD lande ich hinter der OCLP-Schranke.
Den NVRAM-Reset (4x Gong) habe ich auch gleich ausgetestet: da lande ich ohne ALT direkt bei EC, also vor der OCLP-Schranke.
Mit ALT komme ich (nach dem tiefen Reset) an WinOS nicht ran - ein Windows (legacy) gibt es mangels Vorhandensein nicht.
Bei welcher Gelegenheit könnte also Gefahr drohen?


Das könnte bei dir an der NVMe Kombi liegen. Das stört schon mal den Ablauf beim Booten, hab ich auch in mancher Kombination

Normalerweise tm lädt der erste ESP, wenn keine Bootvariablen gesetzt sind. Also entweder OpenCore oder Windows ESP.

Ein "normales" MacOs wäre eigentlich nicht zuerst an der Reihe. Wahrscheinlich sieht die Firmware die ESPs durch die NVMes oder einen Controller nicht.
 
So müsste es auf jeden Fall zum Problem werden:
- nur ein Laufwerk
- nur Windows im UEFI-Modus installiert
- auf der ESP sind die Startdateien vorhanden

Selbst wenn OC installiert wäre, wird als einzige Startoption Windows gefunden und gestartet. Entschärft wird das aber bereits, wenn ein macOS mit auf der Platte ist, weil der Mac das bevorzugt.

Also ein sehr spezielles Szenario, kann aber vorkommen, wenn man eine Windows-Festplatte aus einem PC einbaut.
Über das Bootmenü (alt) wird einem die Option auch angeboten, das muss man halt einfach wissen, dass man das besser nicht startet. Das passiert nur, solange in der ESP noch die Startdateien für Windows sind; sobald die gelöscht wurden, taucht Windows nicht mehr im Apple-Bootmenü auf, nach einem Update aber möglicherweise wieder.
 
So müsste es auf jeden Fall zum Problem werden:
- nur ein Laufwerk
- nur Windows im UEFI-Modus installiert
- auf der ESP sind die Startdateien vorhanden

Selbst wenn OC installiert wäre, wird als einzige Startoption Windows gefunden und gestartet. Entschärft wird das aber bereits, wenn ein macOS mit auf der Platte ist, weil der Mac das bevorzugt.

Also ein sehr spezielles Szenario, kann aber vorkommen, wenn man eine Windows-Festplatte aus einem PC einbaut.
Über das Bootmenü (alt) wird einem die Option auch angeboten, das muss man halt einfach wissen, dass man das besser nicht startet. Das passiert nur, solange in der ESP noch die Startdateien für Windows sind; sobald die gelöscht wurden, taucht Windows nicht mehr im Apple-Bootmenü auf, nach einem Update aber möglicherweise wieder.

das ist mein Hauptproblem, wenn ich Firmwares nach Zertifikaten neu baue, wenn die Leute ein Uefi Windows im Rechner haben:

Das nvram ist leer, die Firmware startet die erste ESP die es findet, wenn man Pech hat ist das die Windows ESP und das nvram bekommt dann gleich wieder seine Signierung.

Ich empfehle deshalb: nach den Flashen der leeren Firmware das Uefi Windows physisch zu entfernen bis OpenCore das erste mal gelaufen ist und sich bei korrekter Einstellung (LauncherOption: Full) selber geblesst hat (als erstes in BootOrder eingetragen hat).
 
  • Gefällt mir
Reaktionen: dg2rbf
Das könnte bei dir an der NVMe Kombi liegen
Auf welchen Zeitpunkt/Status beziehst Du Dich jetzt?

Das nvram ist leer, die Firmware startet die erste ESP die es findet, wenn man Pech hat ist das die Windows ESP und das nvram bekommt dann gleich wieder seine Signierung.
Der Satz irritiert mich: da ist doch nach bisheriger Lesart OCLP vor.
- nur ein Laufwerk
- nur Windows im UEFI-Modus installiert
- auf der ESP sind die Startdateien vorhanden

Selbst wenn OC installiert wäre, wird als einzige Startoption Windows gefunden und gestartet.
Das wäre aber nach meinem Verständnis kein Drama, denn der Weg geht doch so oder so nur über OLCP.
Die Win-Installation ist ja wie bekannt via Drittrechner erstellt worden - da ist alles Notwendige an Startdateien drauf, aber in der Win-ESP ist auch OCLP vorhanden. Und damit ich dahin komme, wird wie gerade vom Schrauber beschrieben OCLP selbst gesegnet, wenn ich es nicht eh schon manuell erledigt habe.

P. S. ich schlage vor, wir bitten einen Admin, ab #30 die Kommentare abzukoppeln und als eigenständigen Thread bei "Windows auf dem Mac" einzuordnen. Ich möchte bobeschs Thread nicht kapern, da es jetzt schon etwas von seinem Thema wegführt.
 
Auf welchen Zeitpunkt/Status beziehst Du Dich jetzt?


Der Satz irritiert mich: da ist doch nach bisheriger Lesart OCLP vor.

die Firmware, wenn sie noch keine Einträge hat, scannt alles durch was sie lesen kann. Sata, PCI, USB, FireWire, .. ohne Anspruch auf die reale Reihenfolge

nehmen wir jetzt einfach mal an um es nicht zu verkomplizieren:

1. Windows ESP unverändert
2. OpenCore ESP

dann lädt die Windows ESP und signiert. Da genügt schon starten der ESP, da muss noch nicht mal Windows selbst angelaufen sein.

dann ist OC noch nicht gelaufen und die Windows ESP hat signiert.

… Ist es zufällig umgekehrt dann ist OC gelaufen und hat sich selbst geblesst.
 
Zurück
Oben Unten