Root-Dateisystemprüfung verhindert normalen Start · Linux Fix Lab

Symptome und Geltungsbereich

Der Start stoppt zur Wartung, nachdem Prüftool unkorrigierte Fehler meldet.
Root bleibt nicht verfügbar oder nur lesbar, während normale Dienste nicht starten.

Betroffene Umgebung

Distributionen mit Startprüfung eines beschreibbaren Root-Dateisystems über systemd-fsck oder Initramfs-Helfer. Tools und Richtlinien unterscheiden sich je Dateisystem.

Erkennbare Meldungen (synthetische Beispiele)

systemd-fsck[250]: /dev/mapper/root: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

Typ und Mount-Zustand vor dateisystemspezifischer Offline-Wiederherstellung bestimmen; dies rechtfertigt keine Prüfungsumgehung.

systemd-fsck[250]: fsck failed with exit status 4.

Vorherige Prüftooldetails und physische E/A-Daten lesen; Exit-Status 8 ist Bedien-/Betriebsfehler und wird aus dieser speziellen Deutung ausgeschlossen.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

Metadaten-Inkonsistenz nach unterbrochenem Schreiben kann Reparatur außerhalb automatischer Richtlinie brauchen.
Falsches Gerät/Typ, fehlendes Prüftool oder physische E/A-Fehler können Prüfung ebenfalls scheitern lassen; Reparatur muss echte Root-Schicht statt Verschlüsselungscontainer treffen.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Prüftool-Gerät, Meldungen und Exit-Status betroffenen Starts lesen; Administrator-Journalzugriff kann nötig sein.

journalctl -b --no-pager --grep='systemd-fsck|UNEXPECTED INCONSISTENCY|fsck failed'

Ergebnis einordnen: Statusbits unterscheiden korrigierte Fehler, nötigen Neustart und unkorrigierte Fehler. Fehlendes Prüftool braucht Paketwiederherstellung statt sofortigem Dateisystem-Umschreiben.

Prüfschritt 2

Quelle, Typ und Optionen des Root-Mounts lesen. In Rettungsumgebung beschreibt dies deren Root, sofern installiertes Root nicht separat ermittelt wurde.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Ergebnis einordnen: Vor Reparatur Device-Mapper- oder Subvolume-Schichten auflösen. Bereits beschreibbar eingehängtes installiertes Root darf nicht mit Offline-Reparaturtool geprüft werden.

Nächste Schritte nach Befund

Dateisystemspezifische Offline-Wiederherstellung nutzen

Sind unkorrigierte Dateisystemfehler bestätigt, zuerst wiederherstellbare Daten oder Abbild sichern und unterstütztes Rettungsmedium mit ausgehängtem Ziel nutzen. Dokumentiertes Prüf-/Reparaturverfahren dieses Dateisystems für ermitteltes Root-Volume befolgen.

Vorsicht: Kein pauschales fsck -y gegen Verschlüsselungscontainer und kein Reparaturtool anderen Dateisystems verwenden. Grundlegenden E/A-Ausfall vor wiederholtem Metadaten-Umschreiben behandeln.

Wiederherstellung / Rücknahme: Dateisystemreparatur kann Daten unwiderruflich ändern; bei Bedarf aus vorherigem Abbild/Sicherung wiederherstellen statt Rückgängig-Befehl versprechen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Fehlendes Prüftool oder falsche Mount-Richtlinie reparieren

Liegt Fehler an fehlendem Dateisystemtool oder falschem fstab-Typ/Optionen, passendes Distributionstool zurückbringen und verifizierte Root-Definition korrigieren. Frühe Abbilder nur erneuern, wenn deren Prüfpfad davon abhängt.

Vorsicht: fsck.mode=skip oder entfernte Prüfnummern nicht zum Verbergen echter unkorrigierter Fehler nutzen. Ursprüngliche Definition vor Änderung sichern.

Wiederherstellung / Rücknahme: Bei schlechterem Start gesicherte fstab-/Initramfs-Konfiguration zurückstellen und vorheriges unterstütztes Abbild nutzen.