Hintergrundwissen für den Bootprozess

AnmerkungBitte beachten
 

In diesem Kapitel wird insbesondere der Bootprozess des Systems x86 beschrieben. Je nach Architektur Ihres Systems kann der entsprechende Bootprozess leicht von den hier beschriebenen Vorgängen abweichen. Nachdem der Kernel gefunden und vom System geladen wurde, verläuft der standardmäßige Bootprozess von Red Hat Linux jedoch in allen Systemarchitekturen auf die gleiche Weise. Weitere Informationen über das Starten des x86-Systems finden Sie unter Abschnitt namens Differenzen im Bootprozess bei anderen Architekturen.

Wenn ein Computer gestartet wird, sucht der Prozessor am Ende des Systemspeichers nach dem BIOS (Basic Input/Output System) und führt es aus. Das BIOS-Programm ist im schreibgeschützten Speicher abgelegt und ständig einsatzbereit. Das BIOS stellt die Schnittstelle der untersten Ebene zu den Peripheriegeräten dar und steuert den ersten Schritt des Bootprozesses.

Das BIOS prüft das System, sucht und prüft Peripheriegeräte und sucht dann nach einem Bootlaufwerk. Normalerweise prüft es das Diskettenlaufwerk (oder auf vielen neueren Systemen das CD-ROM-Laufwerk) und sucht anschließend auf der Festplatte. Die Reihenfolge der zum Booten verwendeten Laufwerke wird gewöhnlich durch eine bestimmte BIOS-Einstellung vorgegeben. Nachdem Red Hat Linux auf einer Festplatte installiert wurde, sucht das BIOS einen Master Boot Record (MBR), der im ersten Sektor der ersten Festplatte beginnt, speichert den Inhalt und startet den MBR.

Der MBR sucht nach der ersten aktiven Partition und liest den Boot Record der Partition. Der Boot Record enthält Anweisungen zum Laden des Bootloaders LILO (LInux LOader). Anschließend lädt der MBR LILO, und LILO übernimmt den Prozess (wenn er auf dem MBR installiert wurde). In der standardmäßigen Konfiguration von Red Hat Linux verwendet LILO die MBR-Einstellungen, um die Bootoptionen anzuzeigen, und ermöglicht es dem Benutzer anzugeben, welches Betriebssystem effektiv gestartet werden soll.

An dieser Stelle ergibt sich die Frage: woher weiß LILO, was zu tun ist, wenn der MBR gelesen wurde? Antwort: LILO hat die Anweisungen bereits mithilfe von lilo mit der Konfigurationsdatei /etc/lilo.conf gelesen.

Optionen in /etc/lilo.conf

In den meisten Fällen wird es nicht notwendig sein, den MBR auf Ihrer Festplatte zu ändern, es sei denn, Sie müssen ein neu installiertes Betriebssystem booten oder einen neuen Kernel verwenden. Wenn Sie mithilfe von LILO und mit einer anderen Konfiguration einen neuen Kernel erstellen müssen, bearbeiten Sie /etc/lilo.conf und führen Sie erneut lilo aus.

WarnungWarnung
 

Wenn Sie /etc/lilo.conf bearbeiten möchten, sollten Sie eine Backup-Kopie erstellen, bevor Sie Änderungen vornehmen. Versichern Sie sich darüber hinaus, über eine funktionierende Diskette zu verfügen, so dass Sie das System booten und den MBR verändern können, wenn ein Problem auftreten sollte. Weitere Informationen finden Sie auf den man-Seiten über mkbootdisk.

lilo liest die Datei /etc/lilo.conf, in der festgelegt ist, welche(s) Betriebssystem(e) zu konfigurieren ist/sind bzw. welcher Kernel zu starten ist und wo sich LILO installieren soll (zum Beispiel /dev/hda für Ihre erste IDE-Festplatte). Eine Beispieldatei für /etc/lilo.conf sieht wie folgt aus:

boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
lba32
default=linux

