Kapitel 3. Die Systeminitialisierung

Das Unified Extensible Firmware Interface (UEFI) definiert als Teil der UEFI-Spezifikation einen Boot-Manager. Wenn ein Rechner eingeschaltet wird, ist dieser Boot-Manager die erste Stufe im Boot-Prozess; er prüft die Boot-Konfiguration und führt den dort festgelegten Betriebssystem-Bootloader bzw. Betriebssystem-Kern aus (normalerweise einen Bootloader). Die Boot-Konfiguration ist über Variablen definiert, die im NVRAM gespeichert sind; dazu gehören Variablen, die den Dateisystempfad zum Betriebssystem-Bootloader oder -Kern enthalten.

Eine EFI System Partition (ESP) ist eine spezielle Partition auf einem Datenspeicher auf UEFI-konformen Computersystemen. Nach dem Einschalten des Rechners greift die UEFI-Firmware auf die ESP zu. Auf ihr sind UEFI-Applikationen abgelegt sowie weitere Dateien, die von diesen Applikationen benötigt werden. Zu diesen Applikationen gehören auch die Betriebssystem-Bootloader. (Auf älteren PC-Systemen können auch das BIOS und der MBR zum Einsatz kommen.)

Der Bootloader ist die zweite Stufe des Boot-Prozesses und wird durch das UEFI gestartet. Er lädt das System-Kernel-Image und das initrd-Image in den Speicher und übergibt diesen die Kontrolle. Das initrd-Image ist ein Abbild des Wurzeldateisystems und seine Funktionalitäten hängen von dem verwendeten Bootloader ab.

Das Debian-System nutzt normalerweise den Linux-Kernel als Standard-Betriebssystem-Kern. Das initrd-Image für den aktuellen Linux-Kernel der Version 5.x ist technisch gesehen ein initramfs- (initial RAM Filesystem-) Image.

Es gibt mehrere Bootloader und Konfigurationsoptionen:

	Warnung
	Spielen Sie nicht mit Bootloadern herum, ohne boot-fähige Rettungsmedien (USB-Stick, CD, Diskette) zur Hand zu haben, die von Images im grub-rescue-pc-Paket erstellt wurden. Damit können Sie Ihr System auch ohne funktionsfähigen Bootloader auf der Festplatte starten.

For UEFI system, GRUB2 first reads the ESP partition and uses UUID specified for search.fs_uuid in "/boot/efi/EFI/debian/grub.cfg" to determine the partition of the GRUB2 menu configuration file "/boot/grub/grub.cfg".

The key part of the GRUB2 menu configuration file looks like:

menuentry 'Debian GNU/Linux' ... {
        load_video
        insmod gzio
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root fe3e1db5-6454-46d6-a14c-071208ebe4b1
        echo    'Loading Linux 5.10.0-6-amd64 ...'
        linux   /boot/vmlinuz-5.10.0-6-amd64 root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 ro quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-5.10.0-6-amd64
}

Dieser Teil von /boot/grub/grub.cfg hat folgende Bedeutung:

	Tipp
	You can enable to see kernel boot log messages by removing quiet in "/boot/grub/grub.cfg". For the persistent change, please edit "GRUB_CMDLINE_LINUX_DEFAULT="quiet"" line in "/etc/default/grub".

	Tipp
	Sie können das GRUB-Hintergrundbild (Splash image) über die Variable GRUB_BACKGROUND in "/etc/default/grub" anpassen; die Variable kann auf den Pfad der Grafikdatei verweisen, oder Sie legen die Grafikdatei selbst in "/boot/grub/" ab.

Weitere Infos finden Sie unter "info grub" und grub-install(8).

Das normale Debian-System ist die vierte Stufe des Boot-Prozesses und wird von dem Mini-Debian-System gestartet. Der System-Kernel des Mini-Debian-Systems läuft in dieser Umgebung weiter. Das verwendete Wurzeldateisystem wird von dem im Arbeitsspeicher umgeschwenkt zu dem auf der echten Festplatte.

Das Programm init wird als erstes Programm mit PID=1 ausgeführt und erledigt die eigentliche Hauptarbeit beim Booten, das Starten verschiedener Programme. Der Standardpfad zum init-Programm ist "/usr/sbin/init", aber er kann über einen Kernel-Boot-Parameter wie "init=/pfad/zum/init-programm" auch geändert werden.

"/usr/sbin/init" wurde nach Debian 8 Jessie (veröffentlicht in 2015) ein symbolischer Link auf "/lib/systemd/systemd".

	Tipp
	Im Debian Wiki unter BootProcessSpeedup finden Sie aktuelle Tipps zur Beschleunigung des Boot-Prozesses.

When the Debian system starts, /usr/sbin/init symlinked to /usr/lib/systemd is started as the init system process (PID=1) owned by root (UID=0). See systemd(1).

Der systemd-Init-Prozess wird - basierend auf den Unit-Konfigurationsdateien (siehe systemd.unit(5)) - in mehrere parallele Prozesse aufgespalten; diese Konfigurationsdateien sind in deklarativem Stil geschrieben, im Unterschied zu dem prozeduralen Stil von SysV.

Die abgespalteten Prozesse werden in individuellen Linux control groups abgelegt, die nach der Unit benannt werden, zu der sie in der privaten systemd-Hierarchie gehören (siehe cgroups und Abschnitt 4.7.5, „Linux Sicherheits-Funktionalitäten“).

Units for the system mode are loaded from the "System Unit Search Path" described in systemd.unit(5). The main ones are as follows in the order of priority:

Deren Abhängigkeiten untereinander sind durch die Regeln "Wants=", "Requires=", "Before=", "After=", … (siehe "MAPPING OF UNIT PROPERTIES TO THEIR INVERSES" in systemd.unit(5)) definiert. Die Ressourcen-Steuerung ist ebenfalls festgelegt (siehe systemd.resource-control(5)).

Die Endung der Unit-Konfigurationsdateien definiert ihren Typ wie folgt:

Während des Systemstarts versucht der systemd-Prozess, das Target "/lib/systemd/system/default.target (normalerweise ein symbolischer Link auf "graphical.target") zu starten. Als erstes werden dabei einige spezielle Target-Units (siehe systemd.special(7)) wie "local-fs.target", "swap.target" und "cryptsetup.target" aktiviert, um die Dateisysteme einzubinden. Dann werden über die Abhängigkeiten weitere Target-Units aktiviert. Details finden Sie in bootup(7).

systemd enthält Funktionalitäten, um die Rückwärtskompatibilität zu SysV zu gewährleisten. Boot-Skripte im SysV-Stil in "/etc/init.d/rc[0123456S].d/[KS]name" werden immer noch abgearbeitet, und telinit(8)-Befehle werden in Aktivierungsanforderungen für systemd-Units übersetzt.

When a user logins to the Debian system via gdm3(8), sshd(8), etc., /lib/systemd/system --user is started as the user service manager process owned by the corresponding user. See systemd(1).

The systemd user service manager process spawns processes in parallel based on the declarative unit configuration files (see systemd.unit(5) and user@.service(5)).

Units for the user mode are loaded from the "User Unit Search Path" described in systemd.unit(5). The main ones are as follows in the order of priority:

• "~/.config/systemd/user/*": User configuration units

• "/etc/systemd/user/*": User units created by the administrator

• "/run/systemd/user/*": Runtime units

• "/lib/systemd/user/*": User units installed by the distribution package manager

These are managed in the same way as Abschnitt 3.2.1, „Systemd-Init“.

Die Optionen zum Einbinden normaler Festplatten- und Netzwerkdateisysteme werden in "/etc/fstab" festgelegt. See fstab(5) und Abschnitt 9.6.7, „Optimierung von Dateisystemen über mount-Optionen“.

Die Konfiguration verschlüsselter Dateisysteme ist in "/etc/crypttab" abgelegt. Siehe crypttab(5).

Software-RAID mit mdadm(8) wird in "/etc/mdadm/mdadm.conf" konfiguriert. Siehe mdadm.conf(5).

Auf modernen Debian-Desktop-Systemen mit systemd erfolgt die Initialisierung von Netzwerkschnittstellen für die Loopback-Schnittstelle lo typischerweise durch "networking.service" und für andere Schnittstellen durch "NetworkManager.service".

Details zur Konfiguration finden Sie in Kapitel 5, Netzwerkkonfiguration.

The cloud system instance may be launched as a clone of "Debian Official Cloud Images" or similar images. For such system instance, personalities such as hostname, filesystem, networking, locale, SSH keys, users and groups may be configured using functionalities provided by cloud-init and netplan.io packages with multiple data sources such as files placed in the original system image and external data provided during its launch. These packages enable the declarative system configuration using YAML data.

See more at "Cloud Computing with Debian and its descendants", "Cloud-init documentation" and Abschnitt 5.4, „The modern network configuration for cloud“.

Bei einer Standardinstallation werden viele Netzwerkdienste (siehe Kapitel 6, Netzwerkapplikationen) von systemd durch network.target als Daemon-Prozess gestartet. "sshd" ist hier keine Ausnahme. Als Beispiel dafür, wie man so etwas anpassen kann, wollen wir zeigen, wie Sie "sshd" so ändern, dass er nur auf Anfrage (on-demand) startet.

Als erstes deaktivieren Sie die entsprechende Dienst-Unit:

 $ sudo systemctl stop sshd.service
 $ sudo systemctl mask sshd.service

Der klassische Weg zur on-demand-Aktivierung von Sockets führte früher über den inetd- (oder xinetd)-Superserver. Unter systemd kann dies über das Hinzufügen von *.socket und *.service Unit-Konfigurationsdateien erreicht werden.

Eine sshd.socket anlegen zur Spezifizierung eines Sockets, der auf Anfragen überwacht wird:

[Unit]
Description=SSH Socket for Per-Connection Servers

[Socket]
ListenStream=22
Accept=yes

[Install]
WantedBy=sockets.target

Und eine sshd@.service als Dienste-Datei passend zu sshd.socket:

[Unit]
Description=SSH Per-Connection Server

[Service]
ExecStart=-/usr/sbin/sshd -i
StandardInput=socket

Dann muss der Dienst neu geladen werden:

 $ sudo systemctl daemon-reload