1.2. Der Bootprozess im Detail

Der wirkliche Beginn des Bootprozesses hängt von der verwendeten Hardware-Plattform ab. Sobald jedoch der Kernel vom System gefunden und geladen wurde, ist der standardmäßige Bootprozess auf allen Architekturen identisch. Dieses Kapitel bezieht sich auf eine x86-Architektur.

1.2.1. Das BIOS

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

Andere Plattformen verwenden verschiedene Programme, um Aufgaben der niedrigen Ebene durchzuführen, die denen des BIOS auf einem x86-System stark ähneln. Itanium-basierte Computer zum Beispiel verwenden die Extensible Firmware Interface (EFI)-Shell, während Alpha-Systeme die SRM-Konsole verwenden.

Nach dem Start prüft das BIOS das System, sucht und prüft Peripheriegeräte und sucht dann nach einem gültigen Gerät zum Starten des Systems. Normalerweise prüft es zuerst die Disketten- und CD-ROM-Laufwerke auf startfähige Medien und sucht dann auf den Festplatten des Systems. Die Reihenfolge der zum Booten durchsuchten Laufwerke wird oft durch eine Einstellung auf dem BIOS gesteuert. Häufig ist die erste, zum Booten festgelegte Festplatte das Laufwerk C oder das Master-IDE-Gerät auf dem primären IDE-Bus. Das BIOS lädt das Programm, das im ersten Sektor dieses Geräts gespeichert ist und Master Boot Record oder MBR genannt wird, in den Speicher. Der MBR ist nur 512 Bytes groß und enthält vom Rechner lesbare Anweisungen zum Booten des Rechners zusammen mit der Partitionstabelle. Nach dem Laden prüft das BIOS das jeweilige Programm auf dem MBR.

1.2.2. Der Bootloader

In diesem Abschnitt werden die Bootloader für die x86-Plattform betrachtet. Je nach Systemarchitektur kann der Bootprozess leicht variieren. Unter Abschnitt 1.2.2.1 finden Sie einen kurzen Überblick zu nicht-x86 Bootloadern.

Unter Red Hat Enterprise Linux stehen zwei Bootloader zur Verfügung: GRUB oder LILO. GRUB ist der Default-Bootloader, LILO ist allerdings verfügbar für alle die diesen entweder benötigen oder vorziehen. Für weitere Informationen zum Konfigurieren von GRUB oder LILO, siehe Kapitel 2.

Die Linux-Bootloader für x86-Plattformen werden in mindestens zwei Phasen unterteilt. Die erste Phase ist ein kleiner binärer Rechnercode auf dem MBR. Seine einzige Aufgabe besteht im Suchen des Bootloaders der zweiten Phase und dem Laden des ersten Teils in den Arbeitsspeicher.

GRUB ist der neuere Bootloader und hat den Vorteil, dass er ext2 und ext3 [1] Partitionen lesen kann und seine Konfigurationsdatei — /boot/grub/grub.conf — zur Bootzeit laden kann. Sehen Sie Abschnitt 2.7 für Informationen zum Bearbeiten dieser Datei.

Unter LILO verwendet der Bootloader der 2. Phase die Informationen auf dem MBR, um zu ermitteln, welche Bootoptionen dem Benutzer zur Verfügung stehen. Dies bedeutet, dass Sie bei jeder Konfigurationsänderung oder manuellen Kernelaktualisierung den Befehl /sbin/lilo -v -v ausführen müssen, um die entsprechenden Informationen auf den MBR zu schreiben. Detaillierte Informationen hierzu finden Sie unter Abschnitt 2.8.

TippTipp
 

Wenn Sie ein Upgrade des Kernel mit Hilfe des Red Hat Update Agent durchführen, wird die Konfigurationsdatei des Bootloader automatisch aktualisiert. Weitere Informationen zu RHN finden Sie unter folgendem URL: https://rhn.redhat.com

Wenn der Bootloader der 2. Phase in den Arbeitsspeicher geladen ist, wird dem Benutzer der grafische Anfangsbildschirm mit den verschiedenen Betriebssystemen oder Kernels angezeigt, die gestartet werden sollen. Auf diesem Bildschirm kann ein Benutzer die Pfeiltasten benutzen, um ein Betriebssystem auszuwählen und dann die [Enter-Taste] drücken, um dieses zu booten. Sollte keine Taste gedrückt werden, wird der Bootloader nach einiger Zeit das standardmäßig ausgewählte Betriebsystem booten.

AnmerkungAnmerkung
 

Wenn SMP-Kernel-Support (Symmetric Multi-Processor) installiert ist, stehen Ihnen beim Erststart des Systems mehrere Optionen zur Verfügung. Unter LILO wird linux, für den SMP Kernel, und linux-up, für den Einzelprozessor, angezeigt. Unter GRUB wird Red Hat Enterprise Linux (<Kernelversion>-smp), für den SMP Kernel, und Red Hat Enterprise Linux (<Kernelversion>), für den Einzelprozessor, angezeigt.

