boot(7) Miscellaneous Information Manual boot(7) 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 grosserem Detail beschrieben. Hardware Nach dem Einschalten oder einem harten Zurucksetzen wird die Steuerung an ein Programm ubergeben, das in schreibgeschutztem Speicher (normalerweise PROM) liegt; aus historischen Grunden, die den PC betreffen, heisst dieses Programm oft >>das BIOS<<. Dieses Programm fuhrt normalerweise eine Reihe von Selbsttests der Maschine durch und greift auf nichtfluchtigen 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<< (nichtfluchtiger RAM) genannt. Die im NVRAM gespeicherten Parameter unterscheiden sich zwischen Systemen, aber minimal sollten sie festlegen, welches Gerat das Betriebssystemladeprogramm bereitstellen kann oder mindestens auf welchen Geraten danach gesucht werden kann; ein solches Gerat ist als >>das Systemstartgerat<< bekannt. Die Hardware-Systemstartstufe ladt das Betriebssystemladeprogramm von einer festen Position auf dem Systemladegerat und ubergibt ihm dann die Steuerung. Hinweis: Das Gerat, von dem das Betriebssystemladeprogramm gelesen wird, kann uber ein Netzwerk angehangt 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 Gerat zu finden, ihn zu laden und auszufuhren. Die meisten Betriebssystemladeprogramme erlauben eine interaktive Verwendung, um die Festlegung eines alternativen Kernels zu ermoglichen (vielleicht ein Ruckfallkernel, falls der letzte kompilierte nicht funktioniert) und optionale Parameter an den Kernel zu ubergeben. Auf einem traditionellen PC befindet sich das Betriebssystemladeprogramm in dem ersten 512-byte-Block des Systemstartgerats; dieser Block ist als >>der MBR<< (Master Boot Record) bekannt. Auf den meisten Systemen ist das Betriebssystemladeprogramm aufgrund verschiedener Beschrankungen sehr eingeschrankt. Selbst auf Nicht-PC-Systemen gibt es einige Beschrankungen der Grosse und der Komplexitat dieses Ladeprogramms, aber die Grossenbeschrankung des PC MBRs (512 bytes, einschliesslich der Partitionstabelle) macht es fast unmoglich, viel Funktionalitat dort hinein zu quetschen. Daher teilen die meisten Systeme die Rolle des Betriebssystemladens in ein primares Betriebssystemladeprogramm und ein sekundares Betriebssystemladeprogramm; dieses sekundare Betriebssystemladeprogramm kann sich auf einer grosseren 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 fur eine solche Aufgabe zustandige Softwareteil wird normalerweise als >>ein Treiber<< fur die zugehorige Komponente betrachtet. Der Kernel startet den Auslagerungsprozess fur virtuellen Speicher (das ist ein Kernelprozess, der bei einem modernen Linux-Kernel >>kswapd<< genannt wird) und hangt einige Dateisysteme am Wurzelpfad / ein. Einige an den Kernel ubergebbare Parameter beziehen sich auf diese Aktivitaten (beispielsweise kann das Wurzeldateisystem ausser Kraft gesetzt werden); fur weitere Informationen uber Linux-Kernelparameter lesen Sie bootparam(7). Erst dann erstellt der Kernel den anfanglichen Prozess im Anwendungsraum, dem die Nummer 1 als seine PID (Prozesskennung) gegeben wird. Traditionell fuhrt dieser Prozess das Programm /sbin/init aus, an den die Parameter ubergeben werden, die noch nicht vom Kernel berucksichtigt wurden. Wurzelprozess des Anwendungsraums Hinweis: Die folgende Beschreibung gilt fur ein auf UNIX System V Release 4 basierendes Betriebssystem. Eine Reihe von breit genutzten Systemen hat einen verwandten, aber fundamental verschiedenen Ansatz eingefuhrt, der als systemd(1) bekannt ist und dessen Systemstartprozess im Detail in seiner zugehorigen bootup(7) beschrieben ist. Wenn /sbin/init startet, liest es /etc/inittab fur weitere Anweisungen. Diese Datei definiert, was ausgefuhrt werden soll, wenn das Programm /sbin/init angewiesen wird, in einen bestimmten Runlevel einzutreten. Damit hat der Administrator eine einfache Moglichkeit, eine Umgebung fur 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 Ausfuhrung der meisten Netzwerkdienste.) Der Administrator kann den aktuellen Runlevel mit init(1) andern 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 tatsachlich die einzelnen Dienste starten bzw. stoppen. Systemstartskripte Hinweis: Die folgende Beschreibung gilt fur ein auf UNIX System V Release 4 basierendes Betriebssystem. Eine Reihe viel genutzter Systeme (Slackware Linux, FreeBSD, OpenBSD) haben allerdings ein leicht anderes Schema fur Systemstartskripte. Fur 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 ausgefuhrt, dann werden die moglichen 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 primares Skript (normalerweise /etc/rc) wird von inittab(5) aufgerufen; dieses primare Skript ruft jedes Dienste-Skript uber 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, enthalt 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 Ausfuhrung von /etc/rc2.d/S12syslog aber vor der Ausfuhrung 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 Moglichkeit hat, diese Eingaben zu andern, ohne gleich ein komplettes Startskript anpassen zu mussen, wird eine getrennte Konfigurationsdatei verwandt. Diese befindet sich in einem bestimmten Verzeichnis, wo die zugehorigen Systemstartskripte sie finden konnen (/etc/sysconfig auf alteren Red-Hat-Systemen). Auf alteren UNIX-Systemen enthielt eine solche Datei die tatsachlichen Befehlszeilenoptionen fur einen Daemon. Auf modernen Linux-Systemen (und auch bei HP-UX) enthalt 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) UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . Linux man-pages 6.06 31. Oktober 2023 boot(7)