Bootstrap und bsdlabel

Tronar

aus Überzeugung altmodisch
Wozu dient eigentlich das "bsdlabel" in einem Slice? Zunächst mal erlaubt es ja, den Slice in mehrere Partitionen a,b,d,e,... zu unterteilen. Wenn man aber mit vier Partitionen auskommt oder GPT verwendet, ist diese Unterteilung ja völlig überflüssig.
Dann brauche ich ein bsdlabel nur für den Slice, von dem ich booten will. Andere, z. B. für meine /home-Partition, kann ich einfach als ada0s3 mit UFS formatieren statt als ada0s3d, richtig?
Wie ist es mit der Swap-Partition? Kann ich dafür auch ada0s2 ohne 'b' verwenden?

Zum Booten ist ein ada0s1a unerläßlich, weil Stufe 2 des Bootstrap-Codes ja hinter dem Superblock des Slices ada0s1 untergebracht sein muß und noch vor Beginn der Partition a, richtig?

Also: Der einzige Grund, warum man im Zeitalter von GPT einen Slice noch mit mindestens einer Partiton auskleiden muß, ist der Bootstrap-Prozeß. Eventuell könnte man in zukünftigen FreeBSD-Versionen die Komplexität des Ganzen um eine Schicht reduzieren und künftig nur noch mit Slices ohne Unterteilung arbeiten. Oder geht das bereits irgendwie?

Fragt sich
Tronar
 
Dort kann ich mal wieder meinen Lieblingsspruch unterbringen: Man muss es historisch betrachten. Ursprünglich lief BSD auf den PDP-Systemen von DEC und wurde später auf die VAX portiert. Beide Plattformen definierten kein vorgegebenes Partitionslayout, es war dem Betriebssystem überlassen wie die Festplatte oder ein andere Speichermedium unterteilt wurde. Dazu nutzte BSD das bsdlabel. Als BSD auf den Intel i386 protiert wurde, behielt man es bei und verfrachtete es in eine primäre MBR-Slice, da das PC-BIOS nur von MBR-Slice booten kann. Dadurch ergibt sich auch die doppelte Bootkette: mbr (für das BIOS) -> boot (für das bsdlabel) -> loader. Über die Jahre änderte sich daran nicht viel, eigentlich nur zwei Dinge:
- Die "d"-Partition wurde allgemein nutzbar.
- Statt 8 Partitionen sind bis zu 26 möglich.

Da bsdlabel maximal 2TB adressieren können und die umgebenden MBR-Slices recht frickelig sind, begann FreeBSD mit 7.0 langsam auf GPT umzusteigen. GPT bringt eine Reihe Vorteile:
- Theoretisch unbegrenzt viele Partitionen, praktisch meist 256.
- Wesentlich robuster als MBR, da 2 Tabellen genutzt werden.
- UUID anstelle der alten, oft mehrfach belegten Partitionscodes.
- Integrierter Bootmechanismus.
Um den Bootmechanismus zu nutzen, benötigt man ein EFI anstelle eines BIOS und einen EFI-Loader. Bei Windows wird sich an diese Regel gehalten, ein Windows kann von GPT nur mittels eines EFI booten. Linux, FreeBSD und einige andere haben aber zusätzlich einen Weg implementiert, um auch mittel BIOS von GPT booten zu können: Bei GPT ist der erste Sektor mit einem "Pseudo-MBR" belegt, damit klassische BIOSe die Platte nicht als leer erkennen, dort wird ein Bootcode hineingeschrieben -> Der Bootcode liest die GPT aus und sucht die Bootpartition. Ihr Inhalt wird in den RAM geladen -> Dieser Bootcode startet das System.

Für ein FreeBSD sieht es z.B. so aus:
Code:
yamagi@happy:pts/2 ~: gpart show ada0
=>       34  234441581  ada0  GPT  (111G)
         34       2014        - free -  (1M)
       2048        512     1  freebsd-boot  (256k)
       2560    2097152     2  freebsd-ufs  (1.0G)
    2099712    2097152     3  freebsd-ufs  (1.0G)
    4196864    2097152     4  freebsd-ufs  (1.0G)
    6294016   52428800     5  freebsd-ufs  (25G)
   58722816   62914560     6  freebsd-ufs  (30G)
  121637376  112804239     7  freebsd-ufs  (53G)

Man muss also nur:
1. Eine Partition vom Typ "freebsd-boot" anlegen. Sie muss vor 2TB liegen, damit das BIOS sie lesen kann. Eine Größe von 64k ist ausreichend, für die Zukunft kann aber etwas mehr nicht schaden. In diese Partition wird der gptloader geschrieben: "gpart bootcode -i $index -p /boot/gptboot $device". Für ZFS wird statt gptboot der gptzfsboot genommen.
2. Den Protective MBR durch den Bootcode austauschen: "gpart bootcode -b /boot/pmbr $device".
Anschließend kann das System von GPT booten. Das Root-Dateisystem mit dem Kernel sollte auf der ersten Partition vom Typ "freebsd-ufs" liegen. Tut es das nicht, kann man die entsprechende Partition mit dem "bootme" Attribut markieren: "gpart set -a bootme $index $device".
 
Wow, das war wieder mal eine geballte Ladung Wissen. Danke erst mal, aber laß mich nur klarstellen, ob ich das richtig verstanden habe:

Es war sogar einer der wesentlichen Gründe für die Einführung von GPT, die Beschränkung auf vier MBR-Slices zu überwinden und sich deren Unterteilung in Partitionen a,b,d,e,... zu ersparen.
Das grundsätzliche Problem des Bootens, nämlich den Zugriff auf das Dateisystem einer Partition zu bekommen, um den restlichen "loader" und den Kernel herauszuholen, wird elegant mit einer speziell organisierten Boot-Partition umgangen, die vermutlich kein richtiges Dateisystem enthält, sondern auf primitive Weise gelesen werden kann.
Der Boot-Code, den man in den MBR schreiben muß, hat nur zum Ziel, diese spezielle Boot-Partition zu finden und zu laden.
Wenn man z. B. Linux auf derselben Platte haben will, darf man aber den "protective MBR" nicht überschreiben, solange man keinen EFI benutzt.
Wenn man nicht GPT, sondern das altmodische MBR-Partitionierungsschema benutzt, braucht man ausschließlich für den Slice, von dem man bootet, ein "bsdlabel". Alle anderen Partitionen, sogar Swap, können einfach so, "roh", in den Slices liegen.

Soweit richtig?
 
Alles richtig. :)

Tronar schrieb:
Wenn man z. B. Linux auf derselben Platte haben will, darf man aber den "protective MBR" nicht überschreiben, solange man keinen EFI benutzt.
Das weiß ich ehrlich gesagt nicht. Eigentlich sollte es Linux aber völlig egal sein, was im pmbr steht, da er wirklich nur dazu dient, damit alte Partitionierungstools und co. die Platte nicht als leer sehen. Multiboot und GPT ist dann noch mal ein ganz anderes, ekliges Thema.
 
Zurück
Oben