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 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.

Linux man-pages 6.9.1                              2. Mai 2024                                           boot(7)