Vom Bootloader zum eigenen OS

Vom Bootloader zum eigenen Betriebssystem

GRUB hat damit fast den Sprung zum eigenen Betriebssystem gemacht. So drängt sich beinahe der Vergleich mit DOS auf, das den umgekehrten Weg ging und seit Windows 95 vom vollwertigen Betriebssystem zum Bootloader degradiert wurde. Mit der neuen Modularität sind mittelfristig auch grafische, per Maus bedienbare Auswahlmenüs oder integrierte Speicher- oder Festplattentests denkbar.

Vergleicht man die schiere Größe einer vollwertigen GRUB-Installation mit insgesamt zirka 2,7 MByte bei Ubuntu mit den wenigen Hundert Kilobyte eines nackten DOS, hat GRUB 2 bereits in Sachen Größe und natürlich Hardware-Unterstützung die Nase vorn.

Neu ist auch die Möglichkeit, endlich eine simple Scriptsprache zu verwenden, die Einträge in Abhängigkeit der Anwesenheit von Dateien verändert oder welche die Verwendung von Variablen möglich macht. Die hierbei verwendete Syntax lehnt sich an die altbekannte Unix-Shell sh an. Wer es umfangreicher haben möchte, findet mit dem lua-Interpreter eine Scriptsprache, die alles bislang von Bootloadern Bekannte in den Schatten stellt.

Die Praxis aktueller Linux-Distributionen

Ein großes Problem bei GRUB Legacy war die monolithische Konfigurationsdatei bei den meisten Linux-Distributionen. Eine einzige Datei menu.lst enthält hier die Einträge aller Kernel und Drittbetriebssysteme. Standard- und abgesicherte Bootparameter werden in distributionsspezifischen Kommentaren abgelegt.

Passt man die von den Scripten der Distribution erzeugte Konfiguration an - beispielsweise um einen neuen Kernel hinzuzufügen, der abweichende Bootparameter erfordert - ist viel Vorsicht im Umgang mit den bereits existenten Einträgen nötig, damit nach Updates die Scripte zur Aktualisierung der GRUB-Konfiguration sauber ausgeführt werden können.

Als Abhilfe speichern Ubuntu und andere Distributionen nun die GRUB-Konfiguration als einzelne Fragmente im Ordner /etc/grub.d. Aus diesen wird beim Kernel- oder Konfigurations-Update dann die eigentliche Konfigurationsdatei /boot/grub/grub.cfg erzeugt.

Dieses Schema erlaubt es Nutzern, die verschiedene Linux-Distributionen parallel nutzen, die Bootloader-Konfiguration der anderen leichter einzulesen und so Updates einfacher handzuhaben. Sollten Sie GRUB auf einem reinen Windows-Multiboot-System einsetzen wollen, können Sie diese Information getrost ignorieren: Hier ist die manuelle Erstellung der grub.cfg der richtige Weg.

Ein Problem von GRUB 2 ist, dass es sich um eine unfertige Entwicklerversion handelt. Dieser Umstand ist unter anderem den Distributoren wie Canonical geschuldet, die durch den Umstieg auf GRUB 2 Entwickler und Community dazu bewegen wollen, ihren Fokus auf die neue Version zu legen.

Das führt zu der nicht ganz angenehmen Situation, dass GRUB 2 stark in Bewegung ist und Updates des Bootloaders Änderungen an der Konfigurationssyntax sowie am Verhalten einzelner Module nach sich ziehen. Dieses Problem dürfte kaum die "typischen" Funktionen betreffen, die wir in unserem Beispiel verwenden, um mehrere Windows-Installationen voreinander zu verstecken.

Eine Folge der sehr aktiven Weiterentwicklung von GRUB 2 mit ständigen Änderungen an der Funktionsweise ist die derzeit noch magere Dokumentation. Ein Teil der Funktionalität - unter anderem die Auswertung von Konfigurationsparametern - erschließt sich erst durch den Blick in die Quellcodes, wozu eine gewisse Portion Erfahrung, aber auch eine Prise Masochismus vonnöten sind.

Die Endbenutzerdokumentation in Form des GRUB-Wikis oder den Wikis der Distributoren konzentriert sich noch auf häufig genutzte Features und Funktionen. Immerhin beginnen Foren und Blogs sowie der eine oder andere Zeitschriftenartikel, diese Lücke zu schließen.