Provided by: manpages-de_4.23.1-1_all 
BEZEICHNUNG
bootup - Systemstartprozess
BESCHREIBUNG
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 nach einem Wurzeldateisystem sucht.
Heutzutage ist die Implementierung ein »initramfs« – ein komprimiertes Archiv, das der Kernel in ein
Tmpfs extrahiert. 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.
SYSTEMVERWALTERSTART
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.
cryptsetup-pre.target veritysetup-pre.target
|
(verschiedene systemnahe v
API-VFS-Einhängungen: (verschiedene Cryptsetup/Veritysetup-Geräte…)
mqueue, configfs, | |
debugfs, …) v |
| cryptsetup.target |
| (verschiedene Auslagerungs- | | remote-fs-pre.target
| Geräte…) | | | |
| | | | | v
| v local-fs-pre.target | | | (Netzwerkdateisysteme)
| swap.target | | v v |
| | v | remote-cryptsetup.target |
| | (verschiedene systemnahe (verschiedene | remote-veritysetup.target |
| | Dienste: udevd, Einhänge- und | | remote-fs.target
| | tmpfiles, random Fsck-Dienste…) | | |
| | seed, sysctl, …) v | | _____________/
| | | local-fs.target | |
| | | | | |
\____|______|_______________ ______|___________/ |
\ / |
v |
sysinit.target |
| |
______________________/|\_____________________ |
/ | | | \ |
| | | | | |
v v | v | |
(verschiedene (verschiedene | (verschiedene | |
Timer…) Pfade…) | Sockets…) | |
| | | | | |
v v | v | |
timers.target paths.target | sockets.target | |
| | | | v |
v \_______ | _____/ rescue.service |
\|/ | |
v v |
basic.target rescue.target |
| |
________v____________________ |
/ | \ |
| | | |
v v v |
display- (verschiedene (verschiedene |
manager.service Systemdienste Systemdienste) |
| benötigt für | |
| graphische UIs) v v
| | multi-user.target
emergency.service | | |
| \_____________ | _____________/
v \|/
emergency.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 Timer-Units, von
Diensten, die erst später beim Systemstart verfügbar werden, abzuhängen.
STARTEN DES BENUTZERVERWALTERS
Der Systemverwalter startet für jeden Benutzer die Unit Benutzer@UID.service, die jeweils eine separate,
unprivilegierte Instanz von systemd für jeden Benutzer startet — den Benutzerverwalter. Ähnlich zum
Systemverwalter startet der Benutzerverwalter Units, die von default.target hereingezogen werden. Das
folgende Diagramm ist ein strukturelle Überblick über die gutbekannten Benutzer-Units. Für
nichtgraphische Sitzungen wird default.target verwandt. Wannimmer sich ein Benutzer in einer graphischen
Sitzung anmeldet, wird der Anmeldeverwalter das Ziel graphical-session.target starten, das die für die
graphische Sitzung benötigten Units hereinzieht. Eine Reihe von Zielen (auf der rechten Seite gezeigt)
werden gestartet, wenn eine bestimmte Hardware dem Benutzer zur Verfügung steht.
(verschiedene (verschiedene (verschiedene
Timer…) Pfade…) Sockets…) (Sound-Geräte)
| | | |
v v v v
timers.target paths.target sockets.target sound.target
| | |
\______________ _|_________________/ (Bluetooth-Geräte)
\ / |
V v
basic.target bluetooth.target
|
__________/ \_______ (Smartcard-Geräte)
/ \ |
| | v
| v smartcard.target
v graphical-session-pre.target
(verschiedene Benutzerdienste) | (Drucker)
| v |
| (Dienste für die graphische Sitzung) v
| | printer.target
v v
default.target graphical-session.target
HOCHFAHREN IN DIE INITRD
Systemd kann auch in der Initrd verwandt werden. Es erkennt die Initrd durch Prüfung auf die Datei
/etc/initrd-release. Das Vorgabe-Ziel in der Initrd ist initrd.target. Der Systemstartprozess ist bis zum
Ziel basic.target identisch zum Systemverwalterstart. Danach führt Systemd das besondere Ziel
initrd.target aus. Bevor irgendwelche Dateisysteme eingehängt werden, muss der Verwalter bestimmen, ob
das System aus dem Ruhezustand zurückkehren 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 initrd-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
SYSTEMVERWALTERABSCHALTVORGANG
Der Abschaltvorgang mit Systemd besteht auch aus verschiedenen Ziel-Units mit einiger minimaler
Ordnungsstruktur:
(Konflikt zu (Konflikt zu allen
allen System- Dateisystemeinhängungen,
diensten) Auslagerungen,
| Cryptsetup-/
| Veritysetup-
| Geräten, …)
| |
v v
shutdown.target umount.target
| |
\___________ __________/
\ /
v
(verschiedene systemnahe
Dienste)
|
v
final.target
|
___________________________/ \__________________________________
/ | | | \
| | | | |
v | | | |
systemd-reboot.service | | | |
| v | | |
| systemd-poweroff.service | | |
v | v | |
reboot.target | systemd-halt.service | |
v | v |
poweroff.target | systemd-kexec.service |
v | |
halt.target | systemd-soft-reboot.service
v |
kexec.target |
v
soft-reboot.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.
SIEHE AUCH
systemd(1), boot(7), systemd.special(7), systemd.target(5), systemd-halt.service(8), systemd-soft-reboot.service(8)
ANMERKUNGEN
1. GRUB
https://www.gnu.org/software/grub/
Ü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⟩.