Ubuntu Manpage: boot - Systemhochfahrprozess, basierend auf UNIX System V Release 4

bezeichnung
beschreibung
dateien
siehe auch
übersetzung

BEZEICHNUNG

       boot - Systemhochfahrprozess, basierend auf UNIX System V Release 4

BESCHREIBUNG

Der Systemstartprozess (oder die »Hochfahrsequenz«) unterscheidet sich im Detail zwischen den Systemen,
kann aber grob in Phasen eingeteilt werden, die von folgenden Komponenten gesteuert werden:

(1) Hardware

(2) Betriebssystem- (OS-)Ladeprogramm

(3) Kernel

(4) Wurzel-Anwendungsraum-Prozess (init und inittab)

(5) Systemstartskripte

Jeder dieser wird nachfolgend in größerem Detail beschrieben.

Hardware
Nach dem Einschalten oder einem harten Zurücksetzen wird die Steuerung an ein Programm übergeben, das in
schreibgeschütztem Speicher (normalerweise PROM) liegt; aus historischen Gründen, die den PC betreffen,
heißt dieses Programm oft »das BIOS«.

Dieses Programm führt normalerweise eine Reihe von Selbsttests der Maschine durch und greift auf
nichtflüchtigen Speicher zu, um weitere Parameter zu lesen. Dieser Speicher im PC wird durch Batterien
gesichert, daher verweisen die meisten Leute in der PC-Welt auf »das CMOS«, ansonsten wird es
normalerweise »das NVRAM« (nichtflüchtiger RAM) genannt.

Die im NVRAM gespeicherten Parameter unterscheiden sich zwischen Systemen, aber minimal sollten sie
festlegen, welches Gerät das Betriebssystemladeprogramm bereitstellen kann oder mindestens auf welchen
Geräten danach gesucht werden kann; ein solches Gerät ist als »das Systemstartgerät« bekannt. Die
Hardware-Systemstartstufe lädt das Betriebssystemladeprogramm von einer festen Position auf dem
Systemladegerät und übergibt ihm dann die Steuerung.

Hinweis:
Das Gerät, von dem das Betriebssystemladeprogramm gelesen wird, kann über ein Netzwerk angehängt
sein. In diesem Fall werden die Systemladedetails weiter in Protokollen wie DHCP, TFTP, PXE,
Etherboot usw. festgelegt.

Betriebssystemladeprogramm
Die Hauptaufgabe des Betriebssystemladeprogramms ist es, den Kernel auf einem Gerät zu finden, ihn zu
laden und auszuführen. Die meisten Betriebssystemladeprogramme erlauben eine interaktive Verwendung, um
die Festlegung eines alternativen Kernels zu ermöglichen (vielleicht ein Rückfallkernel, falls der letzte
kompilierte nicht funktioniert) und optionale Parameter an den Kernel zu übergeben.

Auf einem traditionellen PC befindet sich das Betriebssystemladeprogramm in dem ersten 512-byte-Block des
Systemstartgeräts; dieser Block ist als »der MBR« (Master Boot Record) bekannt.

Auf den meisten Systemen ist das Betriebssystemladeprogramm aufgrund verschiedener Beschränkungen sehr
eingeschränkt. Selbst auf Nicht-PC-Systemen gibt es einige Beschränkungen der Größe und der Komplexität
dieses Ladeprogramms, aber die Größenbeschränkung des PC MBRs (512 bytes, einschließlich der
Partitionstabelle) macht es fast unmöglich, viel Funktionalität dort hinein zu quetschen.

Daher teilen die meisten Systeme die Rolle des Betriebssystemladens in ein primäres
Betriebssystemladeprogramm und ein sekundäres Betriebssystemladeprogramm; dieses sekundäre
Betriebssystemladeprogramm kann sich auf einer größeren Portion des dauerhaften Speichers befinden,
beispielsweise einer Plattenpartition.

Unter Linux ist das Betriebssystemladeprogramm oft grub(8) (lilo(8) ist eine Alternative).

Kernel
Wenn der Kernel geladen wird, initialisiert er verschiedene Komponenten des Computers und
Betriebssystems; jeder für eine solche Aufgabe zuständige Softwareteil wird normalerweise als »ein
Treiber« für die zugehörige Komponente betrachtet. Der Kernel startet den Auslagerungsprozess für
virtuellen Speicher (das ist ein Kernelprozess, der bei einem modernen Linux-Kernel »kswapd« genannt
wird) und hängt einige Dateisysteme am Wurzelpfad / ein.

Einige an den Kernel übergebbare Parameter beziehen sich auf diese Aktivitäten (beispielsweise kann das
Wurzeldateisystem außer Kraft gesetzt werden); für weitere Informationen über Linux-Kernelparameter lesen
Sie bootparam(7).

Erst dann erstellt der Kernel den anfänglichen Prozess im Anwendungsraum, dem die Nummer 1 als seine PID
(Prozesskennung) gegeben wird. Traditionell führt dieser Prozess das Programm /sbin/init aus, an den die
Parameter übergeben werden, die noch nicht vom Kernel berücksichtigt wurden.

Wurzelprozess des Anwendungsraums
Hinweis:
Die folgende Beschreibung gilt für ein auf UNIX System V Release 4 basierendes Betriebssystem.
Eine Reihe von breit genutzten Systemen hat einen verwandten, aber fundamental verschiedenen
Ansatz eingeführt, der als systemd(1) bekannt ist und dessen Systemstartprozess im Detail in
seiner zugehörigen bootup(7) beschrieben ist.

