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:

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
}

Auf einem Debian-System wird "/boot/grub/grub.cfg" von dem installierten GRUB-Paket (z.B. grub-efi-amd64) verwaltet und die direkte Modifizierung durch den Benutzer ist veraltet. Stattdessen sollten Sie die Konfigurationsdateien in "/etc/grub.d/" und "/etc/default/grub" anpassen. Danach konfigurieren Sie GRUBs Konfig-Dateien und aktualisieren die NVRAM-Variablen, um automatisch das Debian-System zu booten, indem Sie folgendes ausführen:

# dpkg-reconfigure grub-efi-amd64

	Tipp
	Sie können die Anzeige von Kernel-Boot-Meldungen aktivieren, indem Sie das quiet aus der "GRUB_CMDLINE_LINUX_DEFAULT"-Zeile in "/etc/default/grub" entfernen.

	Tipp
	Ein GRUB-Splash-Hintergrundbild fügen Sie hinzu, indem Sie die Grafikdatei in "/boot/grub/" ablegen.

Lesen Sie auch "info grub", grub-install(8) und grub-mkconfig(8).

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
	Mittels "ps --pid 1 -f" können Sie überprüfen, welcher init-Befehl letztlich auf Ihrem System verwendet wird.

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

Solch ein "GRUB UEFI-Rettungssystem auf USB" können Sie erstellen, indem Sie das Super Grub2 Disk ISO-Image auf USB-Flash-Speicher schreiben.

In dem Fall, dass die Bootloader-Konfiguration z.B. durch die Installation eines anderen Betriebssystems beschädigt wurde, können Sie dies beheben durch:

	Anmerkung
	Sie können gemäß "info grub-mkrescue" auch ein boot-fähiges GRUB-Rettungs-Image erstellen. Es stellt eine textbasierte GRUB-Shell bereit, aber es kann nicht automatisch boot-fähige, installierte Betriebssysteme detektieren.

Solch ein "Linux Live-Rettungssystem auf USB" wird erzeugt, indem ein Linux-Live ISO-Image auf einen USB-Flash-Speicher geschrieben wird. Hier einige Beispiele solcher Linux-Live-Images:

Einige Anwendungsfälle für solch ein Linux Live-Rettungssystem:

	Warnung
	Die grafische Oberfläche Ihres Linux Live-Systems könnte gesperrt werden, wenn das System zu lange inaktiv war.

Tipp

Es ist eine gute Idee, ein Passwort zu vergeben, sobald Sie das Linux Live-System gestartet haben. Sie können z.B. ein Passwort vergeben über "sudo passwd user" vom Benutzer-Shell-Prompt auf einer der virtuellen Konsolen (siehe dazu Abschnitt 1.1.6, „Virtuelle Konsolen“). Einige Linux Live-Systeme setzen ein Passwort für den Standardbenutzer ("Benutzer/Passwort"): "Debian Live" = "user/live", "Kali Linux Live" = "kali/kali".

Sobald Sie jetzt den Rechner einschalten, zeigt das GRUB-Menü mögliche Kandidaten für Linux Live-Rettungssysteme an.

Wenn das Debian-System startet, wird /usr/sbin/init (ein symbolischer Link auf /usr/lib/systemd) gestartet als Init-System-Prozess mit der PID=1, Eigentümer ist root (UID=0). Lesen Sie dazu 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 für den System-Modus werden aus dem in systemd.unit(5) beschriebenen "System Unit Search Path" geladen. Die wichtigsten sind hier in der Reihenfolge ihrer Priorität aufgelistet:

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.

	Achtung
	Die emulierten Runlevel 2 bis 4 verweisen über symbolische Links alle auf des gleiche "multi-user.target".

Wenn sich ein Benutzer über gdm3(8), sshd(8) usw. am Debian-System anmeldet, wird /lib/systemd/system --user als User-Service-Manager-Prozess gestartet, Eigentümer ist der entsprechende Benutzer. Lesen Sie dazu systemd(1).

Der systemd User-Service-Manager-Prozess wird basierend auf den deklarativen Unit-Konfigurationsdateien (siehe systemd.unit(5) und user@.service(5)) in mehrere parallele Prozesse aufgespalten.

Units für den Benutzer-Modus werden aus dem in systemd.unit(5) beschriebenen "User Unit Search Path" geladen. Die wichtigsten sind hier in der Reihenfolge ihrer Priorität aufgelistet:

Diese werden auf die gleiche Art verwaltet wie Abschnitt 3.3.1, „Systemd-Init“.

Um den derzeitigen Rechnernamen auszugeben, führen Sie hostname(1) ohne ein Argument aus.

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).

	Warnung
	Bei jedem Systemstart werden nach dem Einbinden aller Dateisysteme temporäre Dateien in "/tmp", "/var/lock" und "/var/run" gelöscht.

Details zur Konfiguration finden Sie in Kapitel 5, Netzwerkkonfiguration.

Die Cloud-System-Instanz kann als Klon der "Debian Official Cloud Images" oder ähnlicher Images ausgeführt werden. Für solche Systeminstanzen können persönliche Anpassungen wie Rechnername, Dateisystem, Netzwerk, Locale, SSH-Schlüssel, Benutzer und Gruppen über Funktionalitäten aus den Paketen cloud-init und netplan.io konfiguriert werden. Dabei werden mehrere Datenquellen genutzt, wie Dateien, die im Original-System-Image liegen, und externe Daten, die beim Start der Instanz bereitgestellt werden. Diese Pakete verwenden eine deklarative Systemkonfiguration mittels YAML-Daten.

Näheres finden Sie unter "Cloud Computing with Debian and its descendants", "Cloud-init-Dokumentation" und Abschnitt 5.4, „Moderne Netzwerkkonfiguration für Cloud-Systeme“.

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