Provided by: manpages-de_2.5-1_all 
BEZEICHNUNG
bootup - Systemstartprozess
BESCHREIBUNG
Beim Systemstart sind eine Reihe von verschiedenen Komponenten beteiligt. Direkt nach dem
Start führt das BIOS eine minimale Hardware-Initialisierung durch und übergibt die
Steuerung an einen Boot-Lader auf einem dauerhaften Speichergerät. Dieser Boot-Lader wird
dann einen Betriebssystemkernel von Platte (oder über das Netz) aufrufen. Im Falle von
Linux extrahiert dieser Kernel (optional) eine anfängliche RAM-Platte (Initrd), wie diese
beispielsweise von dracut(8) generiert wurde, und führt diese aus. Diese sucht dann nach
dem Wurzeldateisystem (möglicherweise unter Verwendung von systemd(1)). Nachdem das
Wurzeldateisystem gefunden und eingehängt wurde, übergibt die Initrd die Steuerung an den
Systemverwalter des Rechners (wie systemd(1)), der im Betriebssystem-Image gespeichert
ist, der dann für die Untersuchung aller verbleibenden Hardware, dem Einhängen aller
notwendigen Dateisysteme und dem Erzeugen aller konfigurierten Dienste verantwortlich ist.
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, die für den Betrieb des Systems
notwendig sind, verantwortlich. Auf systemd(1)-Systemen ist dieser Vorgang in verschiedene
diskrete Schritte aufgeteilt, die als Target-Units offengelegt sind. (Siehe
systemd.target(5) für detaillierte Informationen über Target-Units.) Der
Systemstartvorgang ist hochparallelisiert, so dass die Reihenfolge, in der bestimmte
Target-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
Target-Units verfügbar, wie in systemd.special(7) aufgeführt.
Das nachfolgende Diagramm gibt einen strukturellen Überblick über diese gut bekannten
Units und ihrer 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
Timer…) 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
Target-Units, die typischerweise als Systemstart-Tagets verwandt werden, sind
hervorgehoben. Diese Units sind eine gute Wahl für Ziel-Targets, 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.
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:
Das Vorgabe-Target 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 Target initrd.target. Bevor irgendwelche Dateisysteme
einghä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
SYSTEMVERWALTERABSCHALTVORGANG
Der Abschaltvorgang mit Systemd besteht auch aus verschiedenen Target-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 betont.
SIEHE AUCH
systemd(1), boot(7), systemd.special(7), systemd.target(5), dracut(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 <debian-l10n-german@lists.debian.org>.