Standardmäßig kommen mit dem dist-upgrade ein neues udev, das die Umstellung von klassischen Gerätenamen (z.B. /dev/sda1) auf UUIDs als neuen Segen anpreist, sowie grub2, das sich zunächst (zu Recht) vorsichtig an Chainloading aus grub-legacy versucht und dann einen kompletten Umstieg (mittels update-from-grub-legacy) nahelegt.
Schön und gut, das hat in zwei VMs und auf zwei Rechnern zuvor auch einwandfrei funktioniert. Ein Fileserver hat aber mitunter mehr als nur eine Festplatte (in diesem Fall vier), und da fängt der Ärger auch schon an...
"dist-upgrade" war bis zu diesem Punkt inkl. grub2 einwandfrei durchgelaufen - nach dem fälligen Neustart nach Update von udev und Kernel wollte grub-legacy aber nicht mehr: "Error 17: Cannot mount selected partition." Also einen raschen Blick auf die gute, alte "/boot/grub/menu.lst" geworfen: Wieso steht da überall nur /dev/hda drin, obwohl ich doch schon auf UUID umgestellt hatte und außerdem nur SATA-Platten an Bord sind? Naja, was soll's - quick fix: die richtigen Einträge durch c&p der UUIDs aus /etc/fstab selbst zusammenbauen und schon funktionierts - Chainloading nach grub2 funktionerte zu diesem Zeitpunkt nämlich einwandfrei. Bereits hier fand ich seltsam, dass ich sda in grub zwar brav mit hd0, die Hauptinstallation unter sdb allerdings mit hd2 erreiche.
Also ein paar Tage später, als ich wieder Zeit hatte, sorgenfrei update-from-grub-legacy aufgerufen - dachte ich wenigstens... Nach dem Neustart erschien nämlich noch nicht mal mehr ein Bootmenü! Zum Glück gibt es heutzutage ja Rescue-CDs, die einem im Bootmenü gleich alle lokal installierten Linux-Versionen (/boot/grub/stage*) gleich mitanzeigen und dafür sorgen, dass der Fileserver auch ohne funktionierenden Bootloader verfügbar bleibt - kein schöner Zustand freilich.
Zunächst musste ich mich erst mal in grub2 eindenken: statt der handlichen menu.lst gibt es nun im selben Verzeichnis eine grub.cfg, die zwar alle nötigen Einträge zum Booten und jede Menge Intelligenz (Skripte) in sich trägt, aber nachdrücklich davor warnt, editiert zu werden. Also schön: Der Befehl "update-grub" sorgt offensichtlich nun dafür, dass alle nötigen Informationen in der grub.cfg zusammengetragen werden - die liegen verteilt:
- /etc/default/grub enthält ein nur ein paar Basisparameter: welches ist der Standardeintrag im Bootmenü, wie lange warten vor automatischem Booten, welche Auflösung hat die Grub-Konsole etc.
- Im Ordner /etc/grub.d/ liegen dagegen alle Informationen (wiederum teils in Skriptform), aus denen grub.cfg zusammengebaut wird - die Ziffern am Anfang jeder Datei regeln dabei in aufsteigender Ordnung die Verarbeitungsreihenfolge (das ist jetzt einfacher als vorher, weil??) Immerhin gibt es hier einen verheißungsvollen Dateinamen "40_custom" (also ganz am Ende, wenn alles andere schon verarbeitet wurde).
So weit so gut - wenn nicht in grub.cfg wiederum die hässlichen /dev/hda-Einträge (die mir sehr nach einem template aussehen, das ich bis jetzt nicht gefunden habe) gestanden hätten. Also die Radikalkur: grub2 mittels "apt-get install grub" (das alte heißt jetzt ja grub-legacy) komplett neu installieren. Das funtionierte nun einwandfrei, "update-grub" lieferte jetzt auch brav automatisch alle installierten Systeme (einschließlich des alten SUSE 10, mit dem ich mal angefangen habe und das ich bei der Umstellung auf Debian nach und nach bezüglich der Config-Dateien ausgeschlachtet habe, bis alles lief). Also freudig auf Neustart geklickt - und wieder nichts!
Ach ja, da war ja noch der seltsame Fehler, dass sdb im BIOS hd2 heißt - da hilft auch grub2 im laufenden System seine ganze Intelligenz nichts, das zu antizipieren. Also den "best fit" unter den Einträgen in grub.cfg nach 40_custom kopiert und dort einen einzigen, aber entscheidenden Buchstaben verändert, den Standardeintrag in /etc/default/grub angepasst und noch mal update-grub aufgerufen, um die Änderungen zu propagieren, wieder der bange Moment des Neustarts und juhu, endlich wieder Zeit für andere Dinge
Keine Kommentare:
Kommentar veröffentlichen