SuSE und Grub

Hinweis: Dieser Artikel handelt explizit von der Version GRUB Legacy. Das Programm wurde weiterentwickelt. Die Weiterentwicklung wird aufgrund von Inkompatibilitäten auf einer eigenen Seite behandelt: GRUB 2

SuSE und Grub

Der Bootmanager GRUB der ab SuSE Linux Version 8.1 der Standard Bootmanager geworden ist, ist ein äußerst flexibler und vielseitiger Bootmanager mit unzähligen Möglichkeiten, und deshalb sicherlich auch so oft eingesetzt und beliebt. Im Forum gut nachzuvollziehen scheinen sich hin und wieder Probleme mit Grub allerdings etwas häufen, was mich bewogen hat einmal näher hinzuschauen. Hier jetzt mal ein paar allgemeine Weisheiten und Erkenntnisse als "Gute Nacht Lektüre" niedergeschrieben. Unter dem Motto: "man sollte es mal gelesen haben".

Grub und YaST2

Unter SuSE wird YaST zur Systemkonfiguration verwendet. Dazu wurden eine ganze Reihe von Verwaltungs- und Konfigurationsmodulen erstellt, die das Leben unter SuSE übersichtlich, bequem und unkompliziert auch für weniger Erfahrene macht. Auch für den Bootmanager gibt es so ein Modul. Es ist zu erreichen über das YaST-Kontrollzentrum -> System -> Konfiguration des Bootloaders, oder als Root aus einer Konsole mittels der Befehle yast bootloader und das grafische Äquivalent dazu yast2 bootloader

YaST ändert Einstellungen am System nicht selbst, sondern bedient sich dabei der Konfigurationsbefehle der einzelnen installierten Softwarekomponenten oder ändert dazu die Konfigurationsdateien dieser Pakete um danach durch neu- oder restarten der entsprechenden Programme die Änderungen am System auszuführen. Auch bei der Konfiguration von GRUB benutzt man diese Strategie.

Stellt sich als nächstes die Frage welche Konfigurationsdateien und Konfigurationsbefehle bringt Grub mit.

die Dateien von GRUB

Ein Blick in das Paket von Grub zeigt etwa 40 Dateien. Zieht man einmal die ganzen Manpages, Infoseiten und Dokumentationen ab, dann bleiben im wesentlichen 2 Dateigruppen übrig.

Imagedateien 

hier handelt es ich um die Dateien die während des Startens des Rechners geladen werden.

• stage1 das ist Bootloader für den Start
• irgendwas_stage1_5 das sind kleine Unterstützungsimages die helfen direkt aus jeweils einem Filesystem zu lesen.
• stage2 und einige seiner Abkömmlinge für spezielle Bootaufgaben, das ist der eigentliche Grub in Form einer universellen Shell.

Der größte Teil dieser Images wird bei der Installation von Grub zusätzlich nach /boot/grub kopiert.

Ausführbare Dateien

• das Programm /usr/sbin/grub das ist eine Emulation der eigentliche Grub-Shell
• das Script /usr/sbin/grub-install ein Hilfsscript zu Konfiguration und Installation
• 2 oder 3 kleine Hilfstools für spezielle Aufgaben

Das Programm /usr/sbin/grub ist bei näherer Betrachtung wirklich nur eine anders kompilierte Form von stage2, es arbeitet nicht über die BIOS-Zugriffe sondern über Linuxfunktionen hat aber den gleichen Funktionsumfang wie stage2. Die meisten Installationen eines Bootloaders, (Ausnahme zB bootbare Floppy oder CDs) können gar nicht anders als mit Hilfe der Grubshell oder deren Emulation dem Programm /usr/sbin/grub installiert werden. Das liegt daran das in den Images (Stage-Dateien) die dabei auf den Festplatten zB im MBR positioniert werden, kleine Änderungen an internen Variablen innerhalb der so installierten Images vorgenommen werden müssen. Sonst funktioniert das Ganze dann nicht, weil die Dateien über die BIOS-Zugriffe nicht gefunden werden.
Solche Anpassungen kann nur Grub selbst zuverlässig erledigen. Das ist auch die Ursache dafür, dass man einen Bootloader nicht einfach von einem System auf ein anders System kopieren kann. Dieser würde nicht mehr funktionieren, sobald sich die stage1_5 und stage2 Dateien nicht mehr innerhalb des in stage1 konfigurierten Datenblockes befinden. Auch bei einem Filesytemwechsel des Filestems auf dem sich diese Dateien befinden (/boot/grub)funktioniert der alte Grub nicht mehr, da auf ein anderes Stage1_5 Image verlinkt werden muss.