Treten beim SMP-Kernel Probleme auf, wählen Sie einen nicht-SMP-Kernel beim Neustart aus.

Nachdem der Bootloader der 2. Phase den zu bootenden Kernel ermittelt hat, sucht er die entsprechende Binärdatei des Kernel im /boot-Verzeichnis. Die eigentliche Binärdatei ist die Datei /boot/vmlinuz-2.4.x-xx, die den Einstellungen des Bootloaders entspricht.

Informationen zum Benutzen des Bootloaders, um dem Kernel Befehlszeilenargumente zu übergeben, finden Sie unter Kapitel 2. Informationen zum Ändern des Runlevels am GRUB- oder LILO-Prompt finden Sie unter Abschnitt 2.10.

Anschließend legt der Bootloader das entsprechende Image der initialen RAM-Disk, initrd im Speicher ab. initrd wird vom Kernel zum Laden der nicht kompilierten Treiber verwendet, die zum Starten des Systems erforderlich sind. Dies ist besonders wichtig, wenn Sie SCSI-Festplatten haben oder das ext3 Dateisystem [2] verwenden.

WarnungWarnung
 

Entfernen Sie auf gar keinen Fall das /initrd/-Verzeichnis aus dem Dateisystem. Wenn dieses Verzeichnis entfernt wird, kann das System nicht starten und der Kernel meldet einen gravierenden Fehler.

Sobald der Kernel und das initrd-Image in den Speicher geladen sind, übergibt der Bootloader die Steuerung des Bootprozesses an den Kernel.

Für einen detaillierteren Überblick des GRUB und des LILO Bootloaders, sehen Sie Kapitel 2.

1.2.2.1. Bootloader für andere Architekturen

Ist der Kernel erst einmal geladen und übergibt den Bootprozess zum init Befehl, erfolgt die selbe Abfolge von Events auf jeder Architektur. Der Hauptunterschied zwischen den Bootprozessen der verschiedenen Architekturen liegt deshalb in der Applikation, welche zum Finden und Laden des Kernel verwendet wird.

Die Alpha-Architektur, zum Beispiel, verwendet den aboot Bootloader, die Itanium-Architektur den ELILO Bootloader, IBM pSeries verwendet YABOOT und IBM s390 Systeme den z/IPL Bootloader.

Lesen Sie das für die jeweilige Plattform spezifische Red Hat Enterprise Linux Installationshandbuch für Informationen zum Konfigurieren der Bootloader.

1.2.3. Der Kernel

Wenn der Kernel lädt, initialisiert und konfiguriert er sofort den Arbeitsspeicher des Computers. Anschließend wird die an das System angeschlossene Hardware konfiguriert, einschließlich aller Prozessoren und E/A-Subsysteme sowie alle Speichergeräte. Dann sucht er nach dem komprimierten initrd-Image an einem bestimmten Speicherort im Speicher, dekomprimiert es, mountet es und lädt alle notwendigen Treiber. Danach initialisiert er die mit dem Dateisystem verbundenen virtuellen Geräte wie LVM oder Software-RAID, bevor das initrd-Disk-Image dekomprimiert und der gesamte Speicher freigesetzt wird, der belegt war.

Nach dem Initialisieren aller Geräte des Systems erstellt der Kernel ein root-Gerät, mountet die root-Partition als schreibgeschützt und setzt nicht verwendeten Speicher frei.

Zu diesem Zeitpunkt ist der Kernel in den Speicher geladen und betriebsbereit. Allerdings ist das System ohne die Möglichkeit für den Benutzer, sinnvolle Eingaben vorzunehmen, nicht von großem Nutzen.

Der Kernel startet den Befehl /sbin/init, um die Benutzerumgebung einzurichten.

1.2.4. Das Programm /sbin/init

Das Programm /sbin/init (auch init genannt) koordiniert den verbleibenden Bootprozess und konfiguriert die Benutzerumgebung.

Wenn init gestartet wird, wird es automatisch der Elternprozess aller zukünftigen, auf dem System automatisch gestarteten, Prozesse. Zuerst führt es das /etc/rc.d/rc.sysinit-Skript aus, das den Umgebungspfad einstellt, Swapping startet, die Dateisysteme überprüft und andere Schritte der Systeminitialisierung übernimmt. rc.sysinit kümmert sich im Grunde um alle Prozesse, die beim Starten des Systems durchgeführt werden müssen. Die meisten Systeme verwenden zum Beispiel eine Uhr. In diesem Fall liest rc.sysinit die Konfigurationsdatei /etc/sysconfig/clock, um die Hardware-Uhr zu initialisieren. Falls Sie über spezielle serielle Portprozesse verfügen, die ebenfalls initialisiert werden müssen, führt rc.sysinit die Datei /etc/rc.serial aus.

