GPT-Boot: allgemeine Frage, MBR - EFI...

pit234a

Well-Known Member
Hi.
gerade spiele ich mit gpart um es besser kennen zu lernen und dabei auch den GPT ein wenig zu lernen. Sowas braucht man nicht oft, aber es gibt dabei Dinge, die ich nicht verstanden hatte und wenn ich mir dann ansehe, wie es tatsächlich aussieht, werden mir die oft klarer.
Nunja. Das meiste, was mich interessierte, habe ich wohl inzwischen kapiert.

Aber: wie bootet ein System mit einem GPT?

Ich habe mir eine Partition angelegt und den /boot/gptboot dorthin installiert. Soweit, so gut. Da liegt nun der Bootcode also am Anfang der (einzigen) Partition. An eine andere Stelle (etwa den "MBR") passte dieser Code gar nicht, der geht nur auf die Partition.
Im LBA0, dem "MBR", ist aber keinerlei Bootcode eingetragen worden.
gpart bootcode -p /boot/gptboot -i 1 da0 schreibt also, wie auch zu vermuten ist, genau den ausgewählten Bootcode an den angegebenen Platz, mehr nicht. Es hätte ja sein können, dass solch ein Aufruf automatisch auch dazu führt, dass im "MBR" die erste Partition als Bootfähig gesetzt wird und vielleicht ein MBR-Bootcode eingefügt wird, der dann den gptboot automatisch startet.

Bei manchen Systemen wird wohl ein EFI benutzt.
Dazu lese ich dann aber, dass dieses aus dem "MBR" aufgerufen und in der ersten Partition liegen müsste. Ist mein Bootcode (aus /boot/gptboot) ein EFI?
Im LBA0 ("MBR") sieht es so aus:
Code:
[FONT="Courier New"]hexdump -C /home/pit/gpt_55b
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 01  |................|
000001c0  01 00 ee ff ff ff 01 00  00 00 ff 73 f3 00 00 00  |...........s....|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|[/FONT]
Die Einträge sind nachvollziehbar. Aber, da ist kein Bootcode drin und da ist keine Partition als Bootfähig gekennzeichnet.
Ganz offenbar startet dieser "MBR" nichts.

Ich will es nicht probieren und ein System in meine Partition installieren, um zu sehen, ob das dann bootet. Nach meiner Überzeugung dürfte es dies nicht!
Mein Bios weiß ja nichts davon, dass ich nun einen GPT benutzen will und vielleicht ein EFI.

Das ist nun kein aktuelles Problem und es drängt gar nichts.
Wenn ich aber mal (vollkommen blödsinnigerweise) einen bootbaren Stick mit GPT erstellen möchte, wie gehe ich dann vor? (Vermutlich ist die Aufgabe beim Stick sinnlos, aber grundsätzlich doch immer gleich).
Dabei ist der Begriff bootbar nun noch neutral, aber ich meinte natürlich, booten von einem i386 oder amd64 ("Bios-System").
Interessieren würde mich aber auch EFI, denn manche Netbooks und Macs nutzen das ja. Könnte ein solcher Rechner, etwa ein Mac, von einem unter FreeBSD erstellten, mit EFI bootbar erstellten Stick, gebootet werden? Ist EFI gleich EFI oder gibt es dann wieder Unterschiede für die jeweiligen Geräte? Wo bekomme ich dann die benötigten EFI-Bootcodes her? Oder versteh ich hier grundsätzlich was gar nicht?
Bin ich bei "Intel"-PCs immer auch auf das Bios angewiesen, oder könnte ich die auch mit einem (von mir selbst erstellten?) EFI booten?
 
Installier den Bootcode mittels
Code:
gpart create -s gpt $DEV
gpart add -t freebsd-boot -s 64K -l $BOOTNAME $DEV
gpart bootcode -i 1 -b /boot/pmbr -p /boot/$BOOTLOADER $DEV
wobei $DEV der Pfad des Blockdevices relativ zu /dev ist, $BOOTNAME der Name der GPT Partition des Bootloades und $BOOTLOADER entweder gptboot oder gptzfsboot ist je nach dem ob du von UFS oder ZFS booten willst.
 
