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

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