Behebung von Systemd-Boot-Problemen: Häufige Probleme und Lösungen

Linux-Boot-Probleme wirken dringend, weil oft zuerst die vertrauten Werkzeuge ausfallen. SSH kann ausgefallen sein, der grafische Login erscheint möglicherweise nie, und die Konsole könnte Sie mit einer Nachricht in den Notfallmodus werfen, die schlimmer aussieht, als sie ist. Bei Systemd-Boot-Problemen ist der beste erste Schritt nicht zu raten. Finden Sie den Punkt, an dem der Bootvorgang gestoppt hat, und arbeiten Sie dann rückwärts durch die Unit-Protokolle, Mount-Fehler, Abhängigkeitsfehler oder frühe Kernel-Meldungen.

Diese Anleitung konzentriert sich auf Fehler, die auftreten, sobald der Kernel systemd als PID 1 gestartet hat, sowie auf einige naheliegende Probleme, die von der Konsole aus wie Systemd-Fehler aussehen: schlechte Einträge in /etc/fstab, Initramfs-Probleme und Bootloader-Fehler.

Den Systemd-Boot-Prozess verstehen

Systemd verwaltet den Linux-Boot-Prozess durch ein System von "Units". Diese Units beschreiben verschiedene Systemressourcen und -dienste, wie Dienste (.service), Mountpunkte (.mount), Geräte (.device) und Ziele (.target). Ziele sind spezielle Units, die andere Units gruppieren und bestimmte Synchronisationspunkte oder Zustände während des Bootvorgangs darstellen, wie multi-user.target (der traditionelle Runlevel 3) oder graphical.target (Runlevel 5).

Der Bootvorgang umfasst typischerweise:

1. Kernel-Initialisierung: Der Kernel lädt und initialisiert die Hardware.
2. Initramfs-Phase: Ein initiales RAM-Dateisystem wird geladen, das essentielle Treiber und Werkzeuge zum Mounten des Root-Dateisystems enthält.
3. Systemd-Start: Systemd übernimmt als PID 1 und startet das default.target (das oft auf multi-user.target oder graphical.target verlinkt).
4. Unit-Aktivierung: Systemd liest Unit-Dateien, löst Abhängigkeiten auf und startet Dienste und Mounts hochgradig parallel.

Boot-Probleme können in jeder dieser Phasen auftreten, aber diese Anleitung konzentriert sich hauptsächlich auf Probleme, die sichtbar werden, sobald systemd gestartet ist.

Erste Triage: Zugriff auf Boot-Protokolle

Wenn Ihr System nicht richtig bootet, ist der erste und wichtigste Schritt der Zugriff auf die Boot-Protokolle. Diese Protokolle geben Hinweise darauf, was schiefgelaufen ist. Wenn Ihr System nicht in eine grafische Umgebung oder sogar eine Standard-TTY bootet, müssen Sie alternative Methoden verwenden.

1. Verwendung von journalctl (aus dem Rettungs-/Notfallmodus oder von Live-Medien)

journalctl ist das Dienstprogramm zum Abfragen des Systemd-Journals. Wenn Ihr System in den Rettungsmodus oder Notfallmodus booten kann, oder wenn Sie einen Live-USB/CD verwenden, um auf Ihre Festplatte zuzugreifen, ist journalctl Ihr primäres Werkzeug.

Um Protokolle des vorherigen Bootvorgangs anzuzeigen:

journalctl -b -1

Um alle Meldungen seit dem Systemstart anzuzeigen:

journalctl -b

Um Protokolle zu fehlgeschlagenen Units anzuzeigen:

journalctl -b -p err..emerg # Zeigt Fehler, kritische, Alarm-, Notfallmeldungen
journalctl -b --since "-5min" # Zeigt Protokolle der letzten 5 Minuten des aktuellen Bootvorgangs

Wenn Sie eine Live-Umgebung verwenden, benötigen Sie nicht immer ein vollständiges chroot, nur um Protokolle zu lesen. Mounten Sie das installierte System und weisen Sie journalctl darauf:

mount /dev/mapper/vg0-root /mnt
journalctl --directory=/mnt/var/log/journal -b -1

Auf Systemen ohne persistente Journale existieren ältere Boot-Protokolle möglicherweise nicht unter /var/log/journal. Überprüfen Sie in diesem Fall distributionsspezifische Protokolle unter /var/log oder reproduzieren Sie den Bootvorgang, nachdem Sie das persistente Journal aktiviert haben, wenn das System gesund genug dafür ist.