image=/boot/vmlinuz-2.4.0-0.43.6
	label=linux
	initrd=/boot/initrd-2.4.0-0.43.6.img
	read-only
	root=/dev/hda5

other=/dev/hda1
	label=dos

Dieses Beispiel zeigt ein System, das konfiguriert wurde, um zwei Betriebssysteme zu booten: Red Hat Linux und DOS. Im Folgenden eine nähere Betrachtung einiger Zeilen dieser Datei (Ihre Datei /etc/lilo.conf sieht eventuell ein wenig anders aus):

LILO zeigt anschließend den Red Hat Linux Einstiegsbildschirm mit den verschiedenen Betriebssystemen oder Kerneln, für die er konfiguriert wurde. Wenn Sie ausschließlich Red Hat Linux installiert haben und in /etc/lilo.conf nichts geändert haben, wird nur linux als Option angezeigt. Wenn Sie LILO auf zum Booten eines anderen Betriebssystems konfiguriert haben, dann können Sie in diesem Bildschirm das System wählen, das Sie booten möchten. Markieren Sie es mithilfe der Pfeiltasten und drücken Sie die Eingabetaste.

Wenn Sie ein Prompt für die Eingabe von Befehlen für LILO zur Verfügung haben möchten, drücken Sie die Tastenkombination Ctrl-X. LILO zeigt das LILO: Prompt auf dem Bildschirm und lässt Ihnen eine voreingestellte Zeitspanne, um Eingaben vorzunehmen (diese Zeitspanne wird in der Zeile timeout in der Datei /etc/lilo.conf eingestellt). Wurde /etc/lilo.conf so eingestellt, dass mehrere Betriebssysteme angezeigt werden, können Sie an dieser Stelle die Kennung für das Betriebssystem eingeben, das Sie booten möchten.

Beim Booten von Linux bootet LILO zuerst den Kernel, bei dem es sich um eine vmlinuz-Datei (plus Versionsnummer, z.B. vmlinuz-2.4.0-xx) handelt, die sich im Verzeichnis /boot befindet. Dann übernimmt der Kernel den weiteren Bootprozess.

Linux ist an diesem Punkt bereits gestartet, wenn auch auf einem noch sehr einfachen Niveau. Ohne Anwendungen, die den Kernel verwenden, und ohne die Möglichkeit für den Benutzer, sinnvolle Eingaben in das System vorzunehmen, ist Linux noch nicht funktionstüchtig. Das Programm init löst dieses Problem, indem es all die Dienste liefert, die es dem System ermöglichen, seine Funktionen auszuführen.

Init

Der Kernel sucht init in /sbin und startet die Ausführung. init übernimmt den weiteren Bootprozess.

Init startet alle Prozesse Ihres Linux-Systems (und wird gleichzeitig zum Elternteil bzw. Großelternteil dieser Prozesse). Zuerst wird /etc/rc.d/rc.sysinit ausgeführt, wodurch Ihr Pfad eingestellt und Swapping gestartet wird, die Dateisysteme überprüft werden usw. rc.sysinit schafft alle Voraussetzungen, die für Ihr System zum Zeitpunkt der Systeminitialisierung erfüllt sein müssen. In einem vernetzten System verwendet rc.sysinit beispielsweise die Informationen in den Dateien /etc/sysconfig/network, um den Netzwerkprozess u zu initialisieren. Die meisten Systeme verwenden eine Uhr. In diesem Fall verwendet rc.sysinit die Datei /etc/sysconfig/clock, um die Uhr zu initialisieren. Außerdem wird rc.serial ausgeführt, falls Sie über serielle Port-Prozesse verfügen, die initialisiert werden müssen.

Init wertet anschließend die Datei /etc/inittab aus, die beschreibt, wie das System auf jedem Runlevel einzurichten ist, und legt das Standard-Runlevel fest (unter Abschnitt namens Init Runlevels finden Sie weitere Informationen über init-Runlevels). Diese Datei legt u.a. fest, dass /sbin/update beim Start eines Runlevels ausgeführt werden muss. Das Programm update gibt fehlerhafte Buffer auf der Festplatte wieder frei.