FreeBSD bootet mit oder ohne (U)EFI, wenn Du die Methode von Crest anwendest. Bei ZFS ist das aber noch nicht das Ende der Geschichte.

Es gibt im offiziellen FreeBSD Wiki genug Beispiele für GPT-Boot mit sehr unterschiedlichen Kombinationen von Dateisystemen und Datenträgern. Schau mal dort rein.
 
EFI ist die Ablösung des BIOS und wird bei (einigen) Systemen schon eingesetzt, bspw. Apple oder auch x-Series von IBM. Gelegentlich kann man es auch bei manchen Boards schon umstellen. Mein Laptop hat bspw. noch kein EFI, funktioniert aber mit FreeBSD und GPT trotzdem. Windows und OpenBSD brauchen zwingend EFI, um GPT überhaupt zu unterstützen; auf Platten, die ein GPT enthielten, lassen sie sich dann nicht mehr ohne Low-level format bringen, da sie den zweiten GPT-Eintrag am Ende der Platte finden (man möge mich korrigieren, aber so hab ich das bei beiden Systemen verstanden). Ob das nun sinnvoll ist, soll jeder für sich selbst entscheiden ;). Das FreeBSD-Wiki hat einige ganz nette Infos zu der Geschichte.

Vgl. auch http://de.wikipedia.org/wiki/Extensible_Firmware_Interface
 
GPT ist wie ja gesagt das Partitionsformat von EFI, beinhaltet also auch einen entsprechenden Bootmechanismus. Allerdings können derzeit weder FreeBSD/i386 noch FreeBSD/amd64 diesen nutzen. FreeBSD nutzt daher den alten BIOS-Bootmechanismus mit den GPT-Partitionstabellen. Das führt nun zu einigen Konsequenzen:

1. FreeBSD kann, egal ob BIOS oder EFI auf der Kiste ist, von GPT-Tabellen booten. FreeBSD kann auch von Platten >2TB starten, selbst wenn kein EFI vorhanden ist. Die Bedingungen sind nur, dass die Partition mit dem Kernel kleiner als 2TB ist, unter 2TB liegt und vor allem das BIOS die Platte erkennt. Allerdings tun praktisch alle BIOSe mit AHCI-Unterstützung da.

2. Linux kann sowohl nativ mit dem EFI-Verfahren als auch GPT mit dem alten BIOS-Verfahren booten. Für Linux gilt daher für Platten >2TB das gleiche wie für FreeBSD. Allerdings sollte man da noch beachten, dass die Distro noch ein Wort mitzureden hat.

3. Windows kann GPT-Tabellen nur mit dem EFI-Verfahren booten. Daher unterstützt Windows den Boot von Festplatten von >2TB nur in Kombination mit EFI. Das ist zwar bei buchstabentreuer Auslegung des Standards die einzige korrekte Kombination, allerdings muss man sich dennoch die Frage stellen, was eigentlich Sinn und Zweck davon ist. Will man die Hardwareverkäufe ankurbeln?

4. Um die Verwirrung perfekt zu machen, gibt es inzwischen auch BIOSe, die das EFI-Verfahren zum Booten unterstützen. Diese können dann, obwohl sie kein EFI sind, sowohl Linux als auch Windows mit der EFI-Methode booten. Damit kann dann dort auch Windows von Platten >2TB booten.

Neben dieser Bootproblematik gibt es allerdings noch andere gute Argumente für GPT:
1. Es ist durch die zwei Tabellen und Prüfsummen über die Tabellen wesentlich robuster als die alten MBR-Tabellen des BIOS.
2. Es werden ca. 65.000 Partitionen pro Laufwerk unterstützt, als bisher nur 4. Das Verketten von Partitionstabellen (E-MBR oder BSDLabel) fällt damit weg.
3. Die Verwaltung ist wesentlich einfacher. Gerade spätere Änderungen an der Tabelle sind sicherer und zuverlässiger.
 
Sind diese Vorteile überhaupt noch relevant? Ich meine, der Trend geht doch sowieso zu OS-spezfischen Lösungen, ob ZFS oder LVM, am Ende macht doch niemand hunderte GPT-Partitionen, oder?
 
