Bootvorgang

Hinweis: Diese Seite enthält Informationen über den klassischen Start eines PC und des Bootvorganges von Linux wie er etwa in der Zeit von 2002 bis 2010 typisch war. Der ganze Prozess hat sich so aus den Anfängen der 80 Jahre des vorigen Jahrhunderts bis dort hin linear entwickelt und wurde immer wieder an die neuen Anforderungen angepasst. Letztlich haben einige unüberwindliche Grenzen diese lineare Entwicklung jedoch gestoppt, und derzeitig ist hier gleich an mehreren Fronten sehr viel Bewegung. Derzeit ist noch nicht abzusehen ob und wann sich die vielen Neuentwicklungen und Veränderungen zu einem stabilen und einheitlichen neuen Standard zusammenfinden werden. Es ist also möglich und wahrscheinlich, das auf ihrem Rechner schon derzeit vieles anders abläuft, als hier beschrieben. Einige der derzeit in der Entwicklung und Einführungsphase befindlichen Neuerungen die hier überhaupt noch nicht berücksichtigt sind: UEFI ersetzt das klassische BIOS. Hier könnte sich in den nächsten Jahren noch sehr viel ändern. Derzeit starten die meisten mit UEFI ausgestatteten Rechner noch mit einer "Legacy-Boot-Optionen" die ähnlich dem BIOS ist. Jedoch wird von verschiedenen Seiten angestrebt in Zukunft auf den "echten" UEFI-Boot zu setzen, und diesen eventuell auch mit der "Secure Boot" Erweiterung per default abzusichern. Dieses würde sehr große Änderungen und Restriktionen des Linux Bootvorganges mit sich bringen. Grub2 wird auf vielen Systemen derzeit als default Bootloader benutzt. Grub2 ist eine komplette Neuentwicklung und hat mit dem hier beschriebenen Grub (legacy) sogut wie nichts gemeinsam. systemd wird derzeit auf vielen Systemen benutzt und soll das alt bewährte Sys-V-Init ersetzen. Hieraus resultieren derzeit sehr vielen Änderungen an vielen Ecken im halben Betriebssystem. Nichts desto trotz, werden wir diesen Text hier weiterhin anbieten, einiges ändert sich halt nie ;-) Auf einigen Rechnern ist noch nach wie vor alles oder vieles so von Bedeutung wie hier beschrieben, - Andere können sich hier einige Teile herauspicken, die auch noch heute, morgen und übermorgen genau so gehandhabt werden.

Linux ist ja nun leider so stabil, dass es nie komplett abstürzt, und man kommt natürlich auch niemals in den Versuchung den Rechner einmal komplett auszuschalten, weil gar nichts mehr geht, bleibt jedoch immer noch das Risiko, die Mutter bleibt mit dem Staubsauger im Kabelgewirr hängen, der kleine Bruder drückt die Resettaste oder das Kraftwerk in Nachbarschaft hat mal wieder einen Störfall. Egal, Ergebnis ist jedenfalls, der Rechner ist aus, und beim booten bleibt der Rechner mit einer Fehlermeldung hängen.

oder

Nachdem man sich monatelang an seinem Linux erfreut hat, und nach und nach immer mehr von Linux versteht, wird man irgendwann einmal etwas mutiger werden. Festplatten, der Bootloader, der Kernel, die Filesysteme, die Startscripte, nichts ist dann mehr heilig. Die logische Konsequenz, irgendwas war im Howto natürlich wieder nicht richtig beschrieben, man konnte die Warnung also gar nicht beachtet oder übersehen. Wenn man also mal kein Glück hat und das Pech auch gleich noch dazu kommt. Das Ergebnis jedenfalls, der Rechner fährt nicht mehr hoch, die automatische SuSE Reparatur hilft auch nicht weiter und das letzte Backup ist selbstverständlich auch noch unbrauchbar.

Jetzt ist es wichtig zu wissen, wie so ein Bootvorgang von Linux überhaupt abläuft, damit man erst einmal eine grobe Idee bekommt, wo und warum der Bootvorgang hängen könnte.

Der Bootvorgang von Linux

BIOS