Sobald sich das Runlevel ändert, verwendet init die Skripten in /etc/rc.d/rc um verschiedene Dienste wie zum Beispiel Ihren Web-Server, den DNS-Server etc. zu starten und anzuhalten. Zuerst legt init die Quellfunktionsbibliothek für das System fest (normalerweise /etc/rc.d/init.d/functions), in der beschrieben ist, wie Programme zu starten/beenden sind und wie die PID eines Programms bestimmt werden kann. Anschließend bestimmt init das aktuelle und das vorige Runlevel.

Die Datei init startet alle Hintergrundprozesse, die für die Ausführung des Systems erforderlich sind, und sucht nach einem passenden rc-Verzeichnis für dieses Runlevel (/etc/rc.d/rc<x>.d, wobei das <x> eine Zahl zwischen 0 und 6 sein kann). init beendet alle kill-Skripten (ihr Dateiname beginnt mit einem K). Dann initialisiert es alle start-Skripten (ihr Dateiname beginnt mit einem S) im geeigneten Runlevel-Verzeichnis (so dass alle Dienste und Anwendungen korrekt gestartet werden). Sie können diese Skripten nach dem Booten des Systems auch manuell mit einem Befehl wie /etc/rc.d/init.d/httpd stop oder service httpd stop und als Root ausführen. Auf diese Weise wird der httpd Server gestoppt.

AnmerkungBitte beachten
 

Wenn Sie Dienste manuell starten, sollten Sie sich als Root anmelden. Tritt ein Fehler beim Ausführen von service httpd stop auf, besteht vielleicht kein /sbin-Pfad in /root/.bashrc (oder die korrekte .rc-Datei für Ihre bevorugte Shell). In diesem Fall können Sie entweder den vollständigen Befehl /sbin/service httpd stop eingeben oder in Ihrer .rc-Shell export PATH="$PATH:/sbin" hinzufügen. Wenn Sie die Konfigurationsdatei Ihrer Shell bearbeiten, müssen Sie sich abmelden und anschließend als Root wieder anmelden, um die geänderte Shell- Konfiguration anzuwenden.

Keiner der Skripten, die die Dienste starten und stoppen, befindet in /etc/rc.d/init.d. Alle Dateien in /etc/rc.d/rc<x>.d sind symbolische Links, die auf Skripten in /etc/rc.d/init.d zeigen. Ein symbolischer Link ist nichts anderes als eine Datei, die auf eine andere Datei zeigt. Sie werden in diesem Fall verwendet, da sie erstellt und gelöscht werden können, ohne sich auf das Skript auszuwirken, das den Dienst startet oder stoppt. Die symbolischen Links zu den verschiedenen Skripten sind in einer bestimmten Reihenfolge nummeriert, um in dieser Reihenfolge gestartet zu werden. Sie können die Reihenfolge, in der die Dienste gestartet oder gestoppt werden, ändern, indem Sie den Namen des symbolischen Links ändern, der sich auf das Skript bezieht, das den Dienst startet oder stoppt. Weiterhin ist es möglich, symbolischen Links dieselbe Nummer wie anderen symbolischen Links zu geben, wenn Sie möchten, dass der entsprechende Dienst unmittelbar vor oder nach einem anderen Dienst gestartet oder gestoppt wird.

Beispiel für Runlevel 5: init sucht im Verzeichnis /etc/rc.d/rc5.d und stellt Folgendes fest (Ihr System und Ihre Konfiguration entsprechen diesem Beispiel vielleicht nicht ganz):