2. Verwendung von dmesg

dmesg zeigt den Kernel-Ringpuffer an, der Meldungen des Kernels während des Bootvorgangs enthält. Dies ist besonders nützlich für Probleme, die sehr früh im Bootvorgang auftreten, bevor systemd vollständig die Kontrolle übernommen hat.

dmesg

3. Überprüfen des Unit-Status

Sobald Sie sich in einer nutzbaren Shell befinden (Rettungsmodus, Notfallmodus oder Live-Umgebung mit chroot), können Sie den Status aller Systemd-Units überprüfen.

systemctl --failed

Dieser Befehl listet alle Units auf, die nicht gestartet werden konnten. Für detaillierte Informationen zu einer bestimmten fehlgeschlagenen Unit verwenden Sie:

systemctl status <unit_name>.service

Und um ihre spezifischen Journaleinträge anzuzeigen:

journalctl -u <unit_name>.service -b

Häufige Systemd-Boot-Probleme und Lösungen

1. Fehlgeschlagene Dienste und Unit-Fehler

Problem: Ein kritischer Dienst startet nicht, was das System daran hindert, das gewünschte Ziel zu erreichen (z.B. multi-user.target). Dies äußert sich oft darin, dass das System in den Notfallmodus wechselt.

Symptome: systemctl --failed zeigt eine oder mehrere Units mit dem Status "failed". journalctl -u <unit_name>.service zeigt Fehlermeldungen, die erklären, warum der Dienst nicht starten konnte.

Häufige Ursachen:

• Falsche Konfiguration: Tippfehler in einer Konfigurationsdatei, falsche Pfade, fehlende Abhängigkeiten.
• Fehlende Dateien/Abhängigkeiten: Ein Dienst versucht, auf eine Datei oder ein Verzeichnis zuzugreifen, das nicht existiert oder nicht zugänglich ist.
• Ressourcenerschöpfung: Der Dienst versucht, zu viel Speicher oder andere Ressourcen zu belegen.
• Berechtigungsprobleme: Der Dienst hat nicht die erforderlichen Berechtigungen, um Dateien zu lesen/schreiben oder Befehle auszuführen.

Lösungen:

1. Identifizieren Sie die fehlgeschlagene Unit: Verwenden Sie systemctl --failed.
2. Überprüfen Sie die Protokolle: Führen Sie journalctl -u <unit_name>.service -b für detaillierte Fehlermeldungen aus.
3. Korrigieren Sie die Konfiguration: Bearbeiten Sie die Konfigurationsdatei des Dienstes (z.B. /etc/systemd/system/<unit_name>.service oder Dateien in /etc/). Achten Sie auf die Direktiven ExecStart, WorkingDirectory, User, Group, Environment.
4. Überprüfen Sie Abhängigkeiten: Stellen Sie sicher, dass alle Wants=, Requires=, After=, Before=-Direktiven korrekt angegeben sind und dass die erforderlichen Dienste aktiviert sind.
5. Neustarten und erneut aktivieren: Führen Sie nach Änderungen systemctl daemon-reload aus, versuchen Sie dann systemctl start <unit_name>.service und systemctl enable <unit_name>.service.

Beispiel: Ein benutzerdefinierter Webdienst mywebapp.service schlägt fehl, weil seine Datenbank nicht verfügbar ist.

# Status überprüfen
systemctl status mywebapp.service

# Protokolle auf Hinweise überprüfen
journalctl -u mywebapp.service -b

# Unit-Datei bearbeiten (z.B. in /etc/systemd/system/mywebapp.service)
# After=-Direktive hinzufügen/ändern, um sicherzustellen, dass die Datenbank zuerst startet
# z.B. After=postgresql.service mysql.service

# Systemd neu laden und erneut versuchen
systemctl daemon-reload
systemctl start mywebapp.service
systemctl enable mywebapp.service # Sicherstellen, dass es beim nächsten Boot startet

2. Dateisystemprobleme

Problem: Beschädigte Dateisysteme oder falsche Einträge in /etc/fstab können das System daran hindern, kritische Partitionen zu mounten, was zum Notfallmodus führt.

Symptome: Fehlermeldungen über fsck-Fehler, mount-Fehler oder das System wechselt in den Notfallmodus mit einer Meldung wie "Give root password for maintenance (or type Control-D to continue)".

Häufige Ursachen:

