Grand Unified Bootloader
| Allgemeines | |
|---|---|
| Name: | GRand Unified Bootloader |
| Entwickler: | - |
| Akt. Version: | 0.97 (GRUB legacy) 1.98 (GRUB2) |
| Lizenz: | GNU GPL V 2 (GRUB legacy) GNU GPL V 3 (GRUB2) |
| Plattform: | Unix |
| Homepage | |
Der GRand Unified Bootloader (GRUB) ist ein Multiboot-konformer Bootloader der ursprünglich aus dem GNU-Hurd-Projekt entstammt, aber inzwischen bei allen gängigen Linux-Distributionen als Bootloader eingesetzt wird. Im Falle der Betriebssystementwicklung ist es empfehlenswert GRUB den Kernel booten zu lassen, da GRUB sehr flexibel ist und einen großen Funktionsumfang bietet (siehe Abschnitt Warum GRUB?).
Inhaltsverzeichnis
Warum GRUB?
Im Forum und hier im Wiki wird von den meisten GRUB empfohlen und selbst verwendet. Außerdem benutzen die Tutorials im Wiki (größtenteils) GRUB. Dies geschieht aus folgenden Gründen:
- Einen Bootloader zu schreiben setzt tiefergehende Assemblerkenntnisse voraus. Falls man diese noch nicht hat, dann wird man sehr wahrscheinlich am Bootloader scheitern oder aber einen Teil/den größten Teil aus anderem Quellcode zusammenkopieren.
- Dabei kommen dann fehleranfällige Bootloader heraus, von denen der jeweilige Programmierer meist nicht weiß, was sie genau machen (z. B. in welchem Dateiformat der Kernel sein muss, an welche Adresse der Kernel geladen wird oder wie viel vom Kernel überhaupt geladen wird) und im Forum werden dann Threads mit 500 Zeilen zusammengefrickelten Assemblercode und der Frage „Warum funktioniert denn das nicht so, wie ich das will!?“ erstellt. Der Punkt hier ist nicht, dass wir zu faul wären Fragen zu beantworten, sondern, dass es einfach nichts bringt einen eigenen Bootloader zu schreiben, wenn derjenige nicht einmal im Ansatz verstanden hat, was er denn da überhaupt tut. Das ist dann für uns primär frustrierend.
- Diese Fehleranfälligkeit kann auch dazu führen, dass das ganze eine Weile funktioniert, aber irgendwann tauchen plötzlich seltsame Fehler auf. Dies kann unter anderem den Grund haben, dass nicht der komplette Kernel geladen wird, sondern z. B. nur die ersten paar Kilobyte. Solche Fehler sind meist extrem schwer zu debuggen.
- Eventuell tauchen später auch neue Anforderungen an den Bootloader auf, z. B. könnte man bei einem Mikrokernel durch den Bootloader Module (meistens Treiber) laden wollen. Dann wird entweder versucht das schnell hinzufrickeln oder aber man entscheidet sich dann doch gegen einen Mikrokernel, d. h. es kann Auswirkungen auf das Design des Kernels haben.
- Falls man allerdings von Anfang an intensiv seinen Bootloader plant – was einem Anfänger aufgrund mangelnder Erfahrung verwehrt bleibt – und diesen sehr gewissenhaft programmiert, dann ist das ein Projekt für sich, d. h. es wird Unmengen an Zeit verschlucken (wir reden hier nicht von Tagen oder Wochen).
- Der Bootvorgang auf x86-Prozessoren hat so manches Hindernis, welches von Intel und Konsorten gerne aufgrund von Abwärtskompatibilität aufgestellt wurde. Beispiele hierfür sind der Real Mode (der Bootloader startet im Realmode) und das A20-Gate, welches aktiviert werden muss.
Wir möchten natürlich dem geneigten Leser nicht vorenthalten, was genau er denn verpasst, wenn er GRUB benutzt:
- Eine eingehende Beschäftigung mit dem Real Mode bleibt wahrscheinlich aus (oder kommt erst, wenn man sich mit dem Virtual 8086 Mode beschäftigt).
- Assemblerkenntnisse zu erlangen auch für den Kernel bzw. darüber hinaus fürs Debuggen wichtig, da z. B. im Kernel an einigen kleinen Stellen Inlineassembler verwendet werden muss.
GRUB legacy
GRUB legacy ist die ursprüngliche Version von GRUB und wird unter der GNU General Public License vertrieben. Wie man einen Multiboot-Kernel erstellt, der mit GRUB gebootet werden kann, wird im Artikel OS-Dev für Einsteiger - Teil 4 beschrieben.
Funktionen
- Liest ext2, ext3, UFS, UFS2, ReiserFS, FAT, NTFS, ISO9660, JFS, Minix, FFS, XFS
- Auswahlmenü um verschiedene Betriebssysteme zu laden.
- Bootet von Disketten, Festplatten, CDs, DVDs und Flashdisks.
- Beinhaltet eine Shell
- Kann mit einem Passwort gesichert werden
- Kann von einem TFTP-Server booten
Disketten image herstellen
Linux
Achtung!
Funktioniert nur wenn GRUB legacy auf dem Hostsystem installiert ist.
Wir brauchen also zunächst einmal ein Image:
# dd if=/dev/zero of=test.img bs=1024 count=1440 # mkdosfs test.img
Danach muss dieses Image gemountet und alle nötigen Dateien auf das Image kopiert werden werden:
# sudo mount -oloop test.img /mnt # mkdir /mnt/grub # cp /boot/grub/stage* /mnt/grub # cp kernel /mnt # umount /mnt
Anschließend das Image noch bootbar machen:
# grub grub> device (fd0) test.img grub> root (fd0) grub> setup (fd0) grub> quit
Windows
Achtung!
Funktioniert nur mit GRUB4DOS, nicht aber mit GRUB/GRUB2!
Es sind folgende Tools vonnöten:
- BFI (Build Floppy Image)
- GRUB4DOS
- Virtual Floppy Drive
Wir brauchen also zunächst einmal einen Ordner. In desen Ordner kommt die Datei grldr(GRUB4DOS Stage2). Aus diesem Ordner machen wir jetzt ein Iamge.
bfi -t=144 -f=floppy.img floppy
Erstellt die Datei floppy.img mit dem Inhalt des Ordners floppy.
Nun muss GRUB nur noch auf dem Image installiert werden und das Image Bootfähig gemacht werden. Das geschieht mit diesem Befehl:
bootlace.com --fat12 --floppy floppy.img
Installiert GRUB-stage1 in den Bootsektor des Floppy Images
Nun kannst du das Image mit VFD mounten und deinen Kernel und eine menu.lst(Die GRUB konfigurationsdatei) auf das Image kopieren.
CD-Image herstellen
Linux
Es sind folgende Dinge vonnöten:
- stage2_eltorito von GRUB(Sollte bei deinem Linux dabei sein.)
- mkisofs
Als erstes sollte man die Dateien, die nachher auf der CD landen sollen, in einen Ordner stecken. Dazu gehören auch die von GRUB benötigten Dateien und zwar menu.lst und stage2_eltorito. Diese gehören in den Ordner (relativ von der CD aus) /boot/grub/. Man kann sie auch in einen beliebigen anderen Ordner packen, dann muss man allerdings mit den Hexeditor an stage2_eltorito. Wenn die Dateien dann alle fertig sein, baut man das CD-Image. Das geht folgendermaßen:
mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o cdrom.iso cdrom_files/
Dies erzeugt ein CD-Image namens cdrom.iso aus den Dateien des Ordners cdrom_files. boot/grub/stage2_eltorito ist dabei ein relativer Pfad von der CD aus auf den Bootloader.
Mögliche Probleme:
- Die menu.lst kann nicht geladen werden, d.h. es erscheint nur der GRUB-Prompt. Schuld an diesem Fehler ist ein falscher Pfad in stage2 (der Pfad ist Lowercase, aber ISO-Level-1 speichert nur Uppercase). Abhilfe schafft entweder GRUB gepatcht neu bauen, oder einfach den Pfad im Binary zu ändern:
sed -i "s/boot\/grub\/menu.lst/BOOT\/GRUB\/MENU.LST/g" stage2_eltorito
- Es gibt Systeme die nicht von ElTorito-CDs booten können. Abhilfe schafft hier manchmal, statt ElTorito die Floppyemulation zum Booten zu verwenden. Einfach ein Floppyimage mit allen benötigten Treibern erstellen, welches dann von CD weiterlädt. Das CD-Image hierfür wird dann via
mkisofs -b floppy.img -o cdrom.iso cdrom_files/
erstellt. ACHTUNG, man braucht wenn man nicht alles im Speicher hat wirklich eigene Treiber, das Floppy-Image ist ab Protected Mode verloren (es werden Interrupts umgeleitet).
Beispielkonfigurationsdatei
title OS_Name
kernel /kernel
module /modul.mod
boot
Diese Beispielkonfigurationsdatei lädt die Datei kernel aus dem Wurzelverzeichnis als Kernel in den Speicher, lädt die Datei modul.mod als Modul in den Speicher und führt den Kernel danach aus.
GRUB 2
GRUB 2 ist der Nachfolger von GRUB legacy und wurde von Grund auf neu geschrieben. Er ist genauso wie GRUB legacy multibootfähig. Außerdem wird mit GRUB 2 der Multiboot-2-Standard, der sich momentan noch in Entwicklung befindet, unterstützt.
Neuerungen gegenüber GRUB Legacy
GRUB 2 weist eine Vielzahl an Neuerungen auf:
- Scripting-Support mit Lua
- Grafische Benutzerschnittstelle (nicht mit einer klassischen GUI bzw. einem Desktop zu verwechseln!)
- Dynamisches Laden von Module auch während der Laufzeit
- Unterstützung neuer Architekturen
- Internationalisierung
- Modulares und objektorientiertes Framework für Dateisysteme etc.
- Cross-Plattform-Installation
Beispielkonfigurationsdatei
menuentry "OS_Name"
{
multiboot /kernel
module /modul.mod
boot
}
Diese Beispielkonfigurationsdatei lädt die Datei kernel aus dem Wurzelverzeichnis als Kernel in den Speicher, lädt die Datei modul.mod als Modul in den Speicher und führt den Kernel danach aus.
Siehe auch
- GRUB legacy
- OS-Dev für Einsteiger - Teil 4: kleiner Beispielkernel mit Multiboot
- GRUB-Image erstellen
- GRUB-Image erstellen (Windows)
- GRUB auf CD
- GRUB Installation auf einem USB-Stick
- GRUB 2