Grundsätzlich: (U)EFI ist die Definition einer Schnittstelle zwischen Hardware, Firmware ("BIOS") und Betriebssystem, teilweise auch noch zwischen Firmware und Benutzer (Shell). BIOS ist eine andere, ältere und nicht genau definierte Schnittstelle zwischen den selben Komponenten.

gptboot(8) ist ein Loader für FreeBSD, der eine GUID Partition Table (GPT) interpretieren kann um z.B. den Kernel zu laden. gptboot(8) ist, so wie ich das sehe, keine UEFI-kompatible Applikation, d.h. um Disk-Blöcke zu laden greift das Programm auf BIOS Schnittstellen zurück.

Das ist nun kein aktuelles Problem und es drängt gar nichts.
Wenn ich aber mal (vollkommen blödsinnigerweise) einen bootbaren Stick mit GPT erstellen möchte, wie gehe ich dann vor? (Vermutlich ist die Aufgabe beim Stick sinnlos, aber grundsätzlich doch immer gleich).

Das wurde ja schon von Crest beantwortet.

Dabei ist der Begriff bootbar nun noch neutral, aber ich meinte natürlich, booten von einem i386 oder amd64 ("Bios-System").

Ein klassisches BIOS kann nur mit einem MBR etwas anfangen. Möglicherweise gibt's mittlerweile tatsächlich, wie Yamagi sagt, BIOS Implementierungen welche GPT interpretieren können. Vermutlich sind das dann aber schon UEFI Implementierungen mit einem BIOS Kompatibilitäts-Modul.

Egal wie, wenn Du also ein BIOS hast, dann brauchst Du einen MBR. UEFI schreibt vor, entweder einen "Legacy MBR" oder einen "Protective MBR" an den Anfang der Platte zu schreiben, so dass ein BIOS mit der Platte zurecht kommt (Legacy MBR) oder zumindest nichts kaputt macht (Protective MBR). Letzerer breschreibt im Prinzip die gesamte Platte als eine einzige Partition, welche die gesamte Plattenkapazität umfasst. Diese Partition wird dem BIOS gegenüber als nicht bootfähig markiert und es ist auch kein (BIOS-)Bootcode im MBR vorhanden. Der Dump, den Du gepostet hast, zeigt genau das.

Um beides, d.h. GPT + BIOS vereinen zu können, brauchst Du einen MBR, den das BIOS ausführt und einen Loader, der GPT versteht. FreeBSD macht genau das: Es schreibt einen MBR, allerdings mit (BIOS-)Bootcode, so dass das BIOS den Bootcode ausführt. Dieser Bootcode, pmbr, interpretiert dann die GPT, sucht nach einer FreeBSD Bootpartition und lädt von dort den zweiten Bootloader, gptboot(8).

Interessieren würde mich aber auch EFI, denn manche Netbooks und Macs nutzen das ja. Könnte ein solcher Rechner, etwa ein Mac, von einem unter FreeBSD erstellten, mit EFI bootbar erstellten Stick, gebootet werden? Ist EFI gleich EFI oder gibt es dann wieder Unterschiede für die jeweiligen Geräte? Wo bekomme ich dann die benötigten EFI-Bootcodes her? Oder versteh ich hier grundsätzlich was gar nicht?

Ein (U)EFI-kompabibler Boot Block wird von jeder (U)EFI-kompatiblen Firmware interpretiert werden könnnen. So wie FreeBSD das macht, wird ein System mit UEFI-kompatibler Firmware, also z.B. ein Mac, zumindest das Partition-Layout lesen und verstehen können.

Da allerdings gptboot(8) keine UEFI-Applikation ist, kracht's spätestens hier, denn die UEFI Firmware wird das Programm nicht laden und ausführen können.

Bin ich bei "Intel"-PCs immer auch auf das Bios angewiesen, oder könnte ich die auch mit einem (von mir selbst erstellten?) EFI booten?