• Unsauberes Dateisystem: Unsachgemäßes Herunterfahren, Stromausfall.
• Falsches /etc/fstab: Tippfehler in UUID/Gerätepfad, falscher Dateisystemtyp, fehlendes noauto für nicht-kritische Mounts.
• Hardwarefehler: Festplattenfehler.

Lösungen:

1. Zugriff auf den Notfallmodus: Geben Sie auf Aufforderung das Root-Passwort ein.
2. Überprüfen Sie /etc/fstab: Überprüfen Sie /etc/fstab sorgfältig auf Fehler. Kommentieren Sie verdächtige Zeilen vorübergehend mit # aus.
3. Führen Sie fsck vorsichtig aus: Überprüfen und reparieren Sie Dateisysteme manuell nur, wenn sie nicht gemountet sind, oder im Wartungskontext schreibgeschützt gemountet, wenn Ihre Distribution dies als sicher dokumentiert. Für eine Nicht-Root-Partition:

   umount /dev/sdb1
   fsck -f /dev/sdb1
   

   Wenn das Root-Dateisystem repariert werden muss, booten Sie von Live-Medien oder einer Rettungsumgebung und führen Sie fsck von dort aus. Vermeiden Sie fsck -y als ersten Schritt auf wichtigen Festplatten; überprüfen Sie die Eingabeaufforderungen, es sei denn, Sie haben bereits ein Backup oder verstehen den Schaden.
4. Neustart: Versuchen Sie nach Änderungen oder der Ausführung von fsck einen Neustart.

3. Abhängigkeitskonflikte und Unit-Reihenfolge

Problem: Dienste starten in der falschen Reihenfolge, oder Units haben widersprüchliche Abhängigkeiten, was zu Deadlocks oder Fehlern führt.

Symptome: Dienste laufen zeitlich aus, Dienste schlagen fehl, weil ihre Abhängigkeiten nicht bereit sind, systemd-analyze plot zeigt lange Ketten oder Zyklen.

Häufige Ursachen:

• Falsch konfigurierte Wants=, Requires=, After=, Before=-Direktiven in Unit-Dateien.
• Units erwarten Ressourcen, die noch nicht verfügbar sind.

Lösungen:

1. Boot-Reihenfolge analysieren: Verwenden Sie systemd-analyze, um den Bootvorgang zu visualisieren.

   • systemd-analyze blame: Zeigt Dienste geordnet nach ihrer Startzeit und hebt langsame Units hervor.
   • systemd-analyze critical-chain: Zeigt den kritischen Pfad von Units, die die gesamte Bootzeit direkt beeinflussen.
   • systemd-analyze plot > boot.svg: Erzeugt ein SVG-Bild des gesamten Boot-Abhängigkeitsgraphen, unverzichtbar für komplexe Probleme.

2. Unit-Abhängigkeiten überprüfen: Verwenden Sie systemctl list-dependencies <unit_name>, um zu sehen, was eine Unit benötigt und was von ihr abhängt.

3. Unit-Datei-Direktiven anpassen:

   • After=, Before=: Steuern die Reihenfolge von Units. Wenn A.service After=B.service hat, startet A nach B (wenn B überhaupt gestartet wird). Verwenden Sie After= für die meisten Reihenfolgeanforderungen.
   • Wants=: Drückt eine schwache Abhängigkeit aus. Wenn A.service Wants=B.service, wird B gestartet, wenn A startet, aber A läuft weiter, selbst wenn B fehlschlägt.
   • Requires=: Drückt eine starke Abhängigkeit aus. Wenn A.service Requires=B.service, wird B einbezogen, wenn A startet, und A schlägt fehl, wenn B nicht gestartet werden kann. Wenn B explizit gestoppt wird, wird auch A gestoppt.
   • Conflicts=: Stellt sicher, dass eine bestimmte Unit gestoppt wird, wenn die aktuelle Unit gestartet wird, und umgekehrt.
   • PartOf=: Verknüpft den Lebenszyklus einer Unit mit einer anderen (z.B. wenn ein slice gestoppt wird, werden alle Units, die PartOf davon sind, ebenfalls gestoppt).

   Tipp: Bevorzugen Sie für die meisten Abhängigkeiten After= und Wants=, um eine enge Kopplung zu vermeiden, die zu Deadlocks oder Fehlerkaskaden führen könnte.

4. Kernel Panics / Initramfs-Probleme

Problem: Das System bootet sehr früh nicht, oft bevor systemd vollständig die Kontrolle übernimmt, und zeigt Meldungen wie "Kernel panic - not syncing" oder solche, die sich auf dracut oder initramfs beziehen.