K01pppoe -> ../init.d/pppoe
K05innd -> ../init.d/innd
K10ntpd -> ../init.d/ntpd
K15httpd -> ../init.d/httpd
K15mysqld -> ../init.d/mysqld
K15pvmd -> ../init.d/pvmd
K16rarpd -> ../init.d/rarpd
K20bootparamd -> ../init.d/bootparamd
K20nfs -> ../init.d/nfs
K20rstatd -> ../init.d/rstatd
K20rusersd -> ../init.d/rusersd
K20rwalld -> ../init.d/rwalld
K20rwhod -> ../init.d/rwhod
K25squid -> ../init.d/squid
K28amd -> ../init.d/amd
K30mcserv -> ../init.d/mcserv
K34yppasswdd -> ../init.d/yppasswdd
K35dhcpd -> ../init.d/dhcpd
K35smb -> ../init.d/smb
K35vncserver -> ../init.d/vncserver
K45arpwatch -> ../init.d/arpwatch
K45named -> ../init.d/named
K50snmpd -> ../init.d/snmpd
K54pxe -> ../init.d/pxe
K55routed -> ../init.d/routed
K60mars-nwe -> ../init.d/mars-nwe
K61ldap -> ../init.d/ldap
K65kadmin -> ../init.d/kadmin
K65kprop -> ../init.d/kprop
K65krb524 -> ../init.d/krb524
K65krb5kdc -> ../init.d/krb5kdc
K75gated -> ../init.d/gated
K80nscd -> ../init.d/nscd
K84ypserv -> ../init.d/ypserv
K90ups -> ../init.d/ups
K96irda -> ../init.d/irda
S05kudzu -> ../init.d/kudzu
S06reconfig -> ../init.d/reconfig
S08ipchains -> ../init.d/ipchains
S10network -> ../init.d/network
S12syslog -> ../init.d/syslog
S13portmap -> ../init.d/portmap
S14nfslock -> ../init.d/nfslock
S18autofs -> ../init.d/autofs
S20random -> ../init.d/random
S25netfs -> ../init.d/netfs
S26apmd -> ../init.d/apmd
S35identd -> ../init.d/identd
S40atd -> ../init.d/atd
S45pcmcia -> ../init.d/pcmcia
S55sshd -> ../init.d/sshd
S56rawdevices -> ../init.d/rawdevices
S56xinetd -> ../init.d/xinetd
S60lpd -> ../init.d/lpd
S75keytable -> ../init.d/keytable
S80isdn -> ../init.d/isdn
S80sendmail -> ../init.d/sendmail
S85gpm -> ../init.d/gpm
S90canna -> ../init.d/canna
S90crond -> ../init.d/crond
S90FreeWnn -> ../init.d/FreeWnn
S90xfs -> ../init.d/xfs
S95anacron -> ../init.d/anacron
S97rhnsd -> ../init.d/rhnsd
S99linuxconf -> ../init.d/linuxconf
S99local -> ../rc.local

Diese symbolischen Links weisen init an, Folgendes zu stoppen: pppoe, innd, ntpd, httpd, mysqld, pvmd, rarpd, bootparamd, nfs, rstatd, rusersd, rwalld, rwhod, squid, amd, mcserv, yppasswdd, dhcpd, smb, vncserver, arpwatch, named, snmpd, pxe, routed, mars-nwe, ldap, kadmin, kprop, krb524, krb5kdc, gated, nscd, ypserv, ups, and irda. Nachdem alle Prozesse geschlossen wurden, kontrolliert init im gleichen Verzeichnis und sucht nach Startskripten für kudzu, reconfig, ipchains, portmap, nfslock, autofs, random, netfs, apmd, identd, atd, pcmcia, sshd, rawdevices, xinetd, lpd, keytable, isdn, sendmail, gpm, canna, crond, FreeWnn, xfs, anacron, rhnsd, and linuxconf. Die letzte Aktion von init ist es, /etc/rc.d/rc.local zu starten, um alle speziellen Skripten auszuführen, die für diesen Host konfiguriert wurden. Das System läuft nun auf Runlevel 5.

