So beheben Sie einen /etc/fstab-Bootfehler mit journalctl

Niveau: Anfänger / Fortgeschritten
Geschätzte Dauer: ca. 15 Minuten
Ziel: Systemprotokolle mit journalctl analysieren, um einen Fehler in /etc/fstab zu finden und zu beheben, der den Systemstart verhindert.

Einführung

Ein einfacher Syntaxfehler in /etc/fstab kann verhindern, dass ein Server startet, und Sie landen in einer Notfall-Shell (Emergency Mode). Für die Wiederherstellung müssen Sie die Systemprotokolle analysieren, um die genaue Fehlerstelle zu ermitteln. In diesem Tutorial verwenden wir journalctl, um das systemd-Journal abzufragen und die Systemprotokolle anzuzeigen, die Linux beim Start erzeugt. Das Verständnis der systemd-Logs ist eine zentrale Fähigkeit der Linux-Log-Verwaltung und sorgt für eine schnelle Wiederherstellung und hohe Verfügbarkeit Ihrer Dienste. Grundkenntnisse der journalctl-Befehle sind erforderlich, um den Mountpunkt zu finden, der den Fehler verursacht hat.

Linux-Log-Verwaltung und der Logging-Stack

Bevor Sie mit der Wiederherstellung beginnen, sollten Sie die beteiligten Komponenten verstehen. Systemd (das Init-System und der Service-Manager für Linux) nutzt Systemd-journald (den Systemdienst, der Logdaten sammelt und speichert). Dieser Dienst sammelt jedes Log (eine Aufzeichnung von Ereignissen im System) im Journal (den binären Logdaten, die von Systemd-journald gespeichert werden). Dazu gehören Systemprotokolle (Aufzeichnungen systemweiter Ereignisse und Zustandsänderungen), Boot-Logs (Aufzeichnungen des Systemstartvorgangs) und Kernel-Logs (Meldungen, die vom Kernel des Betriebssystems erzeugt werden).

Je nach Konfiguration handelt es sich um flüchtige Logs (im Arbeitsspeicher gehaltene Logs, die beim Neustart verloren gehen) oder persistente Logs (Logs, die Neustarts überdauern und in der Regel auf der Festplatte gespeichert werden). Das Journal wächst kontinuierlich, weshalb die Log-Rotation (das Archivieren und Verwalten alter Logdateien, um Speicherplatz zu sparen) automatisch von systemd übernommen wird.

Voraussetzungen

Stellen Sie vor dem Start sicher, dass die folgenden Bedingungen erfüllt sind:

• Betriebssystem: Getestet unter Ubuntu 22.04/24.04 LTS, Debian 12/13, AlmaLinux/Rocky 9/10
• Zugriff: Direkter Konsolenzugriff (IPMI, VNC oder physische Konsole), um die Notfall-Shell zu erreichen
• Erforderliche Kenntnisse: Sicherer Umgang mit der Linux-Kommandozeile und grundlegende Textbearbeitung

Schritt 1: Den Boot-Fehler erkennen

Ein Syntaxfehler, ein Tippfehler oder ein fehlendes Gerät in /etc/fstab löst den Notfallmodus aus, unterbricht den Bootvorgang und zeigt eine Meldung wie diese an:

Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

Geben Sie Ihr root-Passwort ein, um die Eingabeaufforderung zu erreichen. In diesem Stadium sind möglicherweise einige Dateisysteme nicht eingehängt oder nur schreibgeschützt eingehängt.

Schritt 2: Mit journalctl die von Linux erzeugten Systemprotokolle anzeigen und analysieren

Um die Ursache des Fehlers zu finden, müssen wir die Logs des aktuellen Bootvorgangs prüfen.

Führen Sie den folgenden Befehl aus:

sudo journalctl -xb

Hier verwenden wir Journalctl (ein Kommandozeilenprogramm zum Abfragen des systemd-Journals). Dies ist einer der wichtigsten journalctl-Befehle. Er weist das Programm an, die Logs des aktuellen Bootvorgangs (-b) anzuzeigen und zusätzliche Erläuterungen (-x) einzubinden.

Die Ausgabe kann sehr umfangreich sein. Wir müssen eine Logfilterung (das Eingrenzen der Logausgabe anhand bestimmter Kriterien) durchführen, um den Fehler zu finden.

Um im Pager (der less verwendet) zu suchen, geben Sie /fstab oder /mount ein und drücken Sie die Eingabetaste.

Auszug der erwarteten Ausgabe:

-- Subject: A start job for unit mnt-data.mount has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit mnt-data.mount has finished with a failure.
--
-- The job identifier is 123 and the job result is failed.

Dies zeigt, dass eine Unit (eine Konfigurationsdatei, die beschreibt, wie eine Ressource in systemd verwaltet wird), die für das Einhängen von /mnt/data zuständig ist, fehlgeschlagen ist. Konkret konnte die Mount-Service-Unit (eine Unit-Konfigurationsdatei, die Informationen über einen von systemd verwalteten Prozess enthält) nicht gestartet werden.

Schritt 3: systemd-Logs filtern, um bestimmte Fehler zu finden

Wenn das Durchblättern des gesamten Boot-Logs zu langsam ist, können wir die Logs mit journalctl analysieren und dabei gezielte Filter einsetzen.

Führen Sie den folgenden Befehl aus, um nur Fehler mit hoher Priorität anzuzeigen:

sudo journalctl -p err -b

Erwartete Ausgabe:

May 23 10:00:01 server systemd[1]: Failed to mount mnt-data.mount - /mnt/data.
May 23 10:00:01 server systemd[1]: Dependency failed for Local File Systems.

