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 entweder lilo(8) oder grub(8).

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.