GRUB, zerstörte Partitionen und Booten vom Netz

Booten übers Netz

Natürlich entschied ich mich für letzteres. Dazu mußte ich aber erst einmal einen angepaßten Kernel 2.2.14 erstellen, der alle Netzwerktreiber eingebaut anstatt als Module hat, NFS eingebaut, IP Autoconfig mit BOOTP, sowie NFS als Root-Filesystem. Eine halbe Stunde später war der Kernel fertig und auf Diskette kopiert.

Zum Booten übers Netzwerk muß zunächst der DHCP-Server konfiguriert werden, so daß der Client die richtigen Daten erhält. Dann muß man vom NFS-Server ein Root-Filesystem mounten. Es ist ungünstig, wenn dieses Dateisystem identisch ist mit dem des Servers, denn einige Konfigurationsdateien in /etc sind immer rechnerspezifisch, und diverse schreibbare Dateien in /var sollen auch nicht gemeinsam genutzt werden. Zum Glück hatte ich schon eine vorbereitete Mini-Root-Partition. Der erste Versuch, diese zu booten, ging natürlich daneben. Wie ich schnell feststellte, war eine veraltete Datei resolv.conf das größte Problem. Diese enthielt noch die IP-Adresse 10.0.0.2 für den Nameserver, während ich inzwischen auf 172.30.4.1 umgestellt hatte. Nach dieser und ein paar weiteren kleinen Korrekturen fuhr das System hoch. Ich konnte mich einloggen und das fdisk-Programm starten.

Die Rettung

Bis hierher hatte ich noch nichts gewonnen, denn die Partitionstabelle war immer noch zerstört und ich hatte keine Aufzeichnungen zu den genauen Daten der Partitionen gemacht. Dennoch war ich mir sicher, die Partition wieder herstellen zu können, und zwar aus folgenden Gründen:

Ich wußte noch, daß die Platte drei Partitionen enthalten hatte, wobei die ersten beiden je ca. 60 MB groß waren (evtl. sogar exakt gleich groß) und die dritte, fast 20 GB große Partition unter Kontrolle des LVM (Logical Volume Manager) stand.
Der Bootmanager hatte einen Teil der ersten Partition überschrieben, aber nicht die zweite. Das war verschmerzbar, da die erste Partition eine Swap-Partition war.
Die zweite Platte des Systems ist identisch zur ersten, nur sind die ersten beiden Partitionen zu einer zusammengefaßt. Daraus würde sich sofort die Größe der großen Partition ablesen lassen.

Also fdisk gestartet, die zerstörten Partitionen entfernt und neue entsprechend den obigen Überlegungen angelegt. Dann Reboot mit meiner alten Bootfloppy. Und es funktionierte! Alles war wieder da, nur die Swap-Partition nicht. Diese stellte ich dann von Hand wieder her:

swapoff -a
mkswap /dev/hda1 61456
swapon -a

Abschluß

Nun installierte ich GRUB nochmals, diesmal aber korrekt nach der Anleitung. Ich rief also grub auf und arbeitete mit den Kommandos kernel, root und setup. Dann bootete ich neu (ohne Floppy) und kam an den GRUB-Prompt, was mit LILO nicht funktioniert hatte. Am GRUB-Prompt mußte ich allerdings wieder die Kommandos angeben, die ich am Anfang schon einmal beschrieben habe. Geht das nicht einfacher?

Es geht. Man kann eine Datei /boot/grub/menu.lst anlegen, die einen ähnlichen Zweck erfüllt wie /etc/lilo.conf bei LILO. Bei mir sieht diese Datei jetzt so aus:

default 0 root (hd0,1)
kernel (hd0,1)/boot/vmlinuz-2.2.14
color light-gray/blue black/light-gray

Das Vorhandensein dieser Datei genügt GRUB bereits, eine Installation ist nicht nötig. Wieder einmal bootete ich neu, und erhielt ein Menü, das als einzige Auswahl "2.2.14" anbot. Drücken von ENTER oder Ablauf des Timeouts bootet dann den Linux-Kernel. Hervorragend! GRUB scheint schon jetzt weit besser als LILO zu sein, doch das ist Stoff für einen anderen Artikel.

Fazit

Was ich hier beschrieben habe, ist einmal mehr ein Paradebeispiel für die Flexibilität von Linux. Mit fast jedem anderen System wäre eine Neuinstallation und Datenverlust unumgänglich gewesen. Natürlich handelte es sich bei den fraglichen 6 GB nicht um unersetzliche Daten. Notfalls hätte ich auch auf sie verzichten können. Aber die allmähliche Wiederherstellung wäre aufwendig gewesen.

Natürlich hätte es auch gar kein Problem gegeben, wenn ich nicht bei der Installation von GRUB das falsche Kommando verwendet hätte. Aber solche Dinge passieren halt, und ich bin dank Linux recht gut dagegen abgesichert. Im Endeffekt habe ich nichts verloren außer ein wenig Zeit, und das ist verschmerzbar, wenn man bedenkt, daß ich den größten Teil der Zeit mit dem Erforschen von GRUB verbracht habe, das ich sowieso einmal testen wollte.

Und der abschließende Satz könnte lauten: Don't Panic! Selbst wenn ein Linux-System hochgradig zerschossen ist, ist manchmal Rettung möglich. Sehr viele Dinge lassen sich unter Linux ohne Neuinstallation und meist auch ohne Reboot reparieren. Gute Kenntnis des Systems und seiner Möglichkeiten ist natürlich Voraussetzung.