Beim Einschalten, erfolgt ein Reset, die CPU wird in den Real Modus geschalten und beginnt den Code in einem Flash-EEPROM dem so genannten BIOS ab der Speicheradresse 000F:FFF0 abzuarbeiten. Es folgt ein Peripheriecheck bei dem unter anderem die Grafikkarte gesucht wird. Anschließend erfolgt der POST (Power On SelfTest). Hierbei werden die sich auf dem Motherboard befindlichen Controller, sowie CPU und Speicher, auf Funktionstauglichkeit überprüft und nach Erweiterungssteckkarten gesucht, und diese entsprechend der BIOS Einstellungen zu konfigurieren. Diese gefundenen Controller werden meist noch mit ihren Einstellungen kurz angezeigt.

• Fehlermeldungen des BIOS
  

Sollte hier schon etwas nicht in Ordnung sein, zB fehlender oder defekter Grafikcontroller oder irgendwas anderes noch bevor der Grafikcontroller gefunden und in Betrieb genommen werden konnte, dann meldet das der BIOS über den internen Lautsprecher in Form von definierten Beep Tönen, spätere Fehlermeldungen werden über die Grafikkarte ausgegeben. Weiter Informationen über Funktionen und Fehler während dem POST können im BIOS Kompendium nachgelesen werden.

Nachdem der POST abgearbeitet ist, werden eventuell weitere BIOSe die sich auf eingesetzten Controllern zB. SCSI-Controllern befinden können, gestartet. So ein BIOS ist dafür zuständig, dass über die Geräte die an diesen Controllern angeschlossen sind, auch gebootet werden kann. (Der BIOS der Hauptplatine kann nicht selbst auf solche Geräte zugreifen)

Alles in Ordnung, dann muss jetzt das Betriebssystem irgendwie her

Bootloader

Entsprechend der im BIOS hinterlegten Boot-Reihenfolge durchsucht jetzt der BIOS die Wechselmedien und Festplatten nach einem Bootloader. Dabei wird der MBR (die ersten 512 Byte der Festplatte oder des Mediums) durchsucht. In diese 512 Byte kann ein winziges (bis 440 Byte großes) Programm als Bootloader hinterlegt werden. Ebenfalls in diesem MBR befindet sich die Partitionstabelle für die Partitionen 1 bis 4 und eine MBR-Signatur (0xAA55) die die Partitionstabelle und den Bootloader als gültigen MBR definiert.

die wichtigsten Bootloader die Linux mitbringt sind

• LILO
• GRUB (mittlerweile als Grub Legacy bezeichnet)
• GRUB_2
• Loadlin

Heute wird vor allem GRUB verwendet und ist dabei LILO in modernen Linux-Systemen zu verdrängen, Loadlin wird heute nur noch in einigen wenigen Spezialfällen eingesetzt.

Die wenigen Byte die dort im MBR Platz sind, können natürlich nicht der Kernel selbst sein. Auch ist es hier kaum möglich in diese paar Byte eine Unterstützung für Filesysteme und ähnliches einzubauen, um den Kernel von hier aus direkt zu laden.
Bei Grub nennt sich dieses kleine Programm im MBR stage1. Seine einzige Funktion besteht darin stage2 zu laden. Stage2 befindet sich innerhalb des Linuxsystems im Verzeichnis /boot/grub. Daneben befinden sich dort noch weiter Dateien e2fs_stage1_5 ffs_stage1_5 minix_stage1_5 vstafs_stage1_5 fat_stage1_5 jfs_stage1_5 reiserfs_stage1_5 xfs_stage1_5 diese beinhalten die Unterstützung für die unterschiedlichen Filesysteme auf denen sich das Verzeichnis /boot befinden kann. Bei der Installation von stage1 im MBR durch GRUB wird dort eine feste Adresse in der Form "Controller, Gerät, Partition, Block" hinterlegt, wo sich stage1_5 und stage2 befinden.

• Es wird also vom BIOS stage1 aus dem MBR in den Speicher geladen und gestartet
• stage1 läd jetzt die erforderliche Filesystemunterstützung stage1_5 und startet sie
• stage1_5 lad dann stage2 und startet damit Grub

Die Bedeutung der Fehlermeldungen in diesem Abschnitt.
Ab hier kann Grub auf dem Verzeichnis in dem sich /boot befindet, den Kernel und die Konfigurationsdateien über ihren Namen ansprechen. Grub wertet hier die Datei /boot/grub/menu.lst aus. In dieser Datei befinden sich Menüeinträge für das starten von verschiedenen Betriebssysteme oder verschiedenen Konfigurationen. Hilfe zur Konfiguration und als Einsprungspunkt für alles Geheimnisse gibt es nach wie vor in der Doku

