Die Linux-Boot-Kette für die Fehlersuche: Firmware, Boot Loader, Kernel, initramfs und systemd

Worum es geht

bootup(7) beschreibt die Kette: Die System-Firmware führt eine minimale Hardware-Initialisierung durch und übergibt die Kontrolle an einen Boot Loader (GRUB oder systemd-boot), der auf persistentem Speicher liegt. Der Boot Loader startet einen OS-Kernel von der Platte oder aus dem Netzwerk; auf EFI-Systemen kann die Firmware den Kernel auch direkt laden. Der Kernel bindet anschliessend ein Root-Dateisystem im Arbeitsspeicher ein – das initramfs, ein komprimiertes CPIO-Archiv, das in ein tmpfs entpackt wird. Dieses findet und mountet das eigentliche Root-Dateisystem. Danach übergibt das initramfs an den System-Manager des Hosts (auf den meisten aktuellen Distributionen systemd(1)), der die übrige Hardware erkennt, die restlichen Dateisysteme einbindet und die konfigurierten Dienste bis zum Standard-Target startet.

Warum es wichtig ist

Ein Fehler zeigt sich je nach Stufe anders und erfordert eine andere Behebung: Ein Fehler in Firmware oder Boot Loader liefert überhaupt keine Kernel-Ausgabe; ein Kernel-Fehler erzeugt frühe Kernel-Meldungen, aber keinen Init-Prozess; ein initramfs-Fehler führt typischerweise in eine frühe Shell ((initramfs) unter Debian/Ubuntu, eine dracut-Emergency-Shell auf Systemen der RHEL-Familie) oder zu einem Hänger beim Warten auf das Root-Device; bei einem systemd-Fehler startet der Kernel zwar normal, aber Dienste schlagen fehl, oder das System landet in einem anderen Target als dem Standard-Target. Werden alle vier Fälle als „das System bootet nicht“ behandelt, geht Zeit mit der Neuinstallation der falschen Komponente verloren.

So wird es angewendet

• Die Konsole während des Bootens beobachten (lokal, über die serielle Schnittstelle oder über eine Hypervisor-Konsole), um die letzte Stufe zu erkennen, die noch Ausgaben erzeugt hat.
• Nach einem Boot, der systemd erreicht, das Log dieses Boots auswerten: journalctl -b für den aktuellen Boot, journalctl -b -1 für den vorherigen, falls das System selbstständig neu gestartet ist (in Skripten --no-pager ergänzen; die Ausgabe läuft standardmässig durch less). Zum Lesen des System-Journals sind root-Rechte oder die Mitgliedschaft in systemd-journal, adm oder wheel nötig.
• Mit systemd-analyze blame und systemd-analyze critical-chain messen, wo systemd Zeit verbraucht hat oder was es blockiert hat; letzteres gibt die zeitkritische Kette von Units für ein Target aus.
• In der Kernel-Kommandozeile systemd.unit= übergeben, um für einen einzelnen Boot ein alternatives Start-Target (zum Beispiel rescue.target) zu wählen, ohne eine Datei zu bearbeiten, gemäss kernel-command-line(7); die Variante mit Präfix rd. (rd.systemd.unit=) gilt nur innerhalb des initramfs.
• Wird kein Login-Prompt erreicht, zuerst die Stufe von Firmware und Boot Loader prüfen (erscheint das Boot-Menü überhaupt?), bevor Kernel oder systemd als Ursache angenommen werden.

Stolpersteine

• journalctl -b lesen, obwohl auf den fehlgeschlagenen Boot bereits ein erfolgreicher gefolgt ist; stattdessen -b -1, -b -2 usw. verwenden (journalctl --list-boots zeigt, was verfügbar ist) und beachten, dass ein nicht persistentes Journal frühere Boots vollständig verliert.
• systemd-analyze blame meldet keine Dienste vom Typ Type=simple, weil systemd sie als sofort gestartet behandelt; ein langsamer Simple-Dienst erscheint dort daher nicht.
• Ein schwarzer Bildschirm nach dem Firmware-Splash wird fälschlich als „Kernel abgestürzt“ gedeutet, obwohl möglicherweise nur eine grafische Boot-Animation die Kernel-Meldungen verdeckt; um die tatsächliche Ausgabe zu sehen, für einen Boot im GRUB-Editor quiet splash (Debian/Ubuntu) bzw. rhgb quiet (RHEL-Familie) entfernen.