Das Script /usr/sbin/grub-install ist eine Konfigurationshilfe die notwendige Optionen entweder aus übergebenen Argumenten oder aus dem derzeitig aktuellen System heraussucht und damit über das Programm /usr/sbin/grub die einzelnen Komponenten des Bootloaders neu konfiguriert und installiert.

Achtung:

das Script /usr/sbin/grub-install ist Bestandteil des Orginalprogrammes GRUB. In den SuSE-Versionen ab 10.3 heißt dieses Script /usr/sbin/grub-install.unsupported, ein Script Namens /usr/sbin/grub-install gibt es aber auch dort, das macht jedoch intern etwas anderes, siehe weiter unten

Konfigurationsdateien

Der größte Teil der Imagedateien wird per default in das Verzeichnis /boot/grub/ kopiert. Ebenso werden dort für Grub 2 wichtige Konfigurationsdateien bei der Installation angelegt.

• /boot/grub/device.map Diese Datei wird von der Grubshell selbst erzeugt und spiegelt die vom BIOS gegebene Reihenfolge der Platten wieder.
• /boot/grub/menu.lst Das ist die Konfigurationsdatei in der festgelegt wird, was wie zu booten ist. Sie wird bei der Paketinstallation erst einmal auf eine einfache aber ziemlich universelle Grundkonfiguration gesetzt.

Die device.map sollte man überhaupt nicht verändern, sondern als das behandeln was es ist, eine vom System-BIOS vorgegebene Konfiguration. Bei einigen Operationen wird diese Datei neu von /usr/sbin/grub erzeugt, das ist aber im Normalfall auf einem Rechner sehr selten, so dass es uA. nach Plattenerweiterungen oder Kontrollerumbauten an einem Rechner dazu kommt, dass nicht alle vorhanden Platten hier in dieser Datei eingetragen sind oder ihre Reihenfolge falsch ist. Muss aus diesen oder ähnlichen Gründen einmal diese Datei entsprechend den aktuellen Gegebenheiten angepasst werden, so reicht es aus, die alte Datei umzubenennen oder zu löschen. Danach nur einmal die Grub-shell durch das Kommando "grub" aufzurufen und wieder mit "quit" zu verlassen. Dabei wird dann automatisch eine Neue und jetzt wieder aktuelle device.map erzeugt.

Die menu.lst kann universell und zu jeder Zeit nach Herzenswünschen angepasst und geändert werden, solange dabei die Syntax und die Logik ok sind, funktioniert's oder manchmal auch nicht. Die Änderungen an dieser Datei werden sofort beim nächsten Boot wirksam, da diese Datei beim booten über ihren Namen gesucht und ausgelesen wird.

Dateien von YaST

Das Bootkonfigurationsmodul von YaST kann also auch nur über das Programm /usr/sbin/grub einen Bootloader schreiben, und es kann nach Herzenslust die /boot/grub/menu.lst ändern. An der device.map ändert Yast ohne ausdrückliche Aufforderung dazu nichts, benötigt diese Datei aber natürlich zur Zuordnung der Platten zur Erstellung der SYNTAX für grub. In den Konfigurationsdateien von Grub ist nirgends einen Eintrag enthalten, wo denn nun der aktuelle Bootloader hingeschrieben worden ist. YaST benötigt jedoch diese Information, desshalb wurde eine zusätzliche Datei benötigt, in der vermerkt ist, wo der aktuelle Bootloader mit welchen Optionen hingeschrieben wurde. Dazu hat man die Datei /etc/grub.conf erfunden. (unterhalb /etc/sysconfig gibt es zwar auch einen Konfigurationseintrag wo der Bootloader hingeschrieben werden soll, wird aber zumindestens bei Grub scheinbar nicht benutzt.)

Die /etc/grub.conf

Im strengen Sinne ist diese keine Konfigurationsdatei sondern ein Script das in der Grub-Shell ausgeführt wird. Es gibt auch keine Manpage dazu und nur in ganz wenigen offiziellen Dokumenten ist diese Datei auch nur ansatzweise erklärt. Die Datei könnte folgendermaßen aussehen.

setup --stage2=/boot/grub/stage2 (hd1) (hd1,1)
quit

Das ist die Syntax der Grub-Shell und wird wie folgt ausgeführt

grub --batch < /etc/grub.conf