Starten des Kernel

Ist jetzt in Grub die Entscheidung gefallen welcher Kernel mit welchen Optionen geladen werden soll, dann sucht Grub diesen über seinen Namen und läd ihn in den Speicher, dort wird der Kernel dann gestartet und durchläuft folgende Schritte.

• Umschalten auf Protected Mode
• Sprung in den Code der Datei head.S ( im Kernelquellcode /usr/src/linux/arch/i368/kernel/head.S )

dort werden jetzt Dinge initialisiert die man schon richtig zur Arbeit mit Linux braucht

• Initialisieren der Interrupt Beschreibungstabelle (IDT)
• Sichern der Bootparameter (werden später als Parameter für die Funktion main.c benötigt)
• Prüfung auf Prozessortype
• Initialisieren der Speicherbeschreibungstabelle

Nachdem die Initialisierung durchgeführt wurde kann jetzt die Vorbereitung für den Kernel angegangen werden

• dazu werden Funktionen der Datei ( /usr/src/linux/init/main.c ) gestartet. unter anderem

• Speicher initialisiert
• Einstellungen fpr Interrupts, Scheduler und Zeitgeber
• verarbeiten eventueller Kommandozeilenargumente
• dynamischen Speicherbereich des Kernels initialisieren

Es soll hier auch nicht näher in die einzelnen Vorgänge vorgedrungen werden, wer sich damit auseinander setzten will oder muss, dem sei auf den Quelltext und auf die Howtos zum Kernel verwiesen. Die einzelnen Module des Kernels die initialisiert werden erzeugen Ausgaben auf der Bootkonsole, die man im Fehlerfall genau nach Fehlern durchsuchen muss.

Starten der initrd

Da im Kernel meist nicht alle Module integriert sind, die der Kernel jetzt zum Boot wirklich benötigen würden, wird in der Grubkonfiguration oftmals noch eine initrd (Initial Ram Disk ) mit angegeben. Diese wird nach dem starten des Kernels geladen und abgearbeitet.

Eine initrd besteht entweder aus einem cpio-Archiv oder aus einem mittels gzip komprimierten ext2 Filesystems in einer Datei. Je nach Type der initrd wird diese entweder in einem loopdevide aus dem cpio-Archiv ausgepackt oder die nach dem entkomprimieren der initrd entstandene Datei als loop device gemountet. Diese RAM-Disk stellt somit ein Abbild eines Dateisystems im Speicher dar.

In der Initrd sind jetzt Treibermodule enthalten, die nicht im Kernel enthalten sind, jedoch vor dem Einhängen des Root filesystems benötigt werden. Also ZB. Unterstützung für RAID allgemein , wenn das Root filesystem ein RAID Device ist, Unterstützung und Programme (zB. fsck, mount, umount) zum Umgang von Reiserfs, wenn das Root filesystem ein reiserfs ist. Unterstützung für einen SCSI-Controller soweit dieser nicht im Kernel enthalten ist, das Root filesystem sich aber auf einer Platte an diesem Controller befindet. Module für die Unterstützung der Netzwerkkarte, wenn das Root Filesystem über das Netz gebootet werden muss usw.

Die Initial Ramdisk kann entweder ein mit gzip komprimiertes Abbild eines ext2-Dateisystems sein, oder aber auch ein mit gzip komprimiertes cpio-Archiv. Der Kernel erkennt im Normalfall beides an. In älteren Versionen von Suse war ehr das Dateisystemabbild zu finden, in den neuen Versionen wird das cpio-Achiv bevorzugt. Gelegentlich muss man bei Bootfehlern einmal in dieses initrd hinein, um dort etwas nachzuschauen oder selbst per Hand kleine Änderungen vornehmen. ( Vorsicht: ändern an dieser Stelle ist nur was für wirklich erfahrene User)

initrd ist ext2-Abbild

Folgender Konsolauszug zeigt, wie man eine initrd (ext2 Abbild) öffnen kann:
Das wieder Zusammensetzen eines hier geänderten Filesystems geht dann entsprechend wieder rückwärts zum Auspacken.