Anschließend führt init das /etc/inittab-Skript aus, das beschreibt, wie das System auf jedem SysV init-Runlevel eingerichtet werden sollte [3]. Die Datei /etc/inittab legt u.a. den Standard-Runlevel fest und bestimmt, dass /sbin/update bei jedem Start eines bestimmten Runlevels ausgeführt werden muss. [4].

Danach legt init die Quellfunktionsbibliothek /etc/rc.d/init.d/functions für das System fest. In der Datei wird festgelegt, wie Programme zu starten oder zu beenden sind und wie die PID eines Programms bestimmt werden kann.

Danach startet init alle Hintergrundprozesse, indem es im entsprechenden rc-Verzeichnis nach den Runleveln sucht, die in /etc/inittab als Standard festgelegt sind. Die rc-Verzeichnisse sind gemäß den Runleveln nummeriert, die sie darstellen. So ist zum Beispiel /etc/rc.d/rc5.d/ das Verzeichnis für Runlevel 5.

Das Programm init sucht beim Starten auf Runlevel 5 im Verzeichnis /etc/rc.d/rc5.d/, um die Prozesse zu ermitteln, die gestartet und beendet werden müssen.

Folgend ist ein Beispiel-Listing für das Verzeichnis /etc/rc.d/rc5.d/:

K05innd -> ../init.d/innd
K05saslauthd -> ../init.d/saslauthd
K10psacct -> ../init.d/psacct
K10radiusd -> ../init.d/radiusd
K12mysqld -> ../init.d/mysqld
K15httpd -> ../init.d/httpd
K15postgresql -> ../init.d/postgresql
K16rarpd -> ../init.d/rarpd
K20iscsi -> ../init.d/iscsi
K20netdump-server -> ../init.d/netdump-server
K20nfs -> ../init.d/nfs
K20tomcat -> ../init.d/tomcat
K24irda -> ../init.d/irda
K25squid -> ../init.d/squid
K28amd -> ../init.d/amd
K34dhcrelay -> ../init.d/dhcrelay
K34yppasswdd -> ../init.d/yppasswdd
K35dhcpd -> ../init.d/dhcpd
K35smb -> ../init.d/smb
K35vncserver -> ../init.d/vncserver
K35winbind -> ../init.d/winbind
K36lisa -> ../init.d/lisa
K45arpwatch -> ../init.d/arpwatch
K45named -> ../init.d/named
K45smartd -> ../init.d/smartd
K46radvd -> ../init.d/radvd
K50netdump -> ../init.d/netdump
K50snmpd -> ../init.d/snmpd
K50snmptrapd -> ../init.d/snmptrapd
K50tux -> ../init.d/tux
K50vsftpd -> ../init.d/vsftpd
K54pxe -> ../init.d/pxe
K61ldap -> ../init.d/ldap
K65kadmin -> ../init.d/kadmin
K65kprop -> ../init.d/kprop
K65krb524 -> ../init.d/krb524
K65krb5kdc -> ../init.d/krb5kdc
K70aep1000 -> ../init.d/aep1000
K70bcm5820 -> ../init.d/bcm5820
K74ntpd -> ../init.d/ntpd
K74ypserv -> ../init.d/ypserv
K74ypxfrd -> ../init.d/ypxfrd
K84bgpd -> ../init.d/bgpd
K84ospf6d -> ../init.d/ospf6d
K84ospfd -> ../init.d/ospfd
K84ripd -> ../init.d/ripd
K84ripngd -> ../init.d/ripngd
K85zebra -> ../init.d/zebra
K92ipvsadm -> ../init.d/ipvsadm
K95firstboot -> ../init.d/firstboot
S00microcode_ctl -> ../init.d/microcode_ctl
S08ip6tables -> ../init.d/ip6tables
S08iptables -> ../init.d/iptables
S09isdn -> ../init.d/isdn
S10network -> ../init.d/network
S12syslog -> ../init.d/syslog
S13irqbalance -> ../init.d/irqbalance
S13portmap -> ../init.d/portmap
S14nfslock -> ../init.d/nfslock
S17keytable -> ../init.d/keytable
S20random -> ../init.d/random
S24pcmcia -> ../init.d/pcmcia
S25netfs -> ../init.d/netfs
S26apmd -> ../init.d/apmd
S28autofs -> ../init.d/autofs
S44acpid -> ../init.d/acpid
S55sshd -> ../init.d/sshd
S56rawdevices -> ../init.d/rawdevices
S56xinetd -> ../init.d/xinetd
S59hpoj -> ../init.d/hpoj
S80sendmail -> ../init.d/sendmail
S85gpm -> ../init.d/gpm
S90canna -> ../init.d/canna
S90crond -> ../init.d/crond
S90cups -> ../init.d/cups
S90FreeWnn -> ../init.d/FreeWnn
S90xfs -> ../init.d/xfs
S95atd -> ../init.d/atd
S97rhnsd -> ../init.d/rhnsd
S99local -> ../rc.local
S99mdmonitor -> ../init.d/mdmonitor

