1.2. Der Bootprozess im Detail

Der Beginn des Bootprozesses variiert in Abhängigkeit der verwendeten Hardware-Plattform. Sobald jedoch der Kernel vom System gefunden und geladen wurde, ist der standardmäßige Bootprozess auf allen Architekturen identisch. Dieses Kapitel fokussiert sich vorwiegend auf die 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 zur Verfügung. 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.

Einmal geladen, testet das BIOS das System, sucht und überprü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, Bootloader genannt, zusammen mit der Partitionstabelle. Nach dem Laden prüft das BIOS das jeweilige Programm auf dem MBR.

1.2.2. Der Bootloader

Dieser Abschnitt behandelt den standardmäßigen Bootloader für die x86-Plattform, GRUB. Je nach Systemarchitektur kann der Bootprozess leicht variieren. Unter dem Abschnitt 1.2.2.1 finden Sie einen kurzen Überblick zu nicht-x86 Bootloadern. Für weitere Informationen über die Konfiguration und Anwendung von GRUB siehe Kapitel 2.

Ein Bootloader für die x86-Plattform wird 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.

TippTipp
 

Wenn Sie ein Upgrade des Kernels mit Hilfe des Red Hat Update Agent durchführen, wird die Konfigurationsdatei des Bootloader automatisch aktualisiert. Weitere Informationen zu Red Hat Network finden Sie unter folgender 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 GRUB wird Red Hat Enterprise Linux (<kernel-version>-smp) für den SMP Kernel, und Red Hat Enterprise Linux (<kernel-version>) 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 Bootloader-Prompt finden Sie unter dem Abschnitt 2.8.

Anschließend legt der Bootloader dann ein passendes oder mehrere passende initramfs-Images im Speicher ab. Als nächstes dekomprimiert der Kernel diese Images vom Speicher und legt diese mittels dem Befehl cpio in /boot/ ab, einem RAM-basierten virtuellen Dateisystem. initramfs wird vom Kernel benutzt, um Treiber und Module, die zum Booten des Systems notwendig sind, zu laden. Dies ist besonders dann von Wichtigkeit, wenn SCSI Laufwerke vorhanden sind oder wenn das System das ext3 Dateisystem verwendet.

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

Für einen detaillierteren Überblick des GRUB Bootloaders siehe Kapitel 2.

1.2.2.1. Bootloader für andere Architekturen

Ist der Kernel erst einmal geladen und übergibt den Bootprozess an den 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 Kernels verwendet wird.

Die Itanium-Architektur verwendet beispielsweise den ELILO Bootloader, die IBM eServer pSeries verwendet YABOOT und die IBM eServer zSeries und IBM S/390 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 I/O-Subsysteme sowie aller Speichergeräte. Dann sucht er nach dem komprimierten initramfs-Image (oder den Images) an einem bestimmten Speicherort im Speicher, dekomprimiert es direkt nach /sysroot/ und lädt alle notwendigen Treiber. Danach initialisiert er die mit dem Dateisystem verbundenen virtuellen Geräte wie LVM oder Software-RAID, bevor die initramfs-Prozesse beendet und der gesamte Speicher freigesetzt wird, der einmal 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 Benutzer-Applikationen, die sinnvollen Input erlauben, nicht gerade 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 zum Elternprozess oder Groß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. Die meisten Systeme verwenden beispielsweise eine Uhr, wobei rc.sysinit die Konfigurationsdatei /etc/sysconfig/clock liest, um die Hardware-Uhr zu initialisieren. Falls Sie beispielsweise auch über spezielle, serielle Portprozesse verfügen, die ebenfalls initialisiert werden müssen, führt rc.sysinit die Datei /etc/rc.serial aus.