LINUX:/tmp #  cp /boot/initrd /tmp
LINUX:/tmp # file initrd
initrd: gzip compressed data, was "initrd_small", from Unix, max compression
LINUX:/tmp # mv initrd initrd.gz
LINUX:/tmp # gunzip initrd.gz

gunzip: initrd.gz: decompression OK, trailing garbage ignored
LINUX:/tmp # file initrd
initrd: Linux rev 1.0 ext2 filesystem data
LINUX:/tmp # mount -t ext2 -o loop /tmp/initrd /mnt
LINUX:/tmp # cd /mnt
LINUX:/mnt # ls -l
total 17
drwxr-xr-x  10 root root 1024 Jul 16 00:36 .
drwxr-xr-x  24 root root  560 Nov  5 12:04 ..
drwxr-xr-x   2 root root 1024 Jul 16 00:36 bin
drwxr-xr-x   3 root root 1024 Jul 16 00:36 dev
drwxr-xr-x   3 root root 1024 Jul 16 00:36 etc
drwxr-xr-x   4 root root 1024 Oct 31  2004 lib
-rwxr-xr-x   1 root root 6159 Jul 16 00:36 linuxrc
drwxr-xr-x   2 root root 1024 Jul 16 00:36 mnt
drwxr-xr-x   2 root root 1024 Jul 16 00:36 proc
drwxr-xr-x   2 root root 1024 Jul 16 00:36 sbin
drwxr-xr-x   2 root root 1024 Jul 16 00:36 sys
LINUX:/mnt # 

Abgearbeitet wird innerhalb dieser etwas älteren initrd die Datei linuxrc welche dann mit folgender Zeile endet.

"die 0"

initrd ist cpio-Archiv

LINUX:/boot # ls -l initrd*
lrwxrwxrwx 1 root root      27 Feb 13 23:24 initrd -> initrd-2.6.18.8-0.9-default
-rw-r--r-- 1 root root 3267755 Feb 13 23:24 initrd-2.6.18.8-0.9-default
LINUX:/boot # cp initrd-2.6.18.8-0.9-default /tmp
LINUX:/boot # cd /tmp
LINUX:/tmp # file initrd-2.6.18.8-0.9-default
initrd-2.6.18.8-0.9-default: gzip compressed data, from Unix, last modified: Wed Feb 13 23:23:59 2008, max compression
LINUX:/tmp # mv initrd-2.6.18.8-0.9-default initrd.gz
LINUX:/tmp # gunzip initrd.gz
LINUX:/tmp # file initrd*
initrd: ASCII cpio archive (SVR4 with no CRC)
LINUX:/tmp # mkdir initrd-root
LINUX:/tmp # cd initrd-root
LINUX:/tmp/initrd-root # cpio -idum < ../initrd
14440 blocks
LINUX:/tmp/initrd-root # ls -l
total 224
drwxr-xr-x 2 root root   4096 May 23 20:15 bin
-rw-r--r-- 1 root root 167125 May 23 20:15 bootsplash
drwxr-xr-x 2 root root   4096 May 23 20:15 dev
drwxr-xr-x 4 root root   4096 May 23 20:15 etc
-rwxr-xr-x 1 root root  15105 May 23 20:15 init
drwxr-xr-x 5 root root   4096 May 23 20:15 lib
drwxr-xr-x 2 root root   4096 May 23 20:15 proc
drwxr-xr-x 2 root root   4096 May 23 20:15 root
drwxr-xr-x 2 root root   4096 May 23 20:15 sbin
drwxr-xr-x 2 root root   4096 May 23 20:15 sys
drwsrwxrwx 2 root root   4096 May 23 20:15 tmp
drwxr-xr-x 3 root root   4096 May 23 20:15 var

Zusammengesetzt wird wieder in umgekehrter Reihenfolge. Abgearbeitet wird in dieser initrd die Datei init welche wiederum mit "die 0" endet

Achtung: da es zur Zeit hier sehr viele Veränderungen bei der prinzipellen Hardware-Handhabung gibt, gibt es auch sehr viele Änderungen an den Scripten von mkinitrd und selbstverständich dem inneren Aufbau und deren Funktion der initrd selbst. Distributionsabhängig sollte man sich desshalb unbedingt vor manuellen Änderungen vorher noch einmal mit den Manpages und eventuell den mit der aktuellen Distribution installierten Dokumenten befassen.