Niemand zwingt Dich, das vom Board-Hersteller mitgelieferte BIOS zu verwenden. Allerdings gibt's, realistisch gesehen, wenig Alternativen. Das coreboot Projekt bietet quelloffene Firmware an, die allerdings nur die Hardware initialisiert. Leider wird nur wenig Hardware unterstützt, da nicht alle Hersteller die entsprechende Dokumentation rausrücken. Auf coreboot setzt man dann entweder eine BIOS Implementierung (SeaBIOS) oder bootet den (Linux-)Kernel direkt.

Ich hab' mal Teile von TianoCore als UEFI Layer auf coreboot gepackt -- man braucht etwas Glue-Code und dann geht das erstaunlich einfach: https://phs.phisch.org/website/efiboot/

Übrigens: Wer sich mal in die Richtung vertiefen möchte, dem kann ich diesen Link empfehlen.
 
Vincent Vega schrieb:
Möglicherweise gibt's mittlerweile tatsächlich, wie Yamagi sagt, BIOS Implementierungen welche GPT interpretieren können. Vermutlich sind das dann aber schon UEFI Implementierungen mit einem BIOS Kompatibilitäts-Modul.
Frag mich nicht. Gigabyte bietet auf ihren neueren Boards das z.B. an. Sieht nach außen wie ein normales Award-BIOS aus, hat die gleiche Ausgabe, etc. Aber was da wirklich drunter steckt kann ich so natürlich nicht sagen. Und meine Begeisterung da nun in der Binärsuppe rumzurühren ist auch eher gering.

Vincent Vega schrieb:
Da allerdings gptboot(8) keine UEFI-Applikation ist, kracht's spätestens hier, denn die UEFI Firmware wird das Programm nicht laden und ausführen können.
Wobei es nur eine Frage der Zeit sein dürfte, bis es einen echten EFI-Loader gibt. FreeBSD/ia64 nutzt den seit Jahren, für i386 und amd64 gibt es da bereits unausgereifte Versionen und es steht auf der Liste der möglichen GSoC-Projekten. Vielleicht nimmt sich also jemand der Sache an.
 
Danke euch sehr für die Antworten. Das hat mir schon was gebracht und, um euch zu zeigen, wie das manchmal so geht:
Ich hatte geglaubt, EFI (UEFI) seit ein Bootcode, der auf dem Bootmedium stehen muss und dann ein Bios-unabhängiges Booten ermöglicht.

Also, wenn ich das richtig verstanden habe, ist das alles eine Firmware (auf dem Motherboard) und es gibt Rechner, die haben ein BIOS und andere haben ein (U)EFI und es scheint auch eine Art Hybrid zu geben. Auf den üblichen Motherboards kann diese Firmware erneuert oder ausgetauscht werden, wozu aber eine spezielle Routine nötig ist. Durch solche Austauschverfahren könnten dann auch Alternativen, wie coreboot eingesetzt werden.

Finde ich nun einen Rechner, der ein (U)EFI hat, dann bräuchte ich auch einen entsprechenden Bootloader, um damit booten zu können. Der klassische MBR hilft hier nicht weiter, der wird nicht verstanden.
FreeBSD bietet solche Lösungen (noch) nicht für i386 und amd64 an. Diese werden in der Regel auch BIOS haben.
Intel-Macs wollen wir hier nicht weiter behandeln, aber diese benutzen ein EFI und sind i386 - amd64 Rechner. Über die Möglichkeiten, dort ein anderes System zu booten, kann man hier etwas lesen: http://refit.sourceforge.net/

Wenn ich nun also GPT nutzen will und von meinen BIOS Rechnern i386, amd64 FreeBSD booten möchte, dann brauche ich drei Dinge:
-Einen MBR, der dem eigentlichen GPT vorgelagert ist und einen speziellen Bootcode enthält.
-Eine eigene kleine Partition, in welche der GPT-Bootcode geschrieben werden kann.
-Eine weitere Partition, von der dann gebootet wird.
Der spezielle MBR heißt /boot/pmbr, der GPT-Bootcode /boot/gptboot oder bei ZFS /boot/gptzfsboot.