Wenn /sbin/init startet, liest es /etc/inittab für weitere Anweisungen. Diese Datei definiert, was
ausgeführt werden soll, wenn das Programm /sbin/init angewiesen wird, in einen bestimmten Runlevel
einzutreten. Damit hat der Administrator eine einfache Möglichkeit, eine Umgebung für einen bestimmten
Anwendungsfall einzurichten; jedem Runlevel wird ein Satz an bestimmten Diensten zugeordnet.
(Beispielsweise ist Runlevel S der Einzelbenutzer-Modus und Runlevel 2 bedeutet die Ausführung der
meisten Netzwerkdienste.)

Der Administrator kann den aktuellen Runlevel mit init(1) ändern und den aktuellen Runlevel mittels
runlevel(8) abfragen.

Da es allerdings nicht praktisch ist, individuelle Dienste durch Bearbeitung dieser Datei zu verwalten,
startet /etc/inittab eine Reihe von Skripten, die dann tatsächlich die einzelnen Dienste starten bzw.
stoppen.

Systemstartskripte
Hinweis:
Die folgende Beschreibung gilt für ein auf UNIX System V Release 4 basierendes Betriebssystem.
Eine Reihe viel genutzter Systeme (Slackware Linux, FreeBSD, OpenBSD) haben allerdings ein leicht
anderes Schema für Systemstartskripte.

Für jeden verwalteten Dienst (E-Mail, NFS-Server, Cron usw.) gibt es ein einzelnes Startskript, das sich
in einem bestimmten Verzeichnis (/etc/init.d in den meisten Linux-Versionen) befindet. Jedes dieser
Skripte akzeptiert als einziges Argument »start« (wodurch der Dienst gestartet wird) oder »stop« (wodurch
der Dienst gestoppt wird). Das Skript kann optional weitere »Bequemlichkeitsparameter« akzeptieren (z.B.
»restart«, um den Dienst zu stoppen und dann zu starten, »status«, um den Dienstestatus anzuzeigen usw.).
Wird das Skript ohne Parameter ausgeführt, dann werden die möglichen Argumente angezeigt.

Ablaufverzeichnisse
Damit bestimmte Skripte in bestimmten Runleveln in einer bestimmten Reihenfolge starten/stoppen, gibt es
Ablaufverzeichnisse, normalerweise der Form /etc/rc[0-6S].d. In jedem dieser Verzeichnisse gibt es Links
(normalerweise symbolische) auf die Skripte im Verzeichnis /etc/init.d.

Ein primäres Skript (normalerweise /etc/rc) wird von inittab(5) aufgerufen; dieses primäre Skript ruft
jedes Dienste-Skript über einen Symlink im relevanten Ablaufverzeichnis auf. Jeder Link, dessen Name mit
»S« beginnt, wird mit dem Argument »start« aufgerufen (und startet daher den Dienst). Jeder Link, dessen
Name mit »K« beginnt, wird mit dem Argument »stop« aufgerufen (und stoppt damit den Dienst).

Um innerhalb des gleichen Runlevels die Start- oder Stoppreihenfolge zu definieren, enthält der Link eine
Ordnungsnummer. Zur Klarheit endet der Linkname normalerweise mit dem Dienstenamen, auf den er sich
bezieht. Beispielsweise startet der Link /etc/rc2.d/S80sendmail den Dienst sendmail(8) im Runlevel 2.
Dies passiert nach der Ausführung von /etc/rc2.d/S12syslog aber vor der Ausführung von /etc/rc2.d/S90xfs.

Durch Verwaltung dieser Links werden die Systemstartreihenfolge und Runlevel gesteuert; unter vielen
Systemen gibt es Werkzeuge, um bei dieser Aufgabe zu helfen (z.B. chkconfig(8)).

Systemstartkonfiguration
Ein Programm, das einen Dienst bereitstellt, wird oft »Daemon« genannt. Normalerweise kann ein Daemon
viele Befehlszeilenoptionen und -parameter empfangen. Damit ein Systemadministrator die Möglichkeit hat,
diese Eingaben zu ändern, ohne gleich ein komplettes Startskript anpassen zu müssen, wird eine getrennte
Konfigurationsdatei verwandt. Diese befindet sich in einem bestimmten Verzeichnis, wo die zugehörigen
Systemstartskripte sie finden können (/etc/sysconfig auf älteren Red-Hat-Systemen).

Auf älteren UNIX-Systemen enthielt eine solche Datei die tatsächlichen Befehlszeilenoptionen für einen
Daemon. Auf modernen Linux-Systemen (und auch bei HP-UX) enthält sie aber nur Shell-Variablen. Ein
Systemstartskript in /etc/init.d liest diese Konfigurationsdatei und bindet sie ein (englisch »sources«)
und verwendet dann die Variablenwerte.

DATEIEN

       /etc/init.d/, /etc/rc[S0-6].d/, /etc/sysconfig/

SIEHE AUCH

       init(1), systemd(1), inittab(5), bootparam(7), bootup(7), runlevel(8), shutdown(8)

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

       Diese  Übersetzung  ist  Freie  Dokumentation;  lesen  Sie  die  GNU  General  Public  License  Version 3
       ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE
       HAFTUNG übernommen.

       Wenn  Sie  Fehler  in  der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die
       Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.