BOOTUP(7) bootup BOOTUP(7) BEZEICHNUNG bootup - Systemstartprozess BESCHREIBUNG Beim Systemstart eines Linux-Systems sind eine Reihe von verschiedenen Komponenten beteiligt. Direkt nach dem Einschalten fuhrt die Systemfirmware eine minimale Hardware-Initialisierung durch. Dann wird die Steuerung an einen auf dem dauerhaften Speichergerat 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 hangt (optional) ein speicherinternes Dateisystem ein, das oft mittels dracut(8) erstellt wurde und ein Wurzeldateisystem sucht. Heutzutage ist die Implementierung ein >>initramfs<< - ein komprimiertes Archiv, das der Kernel in ein Tmpfs extrahiert. In der Vergangenheit wurden dafur normale Dateisysteme unter Verwendung eines speicherinternen Blockgerates (Ramdisk) verwandt und der Name >>Initrd<< wird weiterhin fur die Beschreibung beider Konzepte verwandt. Der Bootloader oder die Firmware ladt 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, ahnlich wie bei einem realen System, verwandt werden. Nachdem das Wurzeldateisystem gefunden wurde und eingehangt worden ist, ubergibt die Initrd die Steuerung an den Systemverwalter (wie systemd(1)) des eigentlichen Systems. Dieser ist im Wurzeldateisystem gespeichert und ist fur die Erkennung der verbleibenden Hardware, dem Einhangen aller notwendigen Dateisysteme und dem Starten aller konfigurierten Dienste verantwortlich. Beim Herunterfahren beendet der Systemverwalter alle Dienste, hangt alle Dateisysteme aus (trennt alle hinterlegten Speichertechniken ab) und springt dann (optional) zuruck in den Initrd-Code, der das Wurzeldateisystem und den Speicher, auf dem es liegt, aushangt und abtrennt. Als letzten Schritt wird das System ausgeschaltet. Zusatzliche Informatioen uber den Systemstartprozess konnen in boot(7) gefunden werden. SYSTEMVERWALTERSTART Beim Systemstart ist der Systemverwalter im Betriebssystem-Image fur die Initialisierung der benotigten Dateisysteme, Dienste und Treiber verantwortlich, die fur 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) fur detaillierte Informationen uber Ziel-Units.) Der Systemstartvorgang ist in hohem Masse 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 hochfahrt, wird es standardmassig alle Units aktivieren, die Abhangigkeiten von default.target sind (sowie rekursiv alle Abhangigkeiten dieser Abhangigkeiten). Normalerweise ist default.target einfach ein Alias von graphical.target oder multi-user.target, abhangig davon, ob das Ssytem fur eine graphische Benutzerschnittstelle oder nur fur eine Textkonsole konfiguriert ist. Um eine minimale Ordnung zwischen den hereingezogenen Units zu erzwingen, sind eine Reihe von gut bekannten Ziel-Units verfugbar, wie in systemd.special(7) aufgefuhrt. Das nachfolgende Diagramm gibt einen strukturellen Uberblick uber 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-Einhangungen: (verschiedene Cryptsetup/Veritysetup-Gerate) mqueue, configfs, | | debugfs, ) v | | cryptsetup.target | | (verschiedene Auslagerungs- | | remote-fs-pre.target | Gerate) | | | | | | | | | v | v local-fs-pre.target | | | (Netzwerkdateisysteme) | swap.target | | v v | | | v | remote-cryptsetup.target | | | (verschiedene systemnahe (verschiedene | remote-veritysetup.target | | | Dienste: udevd, Einhange- 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) | | benotigt fur | | | 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 fur Ziele, beispielsweise, indem sie an die Befehlszeilenoption systemd.unit= des Kernels ubergeben werden (siehe systemd(1)) oder indem default.target auf sie verlinkt wird. timers.target wird asynchron von basic.target hereingezogen. Dies ermoglicht es Timer-Units, von Diensten, die erst spater beim Systemstart verfugbar werden, abzuhangen. STARTEN DES BENUTZERVERWALTERS Der Systemverwalter startet fur jeden Benutzer die Unit Benutzer@UID.service, die jeweils eine separate, unprivilegierte Instanz von systemd fur jeden Benutzer startet -- den Benutzerverwalter. Ahnlich zum Systemverwalter startet der Benutzerverwalter Units, die von default.target hereingezogen werden. Das folgende Diagramm ist ein strukturelle Uberblick uber die gutbekannten Benutzer-Units. Fur 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 fur die graphische Sitzung benotigten Units hereinzieht. Eine Reihe von Zielen (auf der rechten Seite gezeigt) werden gestartet, wenn eine bestimmte Hardware dem Benutzer zur Verfugung steht. (verschiedene (verschiedene (verschiedene Timer) Pfade) Sockets) (Sound-Gerate) | | | | v v v v timers.target paths.target sockets.target sound.target | | | \______________ _|_________________/ (Bluetooth-Gerate) \ / | V v basic.target bluetooth.target | __________/ \_______ (Smartcard-Gerate) / \ | | | v | v smartcard.target v graphical-session-pre.target (verschiedene Benutzerdienste) | (Drucker) | v | | (Dienste fur 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 Prufung 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 fuhrt Systemd das besondere Ziel initrd.target aus. Bevor irgendwelche Dateisysteme eingehangt werden, muss der Verwalter bestimmen, ob das System aus dem Ruhezustand zuruckkehren 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 eingehangt werden konnen, bevor die Prufung abgeschlossen ist. Wenn das Wurzeldateisystem verfugbar wird, ist initrd-root-device.target erreicht. Falls das Wurzelverzeichnis als /sysroot eingehangt 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 moglichen Einhangepunkt fur /usr/ und zusatzlichen Eintragen, die mit der Option x-initrd.mount markiert sind. Alle gefundenen Eintrage werden unter /sysroot eingehangt und initrd-fs.target ist erreicht. Der Dienst initrd-cleanup.service isoliert zu dem initrd-switch-root.target, in dem Aufraumdienste laufen konnen. Als allerletzten Schritt wird initrd-switch-root.service aktiviert, das dazu fuhrt, 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 Einhangungen 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 Ubergang ins Hauptbetriebssystem SYSTEMVERWALTERABSCHALTVORGANG Der Abschaltvorgang mit Systemd besteht auch aus verschiedenen Ziel-Units mit einiger minimaler Ordnungsstruktur: (Konflikt zu (Konflikt zu allen allen System- Dateisystemeinhangungen, diensten) Auslagerungen, | Cryptsetup-/ | Veritysetup- | Geraten, ) | | 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 | v kexec.target Haufig 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 uberleiten (was im Programm systemd-shutdown implementiert ist). Dieser wird in einer einfachen und robusten Weise alle verbleibenden Dateisysteme aushangen, alle verbleibenden Prozesse toten und alle verbleibenden Ressourcen freigeben, ohne das Dienste- oder Unit-Konzept noch in Betracht zu ziehen. Zu diesem Zeitpunkt sind gewohnliche Anwendungen und Ressourcen im Allgemeinen bereits beendet und freigegeben, die zweite Phase agiert daher nur als Sicherheitsnetz fur alles, das aus irgendeinem Grund nicht wahrend des oben beschriebenen, primaren, 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/ UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 BOOTUP(7)