Was ich nun sehe ist nach Umsetzung von
gpart bootcode -i 1 -b /boot/pmbr -p /boot/gptboot da0 :
Code:
[FONT="Courier New"]00000160  00 00 00 00 00 00 9d 6b  bd 83 41 7f dc 11 be 0b  |.......k..A.....|
00000170  00 15 60 b8 4f 0f 90 90  90 90 90 90 90 90 90 90  |..`.O...........|
00000180  90 90 90 90 90 90 90 90  90 90 90 90 90 90 90 90  |................|
*
000001b0  90 90 90 90 90 90 90 90  00 00 00 00 00 00 [COLOR="Red"]80[/COLOR] 01  |................|
000001c0  01 00 ee ff ff ff 01 00  00 00 ff 73 f3 00 00 00  |...........s....|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
[/FONT]
Dieser MBR enthält nun Bootcode und markiert die erste Partition als Bootfähig. Die erste Partition enthält nun den /boot/gptboot.

Was ich mir noch genauer ansehen müsste, wäre nun, wie etwa von einer Partition 3 oder 4 oder 15 gebootet werden könnte. Kann der /boot/gptboot entsprechend konfiguriert werden? Wie würde der so etwas wissen? Etwa auch, welches von mehreren möglichen Systemen er nun starten sollte. Müsste dann ein Bootmanager (GRUB) von ihm aufgerufen werden?

Für meine Anwendungen sehe ich bislang keinen Vorteil im GPT gegenüber MBR, vor allem bei Erstellung von bootfähigen Medien. Ich interessiere mich eher dafür, weil es nicht ausbleiben wird, dass man im PC-Umfeld darauf treffen wird.

Eine Kleinigkeit vielleicht zwischendurch: durch die Verwendung von GPT-Labeln, UUID und Filesystem-Labeln, erkennt meine Automatik (HAL und Konsorten) für jede GPT-Partition auf meinem Versuchs-Stick nun drei Geräte und versucht sie einzubinden. In meinem KDE3 habe ich das so eingerichtet, dass kleine USB-Icons pro Gerät erscheinen. Bei einem Versuch mit 9 Partitionen erschienen also 27 neue Icons auf meinem Desktop!

Die Möglichkeiten von gpart und wie sauber das umgesetzt wird, gefallen mir immer besser.
 
Außer dass "BIOS" der generelle Ausdruck dafür ist (Basic Input Output System)... also der doofe Programmcode, der im ROM/EEPROM oder sonstiger Form aufm Mainboard sitzt und das Booten (allgemein: Starten vom austauschbaren Code) anstößt. Ob jetzt das alte PC-BIOS oder (U)EFI... ist alles BIOS. Aber tröstet Euch, nicht einmal Wikipedia hat's verstanden. Alle Rechner und portable Geräte, die von Medien starten haben ein BIOS (schon ein C128 hatte CP/M, das es von der Floppy startete).

Und noch nicht einmal das, auch ein C64 hatte ein BIOS (im klassischen Sinne) namens "KERNAL" (nein, das ist nicht falsch geschriebenes "Kernel"). Ein Gameboy hat ebenfalls einen Code, der das Logo von Nintendo in die Mitte scrollt und "ping!" sagt (fest kodiert in der Hardware), dann springt der Code erst das Programm in der Cartridge an.
 
http://weispit.eu/GPT.pdf

Der wikipedia Artikel zu GPT und die anschließende Diskussion waren auch ein Grund, weshalb ich mir das mal näher ansehen wollte.
Mit vielen Details habe ich "meine Erkenntnisse" mal in dem PDF oben zusammengestellt. Das ist noch nicht verlinkt, der letzte Hinweis von nakal ist nicht berücksichtigt, aber vielleicht kann die Darstellung doch helfen, die Sache genauer zu sehen.

Was ich weiter damit mache, weiß ich noch nicht. Für einen Diskussionsbeitrag in http://de.wikipedia.org/wiki/Diskussion:GUID_Partition_Table taugt es jedenfalls nicht.

Dieses Thema will ich hier auch nicht beliebig ausweiten und den Thread belasten. Vielleicht habt ihr nichts besseres zu tun und seht es euch an. Über Anregungen und Hinweise freue ich mich immer, obwohl ich manchmal sehr dickköpfig bin ;)
 
Zurück
Oben