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:
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 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:
LILO boot: linux aha152x=0x300,10,7Dieser 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.
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.
kernel /bzImage-2.2.14 ro root=/dev/hda3 aha152x=0x300,10,7
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=warmDie Angaben für die Module und ihre Form wird im nächsten Abschnitt dargestellt.
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=7Wir 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 KommandoDen 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 KommandoWenn 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.
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 > Bootmeldungenkönnen die Meldungen in eine Datei geschrieben werden, die dann ausgedruckt oder per Mail an einen Supporter geschickt werden kann.