Der init-Befehl lässt sodann das /etc/inittab-Script ablaufen, welches beschreibt, wie das System in jedem einzelnen SysV Init Runlevel aufgesetzt werden sollte. Runlevels sind ein Zustand, oder Modus, durch die im SysV Verzeichnis /etc/rc.d/rc<x>.d/ enthaltenen Dienste definiert werden, wobei <x> die Nummer des Runlevels ist. Für weitere Informationen zu SysC Init Runlevels siehe Abschnitt 1.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, denen sie entsprechen. 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
K10dc_server -> ../init.d/dc_server
K10psacct -> ../init.d/psacct
K10radiusd -> ../init.d/radiusd
K12dc_client -> ../init.d/dc_client
K12FreeWnn -> ../init.d/FreeWnn
K12mailman -> ../init.d/mailman
K12mysqld -> ../init.d/mysqld
K15httpd -> ../init.d/httpd
K20netdump-server -> ../init.d/netdump-server
K20rstatd -> ../init.d/rstatd
K20rusersd -> ../init.d/rusersd
K20rwhod -> ../init.d/rwhod
K24irda -> ../init.d/irda
K25squid -> ../init.d/squid
K28amd -> ../init.d/amd
K30spamassassin -> ../init.d/spamassassin
K34dhcrelay -> ../init.d/dhcrelay
K34yppasswdd -> ../init.d/yppasswdd
K35dhcpd -> ../init.d/dhcpd
K35smb -> ../init.d/smb
K35vncserver -> ../init.d/vncserver
K36lisa -> ../init.d/lisa
K45arpwatch -> ../init.d/arpwatch
K45named -> ../init.d/named
K46radvd -> ../init.d/radvd
K50netdump -> ../init.d/netdump
K50snmpd -> ../init.d/snmpd
K50snmptrapd -> ../init.d/snmptrapd
K50tux -> ../init.d/tux
K50vsftpd -> ../init.d/vsftpd
K54dovecot -> ../init.d/dovecot
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
K74ypserv -> ../init.d/ypserv
K74ypxfrd -> ../init.d/ypxfrd
K85mdmpd -> ../init.d/mdmpd
K89netplugd -> ../init.d/netplugd
K99microcode_ctl -> ../init.d/microcode_ctl
S04readahead_early -> ../init.d/readahead_early
S05kudzu -> ../init.d/kudzu
S06cpuspeed -> ../init.d/cpuspeed
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
S15mdmonitor -> ../init.d/mdmonitor
S15zebra -> ../init.d/zebra
S16bgpd -> ../init.d/bgpd
S16ospf6d -> ../init.d/ospf6d
S16ospfd -> ../init.d/ospfd
S16ripd -> ../init.d/ripd
S16ripngd -> ../init.d/ripngd
S20random -> ../init.d/random
S24pcmcia -> ../init.d/pcmcia
S25netfs -> ../init.d/netfs
S26apmd -> ../init.d/apmd
S27ypbind -> ../init.d/ypbind
S28autofs -> ../init.d/autofs
S40smartd -> ../init.d/smartd
S44acpid -> ../init.d/acpid
S54hpoj -> ../init.d/hpoj
S55cups -> ../init.d/cups
S55sshd -> ../init.d/sshd
S56rawdevices -> ../init.d/rawdevices
S56xinetd -> ../init.d/xinetd
S58ntpd -> ../init.d/ntpd
S75postgresql -> ../init.d/postgresql
S80sendmail -> ../init.d/sendmail
S85gpm -> ../init.d/gpm
S87iiim -> ../init.d/iiim
S90canna -> ../init.d/canna
S90crond -> ../init.d/crond
S90xfs -> ../init.d/xfs
S95atd -> ../init.d/atd
S96readahead -> ../init.d/readahead
S97messagebus -> ../init.d/messagebus
S97rhnsd -> ../init.d/rhnsd
S99local -> ../rc.local

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 gekillt 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 diese 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 dens Runlevel verarbeitet hat, spaltet (forkt) das Skript /etc/inittab einen /sbin/mingetty-Prozess für jede virtuelle Konsole (Anmeldebildschirme) auf, 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 Kommunikationspfade zu tty-Geräten[2], 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[3] aus — gdm, kdm oder xdm, je nach Inhalt der Datei /etc/sysconfig/desktop.

Nach Beendigung diesen Vorganges 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. Wir verweisen auf das Kapitel Das ext3 Dateisystem im Red Hat Enterprise Linux Handbuch zur System-Administration für mehr Informationen zum ext3 Dateisystem.

[2]

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

[3]

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