Wie Sie sehen, befindet sich keines der Skripte, die die Dienste starten und beenden, im Verzeichnis /etc/rc.d/rc5.d/. Vielmehr sind alle Dateien in /etc/rc.d/rc5.d/ symbolische Links, die auf Skripte im /etc/rc.d/init.d/-Verzeichnis zeigen. Symbolische Links werden in allen rc-Verzeichnissen verwendet, so dass die Runlevel durch Erstellen, Ändern und Löschen der symbolischen Links neu konfiguriert werden können, ohne dass die aktuellen Skripte davon betroffen werden, auf die sie verweisen.

Der Name jedes symbolischen Links beginnt entweder mit einem K oder einem S. Die K-Links sind Prozesse, die auf diesem Runlevel entfernt werden, während die Links gestartet werden, die mit einem S beginnen.

Zuerst beendet der Befehl init alle symbolischen K-Links im Verzeichnis mit Hilfe des Befehls /etc/rc.d/init.d/<Befehl> stop, wobei <Befehl> der zu beendende Prozess ist. Anschließend werden alle symbolischen S-Links mit Hilfe von /etc/rc.d/init.d/<Befehl> start gestartet.

TippTipp
 

Wenn das System den Bootvorgang beendet hat, können Sie sich als root anmelden und dieselben Skripte zum Starten und Beenden der Dienste ausführen. So beendet zum Beispiel der Befehl /etc/rc.d/init.d/httpd stop den Apache HTTP Server.

Alle symbolischen Links sind nummeriert, um die Startreihenfolge festzulegen. Sie können die Reihenfolge ändern, in der die Dienste gestartet oder beendet werden, indem Sie die Nummerierung ändern. Je kleiner die Nummer, desto früher wird gestartet. Die symbolischen Links mit derselben Nummer werden in alphabetischer Reihenfolge gestartet.

AnmerkungAnmerkung
 

Als eine der letzten Aktionen führt das Programm init alle Skripte aus, die sich in /etc/rc.d/rc.local befinden. Diese Datei ist nützlich für das Anpassen des Systems. Für mehr zur Verwendung von rc.local lesen Sie Abschnitt 1.3.

Nachdem der Befehl init das entsprechende rc-Verzeichnis für das Runlevel verarbeitet hat, sucht das Skript /etc/inittab einen /sbin/mingetty-Prozess für jede virtuelle Konsole (Anmeldebildschirme), die dem Runlevel zugewiesen ist. Runlevel 2 bis 5 rufen alle sechs virtuellen Konsolen auf, während Runlevel 1 (Einzelbenutzermodus) nur eine aufruft und Runlevel 0 und 6 gar keine. Der /sbin/mingetty-Prozess öffnet Kommunikationswege zu tty-Geräten[5],legt die Modi fest, druckt den Anmeldebildschirm, ruft den Benutzernamen ab und initiiert den Anmeldeprozess für den Benutzer.

Auf Runlevel 5 führt /etc/inittab das Skript /etc/X11/prefdm aus. Das prefdm-Skript führt den gewünschten X-Desktop-Manager[6] aus — gdm, kdm oder xdm, je nach Inhalt der Datei /etc/sysconfig/desktop.

Zu diesem Zeitpunkt ist das System im Runlevel 5 und zeigt den Anmeldebildschirm an.

Fußnoten

[1]

GRUB liest ext3 Dateisysteme als ext2, unabhängig von der Journal-Datei. Sehen Sie das Kapitel Das ext3 Dateisystem im Red Hat Enterprise Linux Handbuch zur System-Administration für mehr Informationen zum ext3 Dateisystem.

[2]

Detaillierte Informationen zum Erstellen von initrd, sehen Sie das Kapitel Das ext3 Dateisystem im Red Hat Enterprise Linux Handbuch zur System-Administration.

[3]

Weitere Informationen zu SysV init Runleves finden Sie unter Abschnitt 1.4.

[4]

Das update-Programm gibt fehlerhafte Buffer auf der Festplatte wieder frei.

[5]

Weitere Informationen zu tty-Geräten finden Sie unter Abschnitt 5.3.11.

[6]

Sehen Sie Abschnitt 7.5.2 für weitere Informationen zu Display-Managern.