Die Datei /etc/inittab erzeugt mit fork einen Terminalprozess für jede virtuelle Konsole (Anmelde-Prompts) für jedes Runlevel (die Runlevels 2-5 verfügen über sechs solcher Konsolen, Runlevel 1 (Einzelbenutzermodus) nur über eine Konsole, Runlevels 0 und 6 erhalten keine virtuellen Konsolen). getty öffnet tty-Zeilen, stellt die Modi ein, gibt das Anmelde-Prompt aus, stellt den Benutzernamen fest und initialisiert anschließend den Anmeldeprozess für diesen Benutzer. Auf diese Weise können sich die Benutzer authentifizieren und das System benutzen.

/etc/inittab weist init an, was zu tun ist, wenn der Benutzer die Tastenkombination Strg-Alt-Entf auf drückt. Da Red Hat Linux korrekt heruntergefahren und unmittelbar neu gestartet werden sollte, wird init angewiesen, in solchen Fällen den Befehl /sbin/shutdown -t3 -r now auszuführen. Darüber hinaus bestimmt /etc/inittab, was init im Falle eines Stromausfalls tun soll, wenn Ihr System mit einer UPS-Einheit verbunden ist.

Auf Runlevel 5 führt /etc/inittab ein Skript mit dem Namen /etc/X11/prefdm aus. Das prefdm führt den gewünschten X-Desktop-Manager (gdm, wenn Sie GNOME verwenden, kdm, wenn Sie sich für KDE entscheiden, oder xdm, wenn Sie AnotherLevel benutzen) entsprechend dem Inhalt des Verzeichnisses /etc/sysconfig/desktop aus.

Nun sollte ein Anmelde-Prompt erscheinen. Und der gesamte Prozess benötigte nur wenige Sekunden.

SysV Init

Init wird beim Booten vom Kernel ausgeführt. Es ist für das Starten aller normalen Prozesse verantwortlich, die beim Booten ausgeführt werden müssen: die Prozesse zum Anmelden am System, NFS-Dämonen, FTP-Dämonen und alle weiteren Prozesse, die Sie beim Booten Ihres Computers ausführen möchten.

SysV init setzt sich in der Linux-Welt immer mehr als Standard für die Steuerung des Startvorgangs durch. Der Grund: Es ist leichter bedienbar sowie leistungsfähiger und flexibler als das herkömmliche BSD-init.

SysV init unterscheidet sich von BSD init auch darin, dass die Konfigurationsdateien in einem Unterverzeichnis von /etc liegen und nicht direkt in /etc. Dieses Verzeichnis heißt /etc/rc.d. Es enthält rc, rc.local, rc.sysinit und die folgenden Verzeichnisse:

init.d
rc0.d
rc1.d
rc2.d
rc3.d
rc4.d
rc5.d
rc6.d

SysV init stellt jedes init-Runlevel mit einem eigenen Verzeichnis dar und verwendet hierzu init und symbolische Links in jedem Verzeichnis, um die Dienste zu starten und anzuhalten, wenn das System von einem Runlevel auf einen anderen übergeht.

Die Ereigniskette eines SysV-init-Bootvorgangs kann wie folgt kurz zusammengefasst werden:

Der Standardrunlevel wird in /etc/inittab bestimmt. Im oberen Teil des Bildschirms sollte eine Zeile erscheinen, die ungefähr wie folgt aussieht:

id:3:initdefault:

In diesem Beispiel gilt Standardrunlevel 3 (die Nummer nach der ersten Spalte). Wenn Sie das Level ändern möchten, können Sie /etc/inittab manuell bearbeiten. Gehen Sie hierbei jedoch sehr sorgfältig vor. Sollte trotzdem ein Fehler auftreten, können Sie das System mithilfe der Tastenkombination Strg-X neu starten und am boot: Prompt Folgendes eingeben:

boot:  linux single

Auf diese Weise sollten Sie in der Lage sein, den Einzelbenutzermodus zu booten, so dass Sie inittab wieder auf den vorherigen Wert einstellen können.

Im Folgenden werden die Informationen in den Dateien in /etc/sysconfig bearbeitet, die die Parameter bestimmen, die von den verschiedenen Systemdiensten beim Starten verwendet werden.