Das bedeutet hier im Beispiel im Klartext "installiere den Grub im MBR der 2. Festplatte und die Konfigdateien und stage2 liegen auf der 2. Festplatte innerhalb der 2. Partition." ( Die Option --stage2=.... ist eine eventuell unbedeutende oder zusätzliche Option, die in der Dokumentation von Grub als notwendig unter bestimmten Bedingungen beschrieben ist, jedenfalls hat sie auf die Konfiguration keinen direkten Einfluss.)

Die Datei ist seit Urzeiten in allen SuSE Rechnern vorhanden und kaum jemand hat sie je zur Kenntnis genommen, sie wurde bisher auch nur von YaST benutzt.

Bis -- Version OpenSuse 10.3 dort wurde von SuSE das Script /usr/sbin/grub-install in /usr/sbin/grub-install.unsupported umbenannt und statt dessen ein Script mitgeliefert.

 cat /usr/sbin/grub-install
#!/bin/sh

# Instead of the unsupported guessing method of the original grub-install
# script, use the grub installation scriptlet generated by YaST.

# Sanity check
test -x /usr/sbin/grub && \
    grep -q quit /etc/grub.conf 2>/dev/null && \
    grub --batch < /etc/grub.conf && exit 0

# Sanity check failed -- call YaST2
/sbin/yast2 bootloader

# Try again. This time it must succeed, otherwise return the error.
grub --batch < /etc/grub.conf 

Diese Script macht also weiter nichts, als diese /etc/grub.conf in der grub-shell auszuführen oder wenn sie nicht vorhanden ist, dann die Bootloaderkonfiguration von YaST2 aufzurufen.

Da in vielen Howtos /usr/sbin/grub-install verwendet wurde, um zB. gezielt den Bootloader an eine bestimmte Position zu positionieren, und das Script jedoch stillschweigend etwas ganz anderes tut, gab es prompt auch eine Bug-Meldung

YaST und sein Verständnis von GRUB

GRUB ist in seinem Umfang so gewaltig, das YaST nur einen winzigen Bruchteil davon überhaupt unterstützen kann. Nun ist es ja so, auf vielen Rechnern wird man GRUB nur einmal bei der Installation konfigurieren und installieren (meistens überlässt man das sogar der Installationsroutine, auch YaST) und nie wieder anfassen müssen und die Bootkonfiguration ist auf den meisten Rechnern auch so einfach, dass YaST das problemlos beherrscht und somit auch ein Kernelupdate oder ein ganzes Betriebssystemupdate problemlos durchläuft, aber eben nur auf den meisten Rechnern.

Was YaST nicht versteht wird gnadenlos umkonfiguriert

Nun ist es ja so, dass YaST in der /boot/grub/menu.lst seine Menueinträge mit der Zeile

###Don't change this comment - YaST2 identifier: Original name: irgendwas ###

kennzeichnet. Jetzt ist man geneigt, anzunehmen, dass YaST Menueinträge ohne diese oder mit einer stark geänderten Kommentarzeile nicht anfasst. Das stimmt aber nur zum Teil und man sollte sich keineswegs darauf verlassen. Bei Versuchen unter 10.3 konnte mit einer Dualbootkonfiguration nachgewiesen werden, dass es dem YaST Bootkonfigurator vollkommen wurscht ist, was dort steht, "Was ich nicht verstehe wird so umkonfiguriert, dass ich es verstehe". YaST war nicht einmal in der Lage innerhalb des Bootloadermodules die orginalen Konfigurationsdateien anzuzeigen. Angezeigt wurden immer nur die schon von YaST umgeänderten Konfigurationen, auch ein manuelles Ändern an den Konfigurationsdateien innerhalb von YaST brachte keinen Erfolg. Die von YaST vorgenommenen Änderungen betrafen dabei nicht die Kernel-Optionen oder ähnliches, sondern in erster Linie nur die Parameter mit denen die Platten und Partitionen benannt werden. Auch mehrere in Grub gültige Syntax für die eindeutige Benennung von Platte und Partitionen wurden permanent geändert. Nach betätigen mit "OK" wurden von YaST ohne irgend eine Warnung stillschweigend eine solche manuelle Änderungen verworfen und auf etwas "normales" Yast-verträgliches geändert.