Durch die journalctl-Filterung von Logs nach Priorität (-p err) blenden wir reine Informationsmeldungen aus.

Wenn wir die genaue fehlgeschlagene Unit kennen, können wir auch direkt die Dienstprotokolle prüfen. Führen Sie aus:

sudo journalctl -u mnt-data.mount

Wenn Sie Logs mit journalctl auf Unit-Ebene analysieren, isolieren Sie das genaue Konfigurationsproblem. Eine weitere Methode der journalctl-Filterung ist die Angabe eines Zeitraums, bei Boot-Problemen ist die Filterung nach Unit jedoch der effizienteste Ansatz.

Schritt 4: Den Fehler in /etc/fstab beheben

Nachdem das systemd-Journal bestätigt hat, dass der Mountpunkt /mnt/data das Problem ist, müssen wir die Konfigurationsdatei korrigieren.

Versuchen Sie zunächst, die Datei zu bearbeiten. Tritt beim Speichern der Fehler Read-only file system auf, müssen Sie das Root-Dateisystem mit Lese- und Schreibzugriff neu einhängen, da der Notfallmodus es häufig schreibgeschützt einhängt:

sudo mount -o remount,rw /

Erstellen Sie als Nächstes vor jeder Änderung eine Sicherungskopie der Konfigurationsdatei:

sudo cp /etc/fstab /etc/fstab.bak

Öffnen Sie dann die Datei (auf RPM-basierten Systemen wie AlmaLinux, Rocky oder RHEL ist nano möglicherweise nicht standardmäßig installiert; installieren Sie es zuerst mit sudo dnf install -y nano):

sudo nano /etc/fstab

Suchen Sie die Zeile, die /mnt/data referenziert (die richtige UUID finden Sie mit blkid):

UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data ext4 defualts 0 2

Beachten Sie den Tippfehler: defualts statt defaults. Korrigieren Sie den Tippfehler:

UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data ext4 defaults 0 2

Speichern Sie die Datei und beenden Sie den Editor. Laden Sie anschließend die Konfiguration des systemd-Managers neu, damit systemd die Änderungen an /etc/fstab kennt:

sudo systemctl daemon-reload

Überprüfung

Prüfen Sie vor dem Neustart mit findmnt die Syntax Ihrer /etc/fstab:

findmnt --verify

Werden keine Fehler gemeldet, prüfen Sie als Nächstes, ob der Mountpunkt funktioniert:

Führen Sie aus:

sudo mount -a

Gibt der Befehl nichts aus, ist die Syntax korrekt und das Einhängen war erfolgreich. Besteht weiterhin ein Fehler, gibt der Befehl eine Fehlermeldung aus. Unter Debian 13 und AlmaLinux 10 nennt die Meldung möglicherweise den genauen Grund (z. B. Unknown parameter 'defualts'), unter Ubuntu 24.04 ist die Ausgabe dagegen oft allgemein gehalten (wrong fs type, bad option). Führen Sie unter Ubuntu sudo dmesg | tail aus, um Details zu erhalten.

Verlassen Sie nach erfolgreicher Prüfung die Notfall-Shell, um den Bootvorgang fortzusetzen, oder starten Sie das System neu:

sudo systemctl reboot

Nach dem Neustart können Sie mit journalctl-Befehlen erneut die Dienstprotokolle prüfen, um sicherzustellen, dass das Einhängen beim normalen Bootvorgang fehlerfrei funktioniert hat:

sudo journalctl -u mnt-data.mount -b

Fehlerbehebung

• Notfall-Shell nicht erreichbar: Ist das root-Konto gesperrt und Sie können die Notfall-Shell nicht erreichen, müssen Sie den Server mit einem Live-USB-Medium oder einer Wiederherstellungsumgebung starten, die Root-Partition einhängen und /etc/fstab direkt von dort aus bearbeiten.
• UUID hat sich geändert: Wenn Sie eine Partition formatiert oder einen Datenträger ersetzt haben, ändert sich die UUID. Ermitteln Sie die neue UUID mit sudo blkid und aktualisieren Sie /etc/fstab entsprechend.
• Boot-Fehler bei nicht essenziellen Datenträgern vermeiden: Fügen Sie bei Nicht-Root- und Nicht-System-Volumes (wie Backup- oder Datenlaufwerken) die Mount-Option nofail zum Eintrag in /etc/fstab hinzu (z. B. ext4 defaults,nofail 0 2). Damit setzt systemd den Bootvorgang fort, auch wenn das Gerät nicht eingehängt werden kann.

Rollback

Wenn der Server erfolgreich gebootet hat, die geänderte Zeile für /mnt/data aber unerwartetes Anwendungsverhalten verursacht, können Sie das Einhängen rückgängig machen, indem Sie die Zeile in /etc/fstab auskommentieren:

sudo sed -i 's|^UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data|#UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data|' /etc/fstab

Hängen Sie anschließend das Volume aus, um den vorherigen Zustand wiederherzustellen:

sudo umount /mnt/data

Fazit

Eine effektive Linux-Log-Verwaltung beruht wesentlich darauf, sich in den systemd-Logs sicher zu bewegen. Mit journalctl können Sie die von Linux erzeugten Systemprotokolle anzeigen, um die Systemprotokolle effizient zu analysieren und kritische Boot-Fehler wie Fehlkonfigurationen in /etc/fstab zu beheben. Wer diese Werkzeuge beherrscht, kann die Verfügbarkeit sichern und auch komplexe Probleme in der gesamten Infrastruktur diagnostizieren.

Dokumentversion: 1.0
Zuletzt aktualisiert: Mai 2026
Verantwortlich: Team für technische Dokumentation