GPT und grub für Noobs

Dies ist die Geschichte einer Nachtschicht (ja, der Noob aus dem Titel bin ich). Übeltäter war ein recht frisch installierter Sabayon-Rechner, der plötzlich nicht mehr booten wollte. Der Rechner kam noch bis zu den vier Buchstaben GRUB, dann rührte sich nichts mehr. Nach einer Kernel Panic beim Versuch, den Rechner mit Hilfe eines von einer CD gestarteten GRUBs (grml ftw!) zu booten, war schon am Fluchen über vermeintlich defekte Hardware. Letztendlich war (m)ein Fsckup bei der Installation von GRUB2 auf der mit GPT organisierten Platten das Problem.

Der gute alte MBR hat nun 30 Jahre auf dem Buckel und hat sich damit für IT-Verhältnisse extrem gut gehalten... die Grenzen sind aber spätestens mit den heutigen Plattengrößen erreicht. GPT bietet eine faktisch unlimitierte Menge an (primären) Partitionen und verwaltet Platten weit jenseits der Petabyte-Größe. Und wer EFI benutzt, hat ohnehin keine andere Wahl :-)

Ich habe keine Ahnung, ob mir das der Sabayon-Installer eingebrockt hatte oder ob das mein persönlicher Verbock war. Meine GPT hatte zwei Einträge: Eine kleine Partition für /boot sowie den Rest der Platte für Linux-LVM, also so, wie man das früher(tm) immer(tm) gemacht hat. Rückblickend frage ich mich, wie das jemals funktionieren konnte ;-) Der Verdacht dämmerte, als Versuche, GRUB neu zu installieren, mit einer Fehlermeldung quittiert wurden.

Für GRUB auf GPT benötigt man 2 Partitionen: Eine winzige Partition, auf welche GRUB sein boot.img schreiben kann, sowie eine weitere, auf welcher die restlichen Daten von GRUB liegen. boot.img sorgt für den Einsprung in den eigentlichen Bootloader. Es hat noch keinerlei Verständnis von Dateisystemen o.ä., weshalb die Einsprungadressen hier hartcodiert stehen. Bei der Verwendung von MBR wurde das boot.img direkt in den MBR geschrieben... bei GPT bekommt die Datei ihre eigene Partition.

Man legt also mit parted zwei Partitionen an:

  • Eine winzige mit minimaler Größe. Diese bekommt das Label "BOOT_GRUB" und das Flag "bios_grub". Diese wird anschließend mit FAT formatiert.
  • Eine kleine Partition (wenige hundert MB) für /boot, wie früher. Diese erhält das Label "GRUB_FILES". Ich habe sie mit ext2 formatiert.

grub-install fühlt sich mit diesem Setup wohl und erledigt die Installation automatisch. In meinem Fall hatte ich aber bereits eine erste Partition... das Problem ließ sich aber mit einem minimal-invasivem Eingriff reparieren :-)

  • Daten aus dem alten /boot sichern
  • Partition löschen
  • In dem freien Bereich am Anfang der Platte als erstes die Partition für BOOT_GRUB anlegen
  • Im restlichen Platz eine Partition für das neue /boot anlegen
  • Die neuen Partitionen formatieren, die Daten in das neue /boot zurückspielen

Nun noch grub-install starten - und aufatmen! Da sich nun die IDs der Partitionen geändert haben, muß man (zumindest bei Sabayon) die grub.cfg mittels "grub-mkconfig > /boot/grub/grub.cfg" neu erstellen. Außerdem muß man auch den Eintrag für /boot in /etc/fstab anpassen.

Woher die Kernel Panic beim ersten Startversuch mit einem von einer Boot-CD gestarteten GRUB kam, weiß ich nicht genau... möglicherweise hatte ich mich da bei den Kernelparametern (initrd? root? dolvm?) vertan. Bei allen weiteren Versuchen tat's jedenfalls. Und der Grund für das plötzliche Auftreten des Problems ließ sich anhand der Logs ebenfalls rekonstruieren: Vor dem letzten Herunterfahren hatte ich Systemupdates installiert. Und da kam unter anderem ein neuer Kernel mit - der hat vermutlich dafür gesorgt, daß irgendwelche Byteoffsets von GRUB nicht mehr paßten...