Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux Rerenzhandbuch- Der Bootprozess im Detail

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.

 
 
  Published under the terms of the GNU General Public License Design by Interspire