Inhaltsverzeichnis
Beschreibung: Prüfungskandidaten sollten in der Lage sein, das System durch den Bootprozeß zu führen. Dieses Lernziel beinhaltet das Übergeben von Kommandos an den Bootlader und die Übergabe von Optionen an den Kernel zum Bootzeitpunkt sowie das Überprüfen von Ereignissen in den Logdateien.
Die wichtigsten Dateien, Bezeichnungen und Anwendungen:
- dmesg
- /var/log/messages
- /etc/conf.modules oder /etc/modules.conf
- LILO
- GRUB
Der Bootvorgang von Linux kann auf verschiedene Art und Weise gestartet, beeinflusst und nachvollzogen werden. Für die Anforderungen des LPIC 101 Examens genügt das Wissen um die Techniken, die mit dem Linux Loader (lilo) oder dem alternativen Bootmanager grub zu tun haben. Das soll auf dieser Seite näher erläutert werden.
Die Funktion von Bootmanagern wurde bereits in der Vorbereitung auf die erste LPI-Prüfung in Abschnitt 1.102.2 ausführlich dargestellt und wird hier als bekannt vorausgesetzt.
Kernelparameter angeben
Jeder Linux-Kernel kann beim Start, also bevor er geladen wird, noch Parameter übergeben bekommen, die sich auf die Art und Weise auswirken, wie er startet bzw. wie er sich zur Laufzeit verhalten soll. Es kann sich dabei um Parameter für bestimmte Geräte handeln (etwa SCSI-Adressen des Bootlaufwerks) oder um Eigenschaften des Kernels selbst wie z.B. die oben als Beispiel angegebene Anweisung bei einem Reboot einen Warmstart statt einem Kaltstart zu machen.
Kernelparameter für Geräte werden nur notwendig, wenn mit Hardware gearbeitet wird, die der Kernel nicht selbstständig erkennt. Ein Standard-PC mit Standard-Komponenten benötigt keine zusätzlichen Kernelparameter.
Es würde den Rahmen dieser Darstellung bei weitem sprengen, alle denkbaren Kernel-Parameter hier zu beschreiben, das ist für die LPI101 Prüfung auch gar nicht notwendig. Wenn die Kernel-Quellen installiert sind, findet sich eine Beschreibung aller unterstützer Parameter in der Datei /usr/src/linux/Documentation/kernel-parameters.txt. Wichtig ist die Tatsache, daß es möglich ist, bestimmte Parameter dem Kernel zu übergeben.
Wo werden diese Parameter übergeben, das ist jetzt die Frage. Es gibt mehrere mögliche Antworten, die hier kurz angefügt werden sollen: Auf dem Bootprompt von LILO oder GRUB Wenn der Bootprompt beim Start des Systems erscheint, dann erwartet der Bootmanager die Nennung des Systemnamens, das gestartet werden soll (also des in /etc/lilo.conf angegebenen Labels). Diesem Namen können Kernelparameter mitgegeben werden. Das könnte z.B. folgendermaßen aussehen:
LILO boot: linux aha152x=0x300,10,7
Dieser Kernel-Parameter würde dem Kernel also mitteilen, daß ein Adaptec AHA152X SCSI Hostadapter an der Adresse 0x300 sitzt, den IRQ 10 benutzt und die SCSI-ID 7 belegt.
Analog dazu kann ein solcher Parameter auch auf der Boot-Zeile von grub eingegeben werden, statt LILO steht hier dann entsprechend GRUB.
Diese Form der Parameterübergabe ist natürlich lästig, weil man jedesmal beim Booten die erforderlichen Parameter angeben muß. Sie eignet sich daher nur für experimentelles booten, also das Ausprobieren einzelner Parameter, um sicherzustellen, daß sie auch richtig funktionieren. Andere Bootprompts Auch die Bootprompts von SYSLINUX (Startdisketten vieler Distributionen) oder als Parameter von LOADLIN (Linux von DOS/Windows aus starten) können Kernelparameter mitgegeben werden. Auch hier gilt das oben gesagte, es handelt sich um die Möglichkeit zu experimentieren und sollte keine Lösung für den Alltag sein. In der Datei /etc/lilo.conf Sollen Parameter dauerhaft eingerichtet werden, so ist die Datei /etc/lilo.conf der richtige Ort. Wie oben schon gezeigt, gibt es in dieser Datei die Möglichkeit, sowohl in der globalen ersten Sektion, als auch für jeden Kerneleintrag einzeln mit dem Schlüsselwort append= Kernelparameter anzugeben.
Wird diese Angabe wie im obigen Beispiel in der ersten, globalen Sektion der lilo.conf vorgenommen, so gilt sie für alle zu bootenden Linux-Kernel, steht sie stattdessen in der zweiten Sektion, so gilt sie nur für den jeweiligen Kernel, in dessen Kontext sie angegeben wurde. In der Datei /boot/grub/grub.conf Wird statt lilo das Programm grub als Bootmanager verwendet, so muß die Angabe der Parameter entsprechend in seiner Konfigurationsdatei vorgenommen werden. In diesem Fall werden die Parameter direkt an die Kernelangabe gehängt, also etwa in der Art
kernel /bzImage-2.2.14 ro root=/dev/hda3 aha152x=0x300,10,7
In der Datei /etc/conf.modules bzw. modules.conf Nachträglich ladbare Module können (und sollen) in der Datei /etc/conf.modules konfiguriert werden. Streng genommen handelt es sich hier auch um Kernel-Parameter, aber eben um die für ladbare Module. Eine genaue Beschreibung dieser Datei folgt im nächsten Abschnitt. Mit Ausnahme der Einstellungen in der Datei /etc/conf.modules (oder modules.conf) gilt für Kernelparameter immer die folgende Regel:
Alle für einen Treiber relevanten Parameter müssen unmittelbar hintereinander, durch Kommas getrennt, angegeben werden. Es darf kein Leerzeichen zwischen den einzelnen Parametern eines Treibers sein. Sollen mehrere Kernelparameter angegeben werden, so werden diese mit Leerzeichen voneinander getrennt. Also z.B.
aha152x=0x300,10,7 reboot=warm
Die Angaben für die Module und ihre Form wird im nächsten Abschnitt dargestellt.
Kernelmodule konfigurieren
Ein Linux-Kernel kann prinzipiell auf zwei verschiedene Arten aufgebaut werden. Entweder alle notwendigen Gerätetreiber sind fest in den Kernel hineinkompiliert, oder einzelne Gerätetreiber sind als ladbare Module kompiliert und werden zur Laufzeit ge- und entladen. Im ersten Fall spricht man von einem monolithischen Kernel, im zweiten von einem modularisierten Kernel.
Die Vorteile des zweiten Modells liegen auf der Hand. Müssten alle Gerätetreiber immer fest im Kernel eingebaut sein, dann hätten wir entweder einen riesigen (und demzufolge langsamen) Kernel oder wir müssten wegen jeder Kleinigkeit (etwa einer neuen Netzwerkkarte) den Kernel neu kompilieren.
Durch die Modularisierung haben wir die Möglichkeit, die Treiber unabhängig vom Kernel zu kompilieren und dann zu laden, wenn wir sie brauchen. Es ist sogar möglich, die geladenen Treiber während der Laufzeit wieder abzuhängen, so daß unnötiger Speicherbedarf vermieden werden kann. So kann z.B. ein ZIP-Laufwerk an der parallelen Schnittstelle betrieben werden. Immer dann, wenn wir es einstecken laden wir den dafür notwendigen Treiber, sobald wir es abhängen entfernen wir auch den Treiber wieder…
Die Kernel-Module benötigen – genauso, als wären sie fest im Kernel eingebaut – zum Teil Angaben über ihre verwendeten Adressen, IRQs, DMA-Kanäle und ähnliches. Damit diese Angaben nicht jedesmal beim Laden der Module von Hand eingegeben werden müssen (und damit so auch ein automatisches Laden der Module ermöglicht werden kann), müssen wir diese Parameter fest in einer Datei eintragen. Diese Datei heißt /etc/conf.modules oder /etc/modules.conf. Meist ist modules.conf ein Link auf conf.modules oder umgekehrt.
Diese Datei beinhaltet die notwendigen Parameter für die verwendeten Module, allerdings werden diese Parameter hier auf eine andere Art – mit einer anderen Syntax – als bei der direkten Übergabe an den Kernel angegeben.
Die vollständige Dokumentation über diese Datei und deren Format ist in der Handbuchseite modules.conf(5) nachzulesen. Hier werden nur die wichtigsten Elemente beschrieben.
Ein einfaches Beispiel für eine solche Datei (reduziert auf die Beschreibung der Netzwerkkarte) könnte wie folgt aussehen:
alias eth0 ne alias eth1 off options ne io=0x320 irq=7
Wir definieren mit der ersten Zeile einen Alias eth0 (erste Ethernetkarte) und weisen ihm den Wert ne (der Name des passenden Moduls) zu. Die zweite Zeile definiert den Alias eth1 mit dem Wert off. Wird dieser Wert gegeben, so wird dieses Modul nie geladen, sogar dann nicht, wenn es explizit von Hand aufgerufen werden würde.
Die eigentliche Definition der Parameter für das Modul ne wird mit der dritten Zeile vorgenommen. Das Schlüsselwort options legt fest, daß das Modul ne die Parameter io=0x320 und irq=7 bekommt.
Im Gegensatz zur Übergabe der Parameter an den Kernel werden hier die Parameter genau bezeichnet. Das führt häufig zu Verwechslungen, weil ein und das selbe Modul eine unterschiedliche Syntax für die Übergabe der Parameter benutzt, es ist aber nicht zu ändern.
Ein weiterer interessanter Aspekt der Datei /etc/conf.modules ist die Möglichkeit, mit den Schlüsselwörtern pre-install und post-install festzulegen, daß bestimmte Kommandos vor (pre-install) bzw. nach (post-install) dem Einhängen eines Moduls ausgeführt werden. Bei den Kommandos handelt es sich in den häufigsten Fällen wiederum um Kommandos zum Laden (oder Entladen) von Modulen.
Die Syntax dieser beiden Befehle ist dabei sehr einfach:
pre-install Modul Kommando post-install Modul Kommando
Den gleichen Mechanismus gibt es genauso wiederum zum Entladen von Modulen, hier heißen dann die Schlüsselwörter:
pre-remove Modul Kommando post-remove Modul Kommando
Wenn also ein Stück neue Hardware installiert werden soll und diese neue Hardware über ein Modul angesprochen wird, so ist die Datei /etc/conf.modules der Ort, an dem die entsprechenden Parameter für die Module eingetragen werden. Die meisten Distributionen liefern bereits eine solche Datei mit, die schon verschiedenste Einstellungen beispielhaft gesetzt hat. Diese Einstellungen sind mit dem #-Zeichen auskommentiert und können durch das Entfernen dieses Zeichens aktiviert werden.
Die Meldungen des Bootvorgangs nachlesen
Jedes Linux-System protokolliert alle Vorkommnisse in einem Logbuch mit. Der Daemon, der dieses Logbuch schreibt ist der syslogd über den im Abschnitt 1.111.3 noch mehr zu lernen sein wird. Für die Meldungen des Kernels selbst steht noch ein weiterer Daemon zur Verfügung, der klogd, also der Kernel Log Daemon. Auch er schreibt Logbuchmeldungen, allerdings die des Kernels selbst. Beide diese Logbuchdaemonen schreiben ihre Meldungen in der Regel in die Datei /var/log/messages.
Diese Datei ist also das Systemlogbuch, ein Fundus von Informationen, über alle möglichen Vorkommnisse, die das System betreffen. Auch die Startmeldungen des Kernels sind hier größtenteils zu finden. Allerdings eben nur größtenteils, denn um die entsprechenden Daemonen zu starten, muß der Kernel schon geladen, und seine Dateisysteme müssen eingehängt sein. Die ersten – und für die Fehlersuche meist interessantesten – Meldungen des Kernels sind in dieser Datei also nicht zu finden.
Der Kernel hält aber einen internen Ringbuffer aufrecht, in den er alle Meldungen hineinschreibt, die etwa beim Start ausgegeben werden. Um diesen Ringbuffer zu lesen, gibt es das Programm dmesg. Es ließt den Buffer und gibt den Inhalt auf der Standard-Ausgabe aus. Hier finden sich dann alle Meldungen des Kernels, die er seit dem Booten erstellt hat, bzw. wenn der Rinbuffer voll ist, die letzten Meldungen, die in den Buffer passen. Eine typische Form der Ausgabe des dmesg-Programms ist hier einsehbar
Mit diesem Programm stehen uns also auch die Kernel-Meldungen zur Verfügung, die vom Syslog-Daemon bzw. Klog-Daemon noch nicht protokolliert werden konnten, weil diese Daemonen noch gar nicht geladen waren als die Meldungen anfielen.
Das ist eine gerne benutzte Möglichkeit, wenn z.B. beim Start etwas nicht funktioniert und man Rat sucht. Mit dem Befehl
dmesg > Bootmeldungen
können die Meldungen in eine Datei geschrieben werden, die dann ausgedruckt oder per Mail an einen Supporter geschickt werden kann.