Arch manual pages

BOOTUP(7) bootup BOOTUP(7)

bootup - Systemstartprozess

Beim Systemstart eines Linux-Systems sind eine Reihe von verschiedenen Komponenten beteiligt. Direkt nach dem Einschalten führt die Systemfirmware eine minimale Hardware-Initialisierung durch. Dann wird die Steuerung an einen auf dem dauerhaften Speichergerät gespeicherten Bootloader (z.B.systemd-boot(7) oder GRUB[1]) abgegeben. Dieser Bootloader wird dann einen Betriebssystemkernel von der Platte (oder dem Netzwerk) aufrufen. Auf Systemen, die EFI oder andere Arten von Firmware verwenden, kann diese Firmware auch den Kernel direkt laden.

Der Kernel hängt (optional) ein speicherinternes Dateisystem ein, das oft mittels dracut(8) erstellt wurde und ein Wurzeldateisystem sucht. Heutzutage ist die Implementierung normalerweise ein Initramfs — ein komprimiertes Archiv, das entpackt wird, wenn der Kernel in ein leichtgewichtiges, auf Tmpfs basierendes, speicherinternes Dateisystem startet. In der Vergangenheit wurden dafür normale Dateisysteme unter Verwendung eines speicherinternen Blockgerätes (Ramdisk) verwandt und der Name »Initrd« wird weiterhin für die Beschreibung beider Konzepte verwandt. Der Bootloader oder die Firmware lädt sowohl den Kernel als auch die Initrd/das Initramfs in den Speicher, aber der Kernel interpretiert es als Dateisystem. systemd(1) kann zur Verwaltung von Diensten in der Initrd, ähnlich wie bei einem realen System, verwandt werden.

Nachdem das Wurzeldateisystem gefunden wurde und eingehängt worden ist, übergibt die Initrd die Steuerung an den Systemverwalter (wie systemd(1)) des eigentlichen Systems. Dieser ist im Wurzeldateisystem gespeichert und ist für die Erkennung der verbleibenden Hardware, dem Einhängen aller notwendigen Dateisysteme und dem Starten aller konfigurierten Dienste verantwortlich.

Beim Herunterfahren beendet der Systemverwalter alle Dienste, hängt alle Dateisysteme aus (trennt alle hinterlegten Speichertechniken ab) und springt dann (optional) zurück in den Initrd-Code, der das Wurzeldateisystem und den Speicher, auf dem es liegt, aushängt und abtrennt. Als letzten Schritt wird das System ausgeschaltet.

Zusätzliche Informatioen über den Systemstartprozess können in boot(7) gefunden werden.

Beim Systemstart ist der Systemverwalter im Betriebssystem-Image für die Initialisierung der benötigten Dateisysteme, Dienste und Treiber verantwortlich, die für den Betrieb des Systems notwendig sind. Auf systemd(1)-Systemen ist dieser Vorgang in verschiedene diskrete Schritte aufgeteilt, die als Ziel-Units offengelegt sind. (Siehe systemd.target(5) für detaillierte Informationen über Ziel-Units.) Der Systemstartvorgang ist in hohem Maße parallelisiert, so dass die Reihenfolge, in der bestimmte Ziel-Units erreicht werden, nicht deterministisch ist, aber dennoch in einem begrenzten Umfang einer Ordnungsstruktur folgt.

Wenn Systemd das System hochfährt, wird es standardmäßig alle Units aktivieren, die Abhängigkeiten von default.target sind (sowie rekursiv alle Abhängigkeiten dieser Abhängigkeiten). Normalerweise ist default.target einfach ein Alias von graphical.target oder multi-user.target, abhängig davon, ob das Ssytem für eine graphische Benutzerschnittstelle oder nur für eine Textkonsole konfiguriert ist. Um eine minimale Ordnung zwischen den hereingezogenen Units zu erzwingen, sind eine Reihe von gut bekannten Ziel-Units verfügbar, wie in systemd.special(7) aufgeführt.

Das nachfolgende Diagramm gibt einen strukturellen Überblick über diese gut bekannten Units und ihre Position in der Systemstartlogik. Die Pfeile beschreiben, welche Units hereingezogen und vor welchen anderen Units sortiert werden. Units im oberen Bereich werden vor Units im unteren Bereich des Diagramms gestartet.

local-fs-pre.target
         |
         v
(verschiedene Einhänge-  (verschiedene Swap-  (verschiedene Cryptsetup-
 und fsck-Dienste…)            Geräte…)                Geräte…)       (verschiedene systemnahe  (verschiedene systemnahe
         |                         |                        |          Dienste: Udevd,Tmpfiles    API-VFS-Einhängungen:
         v                         v                        v          Zufallszahlenstartwerte,     Mqueue, Configfs,
  local-fs.target             swap.target           cryptsetup.target        Sysctl, …)               Debugfs, …)
         |                         |                        |                      |                      |
         \_________________________|_______________________ | _____________________|______________________/
                                              \|/
                                               v
                                        sysinit.target
                                               |
          ____________________________________/|\________________________________________
         /                  |                  |                    |                    \
         |                  |                  |                    |                    |
         v                  v                  |                    v                    v
   (verschiedene      (verschiedene            |              (verschiedene         rescue.service
    Zeitgeber…)          Pfade…)               |                 Sockets…)               |
         |                  |                  |                    |                    v
         v                  v                  |                    v              rescue.target
   timers.target      paths.target             |             sockets.target
         |                  |                  |                    |
         v                  \_________________ | ___________________/
                                              \|/
                                               v
                                         basic.target
                                               |
          ____________________________________/|                                 emergency.service
         /                  |                  |                                         |
         |                  |                  |                                         v
         v                  v                  v                                 emergency.target
     display-         (verschiedene      (verschiedene
 manager.service      Systemdienste      Systemdienste)
         |             benötigt für            |
         |        graphische Oberflächen)      v
         |                  |           multi-user.target
         |                  |                  |
         \_________________ | _________________/
                           \|/
                            v
                  graphical.target

Ziel-Units, die typischerweise als Systemstart-Ziele verwandt werden, sind hervorgehoben. Diese Units sind eine gute Wahl für Ziele, beispielsweise, indem sie an die Befehlszeilenoption systemd.unit= des Kernels übergeben werden (siehe systemd(1)) oder indem default.target auf sie verlinkt wird.

timers.target wird asynchron von basic.target hereingezogen. Dies ermöglicht es Zeitgeber-Units, von Diensten, die erst später beim Systemstart verfügbar werden, abzuhängen.

Die Implementierung der anfänglichen RAM-Platte (Initrd) kann auch mit Systemd eingerichtet werden. In diesem Fall folgt der Systemstart innerhalb der Initrd der folgenden Struktur:

Systemd erkennt durch Überprüfung der Datei /etc/initrd-release, dass es innerhalb einer Initrd läuft. Das Vorgabe-Ziel in der Initrd ist initrd.target. Der Systemstartprozess beginnt identisch zum Systemverwalterstart (siehe oben), bis er basic.target erreicht. Von hier geht Systemd auf das besondere Ziel initrd.target. Bevor irgendwelche Dateisysteme eingehängt werden, muss bestimmt werden, ob das System aus dem Ruhezustand zurückkehrt oder ob mit dem normalen Systemstart fortgefahren werden soll. Dies wird durch systemd-hibernate-resume@.service erreicht, der vor dem local-fs-pre.target fertig werden muss, so das keine Dateisystem eingehängt werden können, bevor die Prüfung abgeschlossen ist. Wenn das Wurzeldateisystem verfügbar wird, ist initd-root-device.target erreicht. Falls das Wurzelverzeichnis als /sysroot eingehängt werden kann, wird die Unit sysroot.mount aktiv und initrd-root-fs.target ist erreicht. Der Dienst initrd-parse-etc.service durchsucht /sysroot/etc/fstab nach einem möglichen Einhängepunkt für /usr und zusätzlichen Einträgen, die mit der Option x-initrd.mount markiert sind. Alle gefundenen Einträge werden unter /sysroot eingehängt und initrd-fs.target ist erreicht. Der Dienst initrd-cleanup.service isoliert zu dem initrd-switch-root.target, in dem Aufräumdienste laufen können. Als allerletzten Schritt wird initrd-switch-root.service aktiviert, das dazu führt, dass das System seine Wurzel auf /sysroot umschaltet.

                                               : (Anfang identisch zu oben)
                                               :
                                               v
                                         basic.target
                                               |                                 emergency.service
                        ______________________/|                                         |
                       /                       |                                         v
                       |            initrd-root-device.target                    emergency.target
                       |                       |
                       |                       v
                       |                  sysroot.mount
                       |                       |
                       |                       v
                       |             initrd-root-fs.target
                       |                       |
                       |                       v
                       v            initrd-parse-etc.service
                (custom initrd                 |
                 services...)                  v
                       |            (sysroot-usr.mount und
                       |        verschiedene Einhängungen markiert
                       |               mit Fstab-Option
                       |              x-initrd.mount…)
                       |                       |
                       |                       v
                       |                initrd-fs.target
                       \______________________ |
                                              \|
                                               v
                                          initrd.target
                                               |
                                               v
                                     initrd-cleanup.service
                                          isoliert zu
                                    initrd-switch-root.target
                                               |
                                               v
                        ______________________/|
                       /                       v
                       |        initrd-udevadm-cleanup-db.service
                       v                       |
              (angepasste Initrd-              |
                   Dienste…)                   |
                       \______________________ |
                                              \|
                                               v
                                   initrd-switch-root.target
                                               |
                                               v
                                   initrd-switch-root.service
                                               |
                                               v
                               Übergang ins Hauptbetriebssystem

Der Abschaltvorgang mit Systemd besteht auch aus verschiedenen Ziel-Units mit einiger minimaler Ordnungsstruktur:

                                  (conflicts with  (conflicts with
                                    all system     all file system
                                     services)     mounts, swaps,
                                         |           cryptsetup
                                         |          devices, ...)
                                         |                |
                                         v                v
                                  shutdown.target    umount.target
                                         |                |
                                         \_______   ______/
                                                 \ /
                                                  v
                                         (various low-level
                                              services)
                                                  |
                                                  v
                                            final.target
                                                  |
            _____________________________________/ \_________________________________
           /                         |                        |                      \
           |                         |                        |                      |
           v                         v                        v                      v
systemd-reboot.service   systemd-poweroff.service   systemd-halt.service   systemd-kexec.service
           |                         |                        |                      |
           v                         v                        v                      v
    reboot.target             poweroff.target            halt.target           kexec.target

Häufig verwandte Ziele beim Herunterfahren des Systems sind hervorgehoben.

Beachten Sie, dass systemd-halt.service(8), systemd-reboot.service, systemd-poweroff.service und systemd-kexec.service das System und den Diensteverwalter (PID 1) in die zweite Phase des Systemherunterfahrens überleiten (was im Programm systemd-shutdown implementiert ist). Dieser wird in einer einfachen und robusten Weise alle verbleibenden Dateisysteme aushängen, alle verbleibenden Prozesse töten und alle verbleibenden Ressourcen freigeben, ohne das Dienste- oder Unit-Konzept noch in Betracht zu ziehen. Zu diesem Zeitpunkt sind gewöhnliche Anwendungen und Ressourcen im Allgemeinen bereits beendet und freigegeben, die zweite Phase agiert daher nur als Sicherheitsnetz für alles, das aus irgendeinem Grund nicht während des oben beschriebenen, primären, Unit-basierten Herunterfahrens beendet oder freigegeben werden konnte.

systemd(1), boot(7), systemd.special(7), systemd.target(5), systemd-halt.service(8), dracut(8)

1.
GRUB
https://www.gnu.org/software/grub/

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 <debian-l10n-german@lists.debian.org>.

systemd 242