Wenn man also eine per Hand erstellte Grubkonfiguration hat, die Elemente enthält die Yast nicht unterstützt, Kann uU ein Aufrufen des Bootloadermoduls und anschließen "Beenden" ausreichen, um seine Grubkonfiguration zu verschrotten und auf einen quasi YaST verträglichen Standard zurück zu konfigurieren. Man braucht innerhalb des Bootloaders nicht mal irgendwas angefasst/angeklickt zu haben, das öffnen und anschließende bestätigen reicht aus. Nur ein "Abbrechen" mit anschließendem Bestätigen des Abbruchs schützt vor ungewollter Veränderung durch den YaST Bootloader. Dabei was es vollkommen egal wie die Menüpunkte Kommentiert waren, und ob sich original YaST Einträge in der Datei befunden haben oder nicht. Knackpunkt bei den gemachten Versuchen und Tests, YaST konnte überhaupt nicht begreifen, dass es auf dem System auch 2 mal die /boot/grub/Dateien geben kann, eben auf jeder gespiegelten Rootplatte ein mal. Auch eine entsprechende Änderung an der /etc/grub.conf wurde von YaST auf ein für ihn verständliches Niveau umkonfiguriert.

Andere Fehler in dieser Datei, wie etwa Verweise auf nicht mehr existierende Kernelversionen und der gleichen, in original Yasteinträgen, hat YaST dann mal großzügiger Weise überhaupt nicht bemerkt.

Getestet wurde das mit 10.3 und der menu.lst von diesem Howto

Desweiteren konnte damit nachgewiesen werden, dass hier YaST viel öfter den Bootloader neu installiert als man sich das denken kann. Man braucht sich nur dort im YaST-Bootloader ein wenig umzusehen, zB die Konfigurationsdateien und anschließend ohne das man irgendwas geändert hat, auf "Beenden" und schon wird die /etc/grub.conf durch /usr/sbin/grub geschickt. Das die /etc/grub.conf vorher automatisch und unbemerkt von YaST geändert wurde, und das System hinter nicht mehr von allen Booteinträgen bootbar war, war YaST dabei egal.

Bei einem anderem Test mit gleicher Datei und einem Kernelupdate über YaST waren die Fehler nicht gar so drastisch, aber das Ergebnis keinesfalls perfekt. Da keine YaST-Menueinträge vorhanden waren, wurden eben 2 neue erzeugt und an den Anfang der Datei gesetzt. Der Default-Boot-Eintrag wurde allerdings nicht angepasst, so dass anschließend ein ganz andere Menueintrag als default gebootet wurde. Daneben wurde noch an das Ende der Datei ein nicht existierender Booteintrag für das Floppylaufwerk hinzugefügt. Ansich gesehen, keine großartige Geschichte, allerdings hat YaST dazu 2 Mal die menu.lst geändert, so dass anschließend keine Sicherheitskopie der vorher vorhandenen Datei mehr vorhanden war.

Was mir auf mehreren Rechner aufgefallen ist, an denen noch nie händisch das YaST Bootmenu aufgerufen worden ist, gebootet wird definitiv vom MBR der Platte während die /etc/grub.conf auf die erste Partition gesetzt ist, also im Zweifelsfall würden bestimmte Änderungen gar nicht aktiv, weil der aktive Bootloader im MBR davor sitzt und nicht überschrieben werden würde.

Wann ist damit zu rechnen das Komponenten von SuSE oder von Yast in die Bootkonfiguration eingreifen

Ein eingreifen von SuSe in die Bootkonfiguration ist äußerst selten. In folgenden Fällen ist damit zu rechnen das die menu.lst bzw die gesamte Bootkonfiguration unbemerkt geändert, anpasst, neuerstellt oder nur erneuert wird.

• Bei einer Neuistallation, (ist aber ehr erwünscht, wenn er damit nicht eine speziell gewünschte Konfiguration einfach verwirft).
• Beim "Beenden" des Modules Bootloader. Wer hier nur mal aus Neugier vorbeigeschaut hat oder sonst wie dort gelandet ist, auch wenn man bewußt überhaupt nichts geändert hat, dort immer "Abbrechen" als den sicheren Ausgang auswählen. Sonst kann es durchaus passieren das er morgen im Forum behauptet, überhaupt nichts verändert zu haben. ;-)
• Beim Ausführen des Scriptes grub-install. Hier wird in neuen SuSE-Versionen die /etc/grub.conf ausgeführt. Wer Howtos ausführt, in denen dieser Befehl drin steht, sollte sich vergewissern das er das Originale grub-install ausführt, in den derzeigtigen SuSe-Versionen ist es grub-install-unsupported.
• Beim installieren bestimmter Pakete, ua. beim Kernelupdate, installieren/deinstallieren von zusätzlichen Kernel, oder bestimmten Programmen die einen speziell konfigurierten Kernel mitbringen, bei ehr seltenen Updates von grub oder initrd, Bei einem kompletten Systemupdate, Im Zweifelsfall immer, wenn zur Aktivierung ein Reboot notwendig ist.
• bei Funktionen des [http://de.opensuse.org/SDB:YaST-System-Repair Yast-System-Repair}

auf welchen Rechnern könnte es Probleme geben

Bei Otto den Nomallinuxer wird es kaum bis gar keine Probleme geben, einzig das bei dem Einem oder Anderen mal der Windowseintrag verschwunden sein könnte oder nicht mehr bootbar ist. ZB nach automatischer Systemwiederherstellung nach anderen Problemen. Wer schon mal größer händische Änderungen an der menu.lst vorgenommen hat zB nach Änderungen im Platten und Partitionsbereich, weitere Betriebssysteme per Hand in Grub eingetragen hat, oder Spezialkonfigurationen wie gespielgeltes Rootfilesystem oÄ hat, könnte schon ehr vor einer unbemerkter Veränderung durch YaST betroffen sein. Meist bleibt SuSE dabei jedoch erst einmal weiterhin bootfähig, uU funktionieren einige andere Booteinträge nicht mehr, oder starten etwas falsches.

Welche Konsequenzen ergeben sich aus diesem Verhalten

Das Bootloadermodul von Yast scheint für individuelle Änderungen an der Grubkonfiguration, die ein gewisses allgemein einfaches Niveau und eine bestimmte Syntax überschreiten nicht geeignet zu sein. Auch entsprechende manuelle Änderungen an den Konfigdateien innerhalb dieses Moduls führt nicht zum Erfolg, da erstens nicht die orginalen Dateien angezeigt werden, sondern schon yastverträglich gemacht werden bevor sie angezeigt werden, und auch manuelle Änderungen im Anschluss erst einmal über einen solchen Filter laufen und dann wiederum yastverträglich geschrieben wird. Yast ist nicht in der Lage komplexe Konfiguration in bestimmten Einzelheiten und in der Gesamtheit zu verstehen bzw zu überprüfen.
Wer solche manuell erstellt oder geänderte Konfigurationen benötigt oder schon auf dem Rechner hat, sollte eine spätere Benutzung dieses Moduls möglichst vermeiden, da dadurch sehr leicht ungewollt Veränderungen am sensiblem Umfeld der Bootkonfiguration vorgenommen werden könnten. Für den Fall von unvermeidbaren Eingriffen von Yast zB bei einem komplettem Systemupdate sollte man Sicherungen seiner manuellen Bootkonfiguration bereit haben.

wie kann man sich schützen

Direkten Schutz benötigt man hier wahrscheinlich in den aller seltensten Fällen. Wenn man im Gefühl hat, wann sich da etwas verändern könnte, und man einschätzen kann ob ein System dafür anfällig ist oder nicht, reicht das meistens aus, um wachsam zu sein. Dann kann man hin und wieder mal nach dem Rechten zu sehen. Beachten sollte man, das nach Änderungen an der /etc/grub.conf oder /boot/grub/menu.lst man sich sicherheitshalber eine Kopie der dann fertigen und funktionieren Dateien macht. Im Zeifelsfall ist dann bei Veränderungen der alte richtige Zustand durch eine solche Reverenz wieder schnell hergestellt.

(ungetestet und ausdrücklich nicht empfohlen : Absoluten Schutz könnte zB das Immutable-Flag auf die beiden Konfigurationsdateien und das Entfernen des Ausführungsrechts bei /usr/sbin/grub sein, allerdings ist nicht sicher, wie Yast denn in automatischen Abläufen mit den damit entstehenden Fehlern umgeht, und ob man sich dadurch nicht schlimmere Fehler einfängt.)

Wer öfter Bootprobleme hat, der kann sich auch mal mit der Grub-Shell befassen. Eine gute Dokumentation sind die mit installierten Info-Seiten oder auch online oder download von hier Mit nur wenigen einfachen Befehlen wie zB find und cat und ein wenig Linuxgrundwissen findet man sich auf seinem System dann auch von der Grub-Shell aus schnell zurecht, und kann von dort aus Alles nur erdenkliche per Hand booten, (es wird sogar behauptet, man könne mit Grub Bierdeckel mit der Aufschrift Betriebssystem, booten ;-) von mir ungetestet ;-) )

---

zurück zur Bootmanager