SuSE und Grub

Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

Robi 20:03, 27. Jul. 2008 (UTC)

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. Seit der Version openSUSE 10.3 scheinen sich 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

Ausführbare Dateien

• das Programm grub das ist eine Emulation der eigentliche Grub-Shell
• das Script 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, da 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, damit das Ganze dann auch funktioniert.
Solche Anpassungen kann nur Grub 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 haargenau innerhalb des selben Datensektors befinden, sowie der Filesystemtype auf dem diese Dateien liegen, sich verändert hätte.

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 Paketinstallation 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 die Reihenfolge falsch ist. Muss aus diesen oder ähnlichen Gründen diese Datei entsprechend den aktuellen Gegebenheiten wieder neu angepasst werden, so reicht es aus, die alte Datei umzubenennen oder zu löschen und 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 Datei 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 muss also wohl oder übel nun auch über das Programm /usr/sbin/grub seine Bootkonfigurationen schreiben, und es kann nach Herzenslust die /boot/grub/menu.lst ändern. An der device.map spielt es ohne ausdrückliche Aufforderung dazu jedoch nicht herum. Da es aber in den Konfigurationsdateien von Grub nirgends einen Eintrag gibt, wo denn nun der Bootloader hingeschrieben worden ist, benötigt YaST eine zusätzliche Datei, damit er sich das merken kann, wo er schonmal den Bootloader mit welchen Optionen hingeschrieben hat. Dazu hat man die Datei /etc/grub.conf erfunden.

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 zur Kenntnis genommen, sie wurde auch nur von YaST benutzt.

BIS - In Version OpenSuse 10.3 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 

Das weiter nichts macht, 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 grub-install verwendet wurde, um zB. gezielt den Bootloader an eine bestimmte Position zu positionieren, und das Script 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. 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. Nach betätigen mit "OK" wurden von YaST ohne irgend eine Warnung stillschweigend solche Änderungen verworfen und auf irgendwas "normales" geändert. Wenn man eine per Hand geänderte Bootkonfiguration hat, die YaST nicht versteht, reicht ein Aufrufen des Bootloadermoduls und anschließen "Beenden", um seine gesamte Konfiguration 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 Tests, YaST konnte überhaupt nicht begreifen, dass es 2 mal die /boot/grub/Dateien gab, eben auf jeder Platte 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 gebootet hat, 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ürde eine Änderungen gar nicht aktiv, weil der Bootloader im MBR davor sitzt und nicht überschrieben werden würde. Was das soll ????

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. In der Regel bleibt SuSE dabei jedoch erst einmal weiterhin bootfähig.

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, und 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 ;-) )