Sollten Fehler innerhalb der Abarbeitung der initrd auftreten, dann sind diese an der Bootkonsolausgabe ersichtlich. Meist sind es fehlende oder falsche Module, fehlende oder veraltete Konfigurationsinformationen oder die falsche initrd zu diesem Kernel. Ist das System über eine Boot- oder Install-CD komplett startbar, dann dort mittels des Befehls

mkinitrd

die initrd neu erzeugen. Sollte es nicht möglich sein, das System mittels einer solchen CD zu booten, so kann statt dessen ein System von CD gebootet werden und die initrd innerhalb einer chroot-Umgebung neu erstellt werden. Dazu ist es jedoch erforderlich entweder eine ganze Menge Optionen an den Befehl mkinitrd zu übergeben, oder was sehr viel einfach und fehlerfreier läuft, der chroot-Umgebung die Informationen zur Verfügung zu stellen, die sie zum erkennen aller Gegebenheiten benötigt.

mount /dev/...... /mnt         #Rootfilesystem
mount /dev/...... /mnt/.....   #falls /boot /usr /var eigene Verzeichnisse darstellen diese unterhalb von /mnt einhängen
chroot /mnt
mount /proc
mount /sys
mkinitrd

Einhängen des Rootfilesystems

Nachdem die initrd abgearbeitet ist, erfolgt das Laden des Rootfilesystems entsprechend den Angaben in der Grubkonfiguration. Das Filesystem wird per default erst einmal "readonly" gemountet. Hier werden die meisten Fehler jetzt aufschlagen, und sich bemerkbar machen mit Fehlern wie "kein Rootdevice gefunden" oder "Filesystem nicht bekannt" die schon zu einem früheren Zeitpunkt des Bootprozesses ihre Ursache haben, und jetzt hier dazu führen das das Rootfilesytem nicht gefunden und gemountet werden kann.

mögliche Ursachen:

• falsche Konfiguration oder Eingabe über das Rootdevice bei Grub
• defekte Partitionstabelle, oder komplett zerschossenes Filesystem
• fehlender Treiber für Filesystemunterstützung, oder Kontroller
• fehlender Treiber oder Konfigurationen für RAID oder LVM
• veralte Signaturen oder IDs für Logische oder physikalische Partitionen, zb nach Hardwareaustausch

Sollte der Fehler hier auftreten, hilft nur Studium der Bootlogausgaben. Gefahndet hier wird nicht nur nach Fehlermeldungen sondern auch nach schlichtweg fehlenden Meldungen.

Ist die Hardwareunterstützung der initrd geladen und das Rootfilesystem eingehängt, ist deren Aufgabe erledigt und die initrd stirbt und gibt den Staffelstab des bootens jetzt weiter an das Rootfilesystem. Die von der initrd geladenen Treibermodule und Konfigurationseinstellungen befinden jetzt im Systemspeicher oder sind jetzt Bestandteil des Kernels. Die wenigen Programme und Library die in der initrd enthalten waren und zur Abarbeitung in der initrd notwendig waren, befinden sich ja alle auch im Rootfilesystem, und darauf kann nun zugegriffen werden.

Starten des init-Prozesses

wenn das Root filesystem eingehängt ist wird das Programm /sbin/init gestartet. Dieser Prozess hat eine Konfigurationsdatei, die Datei /etc/inittab. Solange das System läuft, hat dieser Prozess immer die ID 1 und ist der Urahn aller anderen Prozesse im System. Prozesse die ihre Vorfahren verlieren aber selbst nicht beendet werden oder werden können, werden dann von diesem init-Prozess adoptiert. Befehle wie shutdown oder /sbin/init selbst können den laufenden init-Prozess beinflussen und somit zB das System herunterfahren. Innerhalb der /etc/inittab können aber auch Tastenkombinationen und Signale konfiguriert werden, die init beeinflussen. So kann sich das System zB herunterfahren wenn von der Überwachung der Stromversorgung ein entsprechendes Signal an den init-Prozess gesendet wird, oder das System mit "ctrl-alt-del- Tastenkombination" heruntergefahren werden. Init durch /etc/initab konfiguriert startet dabei nur wenige Scripte oder Programme selbst sondern bediehnt sich zum Hochfahren des Systems den Scripten /etc/init.d/boot und /etc/init.d/rc. Was init nicht aus der Hand gibt, ist allerdings das Starten und Restarten der Anmeldekonsolen, welche auch innerhalb der inittab konfiguriert werden. Genaueres kann man in den Manpages von inittab und init nachlesen.

die Bootscripte

Das erste Script das innerhalb der inittab gestartet wird, ist bei SuSE normalerweise /etc/init.d/boot . Dieses Script startet dann die Startscripte unterhalb von /etc/init.d/boot.d Diese Prozedur läuft immer ab, egal welcher Runlevel dann letztendlich gestartet werden wird.

Dort kommt es besonders nach Systemcrash öfter einmal zu einem Bootabbruch innerhalb des Scripte S03boot.rootfsck. Das Root filesystem ist so defekt, dass eine automatisierte Reparatur mit fsck nicht funktioniert hat und dieses Programm interaktiv vom User gestartet werden soll. Hier hilft schon ein genaues lesen der Fehlermeldung, die schon fast genau sagt, was gemacht werden muss. Etwas knifflig kann es mit Reiserfs werden, hier hilft Reiser-Dateisystem reparieren eventuell weiter.

Mit weiteren Abbrüchen innerhalb dieser ersten Boot-Scripte ist zu rechnen wenn die Daten innerhalb der /etc/fstab nicht korrekt sind, oder nicht den aktuellen Gegebenheiten entsprechen und damit Filesysteme nicht gemountet werden können, oder Filesysteme beschädigt sind, und somit nicht automatisch eingebunden werden können.

Innerhalb dieser Boot-Scripte die jetzt hier gestartet werden, werden die Filesysteme geprüft und gemountet, dazu werden eventuelle weitere Module zur Ünterstützung von zB Raid oder Verschlüsselung geladen, es werden die Daten von wichtigen Systemresourcen überprüft oder gegebenenfalls neu erstellt, wie zB den Cache für den Library-Loader, Netzwerktechnisch wird vorerst nur einiges an Grundeinstellungen vorgenommen und das Loopback Interface konfiguriert.

Starten der Runlevel

sind die Bootscripte durchlaufen, wird aus der inittab heraus mittels des Scriptes /etc/init.d/rc der entsprechnede Runlevel durch Starten der Runlevelscripte gestartet. Hier erfolgt jetzt die weitere Konfiguration aller im System vorhandener Hardware, die eventuelle Konfiguration der Netzwerkschnittstellen und der Netzwerkdienste, sowie dem Start aller automatisch zu startenden Software. Viele der Scripte hier werden von den jeweiligen Programmpaketen bei der Installation schon mitgebracht. Die eventuelle Konfiguration für diese Dienste befinden sich nicht innerhalb der Scripte sondern oft unterhalb von /etc oder relativ ../etc/ der Binärdateien solcher Software

Die Fehler, die hier auftreten können sind sehr vielfältig, wirklich tödliche Fehler hier aber eher selten, da das System als solches ansonsten voll funktionsfähig bleibt. Es läßt sich jedoch in aller Regel sehr schnell feststellen, in welchem Script ein solcher tödlicher Fehler aufgetreten ist. Entweder die Bootausgaben auswerten, in schwierigen Fällen hilft hier auch ein Starten des Runlevel 1 und das anschließende manuelle Starten der einzelnen Scripte, die zum Runlevel gehören, um das Entstehen eines tötlichen Fehlers näher eingrenzen zu können. Nicht funktionierende Dienste, obwohl scheinbar sauber gestartet, können zB dadurch ausgelöst werden, dass die Scripte nicht in der richtigen notwendigen Reihenfolge gestartet werden.
Prinzipiell sollten Runlevelscripte nicht mehr, wie in früheren Zeiten, selbst per Handverlinkung in die Reihenfolge eingefügt werden. Neue Suse-Systeme werden solche Scripte gar nicht erst starten. Die Reihenfolge der Abarbeitung der Scripte, die in neuen Systemen auch parallel abgearbeitet werden, wird im wesentlichen durch die Konfiguration innerhalb von 3 Dateien im Verzeichnis /etc/rc.d/ bestimmt.

/etc/rc.d/.depend.boot 
/etc/rc.d/.depend.start 
/etc/rc.d/.depend.stop

Entsprechend dem Header in dem Startscripten

         ### BEGIN INIT INFO
         # Provides:       boot_facility_1 [ boot_facility_2 ...]
         # Required-Start: boot_facility_1 [ boot_facility_2 ...]
         # Required-Stop:  boot_facility_1 [ boot_facility_2 ...]
         # Should-Start:   boot_facility_1 [ boot_facility_2 ...]
         # Should-Stop:    boot_facility_1 [ boot_facility_2 ...]
         # Default-Start:  run_level_1 [ run_level_2 ...]
         # Default-Stop:   run_level_1 [ run_level_2 ...]
         # Description:    multiline_description
         ### END INIT INFO

werden beim Hinzufügen eines Scriptes durch den Befehl insserv diese Dateien entsprechend der Abhängigkeiten der einzelnen Scripte und Dienste untereinander, erstellt und bei der default eingestellten parallelen Abarbeitung der Scripte verwendet.

Häufiges Problem bei Runlevel 5 ist das Problem mit dem nichtstarten der Grafischen Oberfläche, meist ausgelöst durch fehlerhafte Konfiguration des Xservers.

Starten der Konsolen

Nachdem /etc/init.d/rc seine Arbeit beendet hat, oft noch während einige Startscript im Hintergrund weiter arbeiten, werden von init die in der inittab konfigurierten Anmeldekonsolen gestartet. Diese Konsolen werden in aller Regel mit dem Schlüsselwort respawn in der inittab versehen und werden dann nach der Abmeldung neu gestartet, um auf einen neue Anmeldung zu warten. Hier sind die wenigsten Fehler zu erwarten, wenn man in die inittab keine groben Schnitzer einbaut.

Die Meldungen des Bootprozesses

Im Prinzip haben wir 3 Möglichkeiten die Ausgaben oder Logs die beim Booten entstehen, nachzulesen. Alle diese Ausgaben fallen in ihrem Format Aussehen und Inhalt etwas anders aus.

Die Ausgaben auf der Konsole

hier werden wir alle Meldungen vom Start des Rechners, Bios. Bootloader, Kernelstart usw verfolgen können. Die Ausgabe der Linuxbootmeldungen auf der Konsole kann im Bootloader deaktiviert sein, ist aber durch einen Tastendruck (manchmal ESC oder F2) dennoch zu verfolgen. Allerdings ist die Ausgabe oftmals sehr schnell und läßt sich später nicht immer zurückscrollen. Bisweilen sind bei den Ausgaben auch einmal einiges durcheinander, da hier die Ausgaben von normalen Meldungen und Fehlermedungen bisweilen auch von mehren Prozessen gleichzeitig, ausgegeben werden. Bei den Runlevelscipten sehen wir hier oftmals nur derbe Fehler und ansonsten den Rückgabestatus des Startscriptes. Beim Hängen des Systems sieht man jedenfalls die letzten oft entscheidenten Zeilen.

Die Logs des Kernels

die Kernellogs befinden sich in einem Ringpuffer innerhalb des Kernels und lassen sich jederzeit mit dem Befehl dmesg auslesen, allerdings wird der Ringpuffer bei sehr vielen Meldungen irgendwann voll werden und vom Anfang an alte Meldungen überschreiben. Einige Systeme sichern deshalb die Ausgabe von dmesg nach dem Booten in einer Datei zB boot.log unterhalb von /var/log. Diese Meldungen beginnen mit dem Start des Kernels, Grubmeldungen werden wir hier also vergebens suchen.

Die Logs des Systemlogging

Diese Meldungen werden per default in der Datei /var/log/messages abgelegt, und sind besser strukturiert als die anderen beiden Ausgaben, so dass man hier besser Filter auf die Meldungen ansetzen kann. Auch hat man hier oftmals die Logs von mehreren Bootvorgängen, so dass man diese unmittelbar vergleichen kann. Allerdings beginnen diese Meldungen erst wenn das Systemlogging aktiviert ist, frühe Meldungen des Kernels und der Initrd bzw Meldungen der ersten Bootscripte sind hier nicht zu finden.

Weitere Links zum Thema booten von Linux

• Booten (Wikipedia)
• Schnelles Booten mit Upstart, einem Ersatz für das betagte Sys-V-Init (Artikel Linux Magazin)
• PXE Bootablauf (schematische Darstellung)
• Grub Doku Version 0.97
• Bootmanager
• BIOS
• MBR
• systemd