Symptome: Früher Bootfehler, oft mit einer Textwand, die Stack-Traces oder Meldungen über fehlendes Root-Gerät, /dev/root nicht gefunden usw. zeigt.

Häufige Ursachen:

• Fehlende Kernel-Module: Initramfs enthält nicht die notwendigen Treiber für das Root-Dateisystem (z.B. LVM, RAID, bestimmte Festplattencontroller).
• Beschädigter Kernel/Initramfs: Dateien sind beschädigt.
• Falsche Kernel-Parameter: Der root=-Parameter in GRUB zeigt auf das falsche Gerät.

Lösungen:

1. Initramfs neu erstellen: Dies ist eine häufige Lösung. Booten Sie in eine Live-Umgebung oder einen anderen Kernel, chroot in Ihr System und erstellen Sie das Initramfs neu.

   # Beispiel für Dracut (Fedora/RHEL/CentOS)
   dracut -f -v /boot/initramfs-$(uname -r).img $(uname -r)
   
   # Beispiel für mkinitcpio (Arch Linux)
   mkinitcpio -P
   
   # Beispiel für update-initramfs (Debian/Ubuntu)
   update-initramfs -u -k all
   

2. GRUB-Konfiguration überprüfen: Überprüfen Sie /boot/grub/grub.cfg (oder /etc/default/grub, wenn Sie es neu generieren) auf korrekten root=-Parameter und initrd-Pfad.
3. Kernel-Parameter: Wenn Sie vermuten, dass ein bestimmtes Modul fehlt oder Probleme verursacht, können Sie versuchen, Kernel-Parameter in GRUB hinzuzufügen (z.B. rd.break, um für Debugging in die Initramfs-Shell zu gelangen).

5. GRUB/Bootloader-Probleme

Problem: Das System erreicht nicht einmal den Punkt, an dem der Kernel geladen wird, oder es bleibt im GRUB-Menü hängen.

Symptome: "No boot device found", GRUB-Rettungseingabeaufforderung oder GRUB lädt den Kernel nicht.

Häufige Ursachen:

• Beschädigter Bootloader.
• Falsche GRUB-Konfiguration, die auf nicht existierenden Kernel/Initramfs verweist.
• BIOS/UEFI-Einstellungen verhindern die richtige Boot-Reihenfolge.

Lösungen:

1. GRUB neu installieren: Booten Sie von einem Live-USB, chroot in Ihr System und installieren Sie GRUB neu auf dem MBR/EFI-Partition.

   # Beispiel
   mount /dev/sdaX /mnt # Root-Partition mounten
   
   mount /dev/sdaY /mnt/boot/efi # Wenn separate EFI-Partition
   
   for i in /dev /dev/pts /proc /sys /run; do mount --bind $i /mnt$i; done
   chroot /mnt
   
   grub-install /dev/sda # Auf der Hauptfestplatte installieren
   
   grub-mkconfig -o /boot/grub/grub.cfg # GRUB-Konfiguration neu generieren
   
   exit
   umount -R /mnt
   reboot
   

2. BIOS/UEFI-Einstellungen überprüfen: Stellen Sie sicher, dass das richtige Boot-Laufwerk priorisiert ist.

Fortgeschrittene Fehlerbehebungstechniken

Booten in den Rettungs-/Notfallmodus

Diese Modi bieten eine minimale Umgebung zur Fehlerbehebung. Um sie zu betreten:

1. Während GRUB: Drücken Sie e, um die Kernel-Befehlszeile zu bearbeiten.
2. Finden Sie die linux-Zeile: Suchen Sie die Zeile, die mit linux (oder linuxefi) beginnt.
3. Fügen Sie systemd.unit=rescue.target für den Rettungsmodus hinzu (die meisten Dienste sind aus, Single-User-Shell).
4. Fügen Sie systemd.unit=emergency.target für den Notfallmodus hinzu (minimale Dienste, oft schreibgeschütztes Root).
5. Drücken Sie Ctrl+X oder F10, um zu booten.

Verwenden von rd.break für Initramfs-Debugging

Das Anhängen von rd.break an die Kernel-Befehlszeile in GRUB bringt Sie in eine Shell innerhalb des Initramfs, bevor das eigentliche Root-Dateisystem gemountet wird. Dies ist äußerst nützlich für das Debuggen von initramfs-Problemen, wie fehlende Treiber oder Probleme mit der LVM/RAID-Einrichtung.

Sobald Sie in der initramfs-Shell sind, können Sie:

• lsblk, mount überprüfen.
• Nach fehlenden Dateien in /sysroot suchen.
• Versuchen, das Root-Dateisystem manuell zu mounten.

Boot-Leistung analysieren

Obwohl es sich nicht unbedingt um einen "Fehler" handelt, können langsame Bootzeiten auf zugrunde liegende Probleme oder ineffiziente Dienstkonfigurationen hinweisen.

• systemd-analyze blame: Identifizieren Sie Dienste, die am längsten zum Starten benötigen.
• systemd-analyze critical-chain: Verstehen Sie den kritischen Pfad von Abhängigkeiten, die die gesamte Bootzeit beeinflussen.

Eine sichere Wiederherstellungssequenz

Wenn Sie an der Konsole sitzen und die Maschine halb gebootet ist, halten Sie die Wiederherstellungssequenz langweilig:

1. Erfassen Sie den genauen Fehler auf dem Bildschirm, wenn möglich.
2. Führen Sie systemctl --failed aus.
3. Lesen Sie journalctl -b -p err..alert --no-pager.
4. Wenn eine Unit fehlgeschlagen ist, lesen Sie journalctl -u unit-name -b.
5. Wenn ein Mount fehlgeschlagen ist, überprüfen Sie /etc/fstab, verifizieren Sie die UUIDs mit blkid und kommentieren Sie nur den verdächtigen nicht-kritischen Mount aus.
6. Wenn das Root-Dateisystem oder Initramfs betroffen ist, wechseln Sie zu Live-Medien oder in den Rettungsmodus, bevor Sie invasive Reparaturen durchführen.
7. Führen Sie nach Bearbeitungen von Unit-Dateien systemctl daemon-reload aus und starten Sie nur die betroffene Unit neu, wenn möglich.

Die meisten Systemd-Boot-Probleme werden nicht behoben, indem man viele Dinge auf einmal ändert. Eine schlechte Mount-Zeile, eine fehlende Festplatte, ein Dienst mit einem defekten ExecStart= oder ein Reihenfolgefehler hinterlassen eine ziemlich direkte Spur. Folgen Sie dieser Spur, führen Sie eine kleine Reparatur durch und starten Sie nur neu, wenn die aktuelle Shell die Reparatur nicht testen kann.

Verwenden Sie diese Werkzeuge, um Engpässe zu identifizieren und den Unit-Start zu optimieren, indem Sie die Direktiven After=, Requires=, TimeoutStartSec= oder Type= anpassen.

Prävention und bewährte Methoden

• Änderungen testen: Bevor Sie Änderungen an Unit-Dateien in der Produktion bereitstellen, testen Sie sie in einer Staging-Umgebung.
• Konfiguration sichern: Sichern Sie regelmäßig /etc/ oder zumindest kritische Dateien in /etc/systemd/system/.
• Unit-Direktiven verstehen: Ein solides Verständnis der Manpages systemd.service(5) und systemd.unit(5) ist unverzichtbar.
• Drop-in-Dateien verwenden: Anstatt /lib/systemd/system/-Unit-Dateien direkt zu ändern (die durch Updates überschrieben werden können), verwenden Sie Drop-in-Dateien (/etc/systemd/system/<unit_name>.service.d/*.conf) für benutzerdefinierte Konfigurationen.
• Kernel behalten: Behalten Sie immer mindestens einen bekannten, funktionierenden älteren Kernel auf Ihrem System, um in diesen zu booten, falls ein neuer Kernel Probleme verursacht.

Fazit

Die Behebung von Systemd-Boot-Problemen erfordert einen systematischen Ansatz, der mit einer effektiven Protokollanalyse beginnt. Durch das Verständnis der unit-basierten Architektur von systemd und den Einsatz von Werkzeugen wie journalctl, systemctl und systemd-analyze können Sie die Ursache von Bootfehlern effizient lokalisieren, sei es ein falsch konfigurierter Dienst, ein Dateisystemproblem oder ein komplexer Abhängigkeitskonflikt. Die Fähigkeit, in den Rettungs- oder Notfallmodus zu booten, zusammen mit fortgeschrittenen Debugging-Techniken, befähigt Sie, die Kontrolle über Ihr System zurückzugewinnen, selbst wenn es völlig unresponsive erscheint. Mit diesen Strategien und bewährten Methoden sind Sie gut gerüstet, um die meisten Systemd-Boot-Herausforderungen zu bewältigen und einen stabilen, zuverlässigen Linux-Betrieb aufrechtzuerhalten.