Ein MBR ist zwar zwingend erforderlich damit die GPT korrekt erkannt werden kann, aber normalerweise steht da nur ein "Schutzeintrag" drin, der die gesamte HD abdeckt. Dadurch soll vermieden werden, dass veraltete Systeme die HD irrtümlicherweise als vermeintlich "leer" betrachten.
Bei Auswahl von MBR wird ein reines MBR-Layout angelegt und die GPT ungültig gemacht.
Ohne den oben beschriebenen speziellen Eintrag vom Typ 0xEE wird nach einer GPT Tabelle nämlich gar nicht erst gesucht, auch falls sie noch vorhanden wäre.
Oder etwa nicht.
(Bild) ohne Worte.
Der Anspruch ist nicht reklamiert, das Procedere ist "inoffiziell".
Dennoch empfiehlt es sich sehr, auf derartige zukünftige Änderungen vorbereitet zu bleiben.
Erst wenn wirklich alle relevanten Betriebssysteme mit vollem EFI-Support zu haben sind, kann man all diese Einschränkungen in die Tonne kloppen und seine HD in so viele Bereiche zerteilen wie man will.
Nach wie vor ist OS X das einzige entsprechende System. Linux steckt hier immer noch in der Anfangsphase fest. Microsoft s.u.
Weil Windows den Start aus nicht technisch zu erklärenden Gründen verweigert, sobald man ihm die wahre Partitionstabelle mit dem GPT-Schutzeintrag zeigt.
Damit Windows seinen Bootvorgang nicht unter absichtlicher Vortäuschung eines Fehlers einfach abbricht, muss der erste Partitionseintrag vom Typ 0xEE kurzzeitig vor dem Bootloader verborgen werden.
Dadurch verschiebt sich die numerische Ordinalzahl, die BIOS für seine Handles verwendet um den Wert Eins. Der NT-Bootloader NTLDR landet bei seinem selbst durchgeführten Neulesevorgang des MBR dadurch zwangsläufig immer genau eine Partition neben seinem eigentlichen Ziel, wenn diese "kleine Rochade" nicht korrekt ausgeführt werden kann.
Dieser MS-spezifische EFI-Trick darf nur bei Microsoft Systemvolumes durchgeführt werden, bei anderen Partitionen bewirkt er das Gegenteil. Und da Microsoft seine Partitionen während des Bootvorgangs "rückwärts einzählt", geht EFI ebenso vor. Die numerisch letzte NT-lesbare Partition wird als Windows-Partition behandelt, die evtl. noch davor stehenden nicht. That's the Point.
(Aus diesem Grund funktioniert auch die XP-Wiederherstellungskonsole nicht, wenn sie unter Boot Camp auf der HD installiert wird. CMLDR und NTLDR führen nacheinander einen doppelt ausgeführten Re-Read durch, auf den EFI nicht vorbereitet ist. Der "böse" GPT-Eintrag wird zu früh wieder sichtbar geschaltet, der Start dieser Idiotenshell endet damit im gleichen Bluescreen.)
Du hast ja noch nicht mal an der Spitze des Eisbergs aus purem Zitronensaft geleckt.
Mach doch auf einem reinen BIOS-PC mal folgendes Experiment (eine virtuelle Maschine zB in VMware genügt dafür auch):
Richte auf einer ansonsten vollständig leeren HD genau zwei "primäre" Partitionen ein, die erste vom Typ 0x83 (Linux), die zweite vom Typ 0x07 (NTFS). Lasse dabei den letzten und vorletzten Zylinder frei, so wie auch das Windows-eigene Partitionierungsprogramm das tun würde.
(Der letzte "Zylinder" MUSS freibleiben, sonst kommt der berüchtigte "Medienfehler" beim Start von XP. Der vorletzte bleibt bei MS reserviert für das NT-eigene LVM-System namens "Dynamische Datenträger".)
Mit "vollständig leer" meine ich übrigens: wirklich vollständig, überschreibe sie vorher komplett mit Nullen wenn du willst. Lasse diese beiden Partitionen zunächst noch unformatiert, so dass kein möglicher Inhalt darin einen evtl. störenden Einfluss auf den Versuch haben könnte.
Installiere auf der NTFS Partition daraufhin ein Windows XP, auf gewohntem Weg aber auf jeden Fall ohne die Partitionierung dabei irgendwie zu verändern.
Starte dieses Windows, es wird ganz normal laufen. Die für ein Linux vorbereitete Partition wird in der Datenträgerverwaltung als "unbekannt" angezeigt werden, ganz wie man das erwarten kann. Alles bestens, ja?
Jetzt boote ein externes Medium (zB eine Knoppicillin CD) und manipuliere die Partitionstabelle:
Ändere den Partitionstyp der ersten Partition von 0x83 (Linux) auf 0xEE (EFI GPT Schutzzone).
Ansonsten änderst du nichts.
Versuche dein Windows neu zu booten und beobachte was geschieht, wenn Windows beim Start schon bemerkt (bzw hier: nur glaubt zu bemerken), dass es auf einem Computer von Apple gestartet werden soll.
(Das waren zum fraglichen Zeitraum die einzigen am Markt, die mit EFI und der dazugehörigen Partitionierung daherkamen, und bei denen Microsoft das auch ganz genau schon lange zuvor im Vorfeld wusste.)
Was denkst du jetzt? Gehen dir die Augen auf?
Entsetzt über diese offenkundige Frechheit?
Tja, MS hat eben kein vitales Interesse daran, sein Windows auch auf Macs laufen zu sehen...
Windows Vista SP1, Server 2008 und "Seven" bieten "vollen" EFI-Support.
ABER:
- nur für die jeweils 64bittigen Varianten von EFI und OS
- nur für die neue Version "UEFI 2.x", nicht aber für den älteren Standard "EFI 1.x" den man bis dato in allen Macs vorfindet.
Das letztere ist dabei schon wieder mal so eine offenkundige Sabotage-Aktion gegen Apple-Rechner wie schon die oben demonstrierte Nummer.
EFI 1.x würde rein technisch gesehen voll ausreichen (es beinhaltet alle wirklich nötigen Funktionen). Aber erst ab UEFI 2.x wird nicht mehr nur ein optional vorhandenes BIOS-CSM (CSM = "Compatibility Support Module", vulgo: "Emulation") angeboten, sondern es wird zwingend verlangt. Darüberhinaus auch noch ein bis dahin nicht erforderliches weiteres CSM, das ein rudimentäres Grafikkarten-BIOS nach dem CGA/VGA Standard enthält.
Obwohl der Windows Bootloader von diesem VGA-BIOS keinerlei praktischen Gebrauch macht, weigert er sich zu laufen wenn es nicht da ist. (Präziser gesagt: BIOS INTh10 muss voll unterstützt sein - obwohl es im ganzen Windows-System keinen einzigen Aufruf dazu mehr gibt.)
EFI auf Apple-Rechnern wird also erst dann eine echte Unterstützung durch Microsoft Systeme erhalten, wenn Apple per Firmware-Updates die entsprechenden Komponenten nachrüstet.
Ganz so einfach geht das aber nicht, denn darauf lastet so ein leidiges Ding namens "Geistiges Eigentum"...
(Und ausgerechnet Apple macht man zum Vorwurf, sein OS "rechtswidrig" an bestimmte Hardware zu binden. Lustig, nicht wahr?)
