Provided by: manpages-de_4.15.0-9_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 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.
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 ANFÄNGLICHE RAM-PLATTE (INITRD)
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 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 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.
SIEHE AUCH
systemd(1), boot(7), systemd.special(7), systemd.target(5), systemd-halt.service(8),
dracut(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⟩.