Boot, GRUB und systemd-boot

Benötigter fstab-Mount führt in den Notfallmodus

Ein fehlender Nicht-Root-Mount kann systemds Dateisystemziel blockieren; genaue fstab-Abhängigkeit vor einer optionalen Einbindung ohne Startpflicht prüfen.

Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

Symptome und Geltungsbereich

  • Nach Warten auf ein Dateisystem endet der Start in einer Notfall-Shell.
  • Mount- oder local-fs.target-Abhängigkeit scheitert nach entferntem oder umbenanntem Datenträger.

Betroffene Umgebung

systemd-Systeme mit /etc/fstab. Dieser Eintrag betrifft einen Nicht-Root-Mount; fehlender Root-Speicher braucht frühe Boot-Diagnose.

Erkennbare Meldungen (synthetische Beispiele)
systemd[1]: Dependency failed for local-fs.target - Local File Systems.

Vorherigen Mount-/Geräte-/fsck-Fehler finden; diese Gesamtmeldung rechtfertigt keine Abschaltung aller Mount-Prüfungen.

Mögliche Ursachen

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

  • fstab-UUID, Pfad, Typ oder Mount-Option können nicht mehr zum vorgesehenen Gerät passen.
  • Eine als notwendig behandelte Einbindung kann tatsächlich optional sein; gescheiterte Dateisystemprüfung oder Gerätefehler können ebenfalls blockieren und dürfen nicht versteckt werden.

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

/etc/fstab ohne Einhängen prüfen. Aus betroffener Installation statt ungeprüft gegen fstab eines Live-Abbilds ausführen.

findmnt --verify --verbose

Ergebnis einordnen: Fehlende Quelle oder ungültige Option grenzt Konfigurationsfehler ein. Saubere Syntax beweist keinen gesunden Datenträger und kein gesundes Dateisystem.

Prüfschritt 2

Gescheiterte Mount-Units der aktuellen systemd-Instanz ohne Wiederholungsversuch auflisten.

systemctl --failed --type=mount --no-pager

Ergebnis einordnen: Zur fstab-Einbindung passende Unit und danach deren Journal prüfen. Leere Liste in Initramfs oder nach Neustart muss den gescheiterten Host-Start nicht beschreiben.

Nächste Schritte nach Befund

Ermittelte Mount-Definition korrigieren

Ist Gerätekennung oder Option falsch, fstab sichern und nur betroffene Zeile mit verifizierter Dateisystemkennung und unterstützten Optionen korrigieren. Vor nächstem normalen Start findmnt-Prüfung erneut ausführen.

Vorsicht: Root-, Verschlüsselungs- oder Rettungseinträge nicht auf Verdacht ändern. Bei E/A-Fehlern des Datenträgers diese vor erzwungenem Mount untersuchen.

Wiederherstellung / Rücknahme: Bei schlechterem normalem Start gesicherte fstab aus Notfall- oder Rettungsumgebung wiederherstellen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Tatsächlich optionalen Mount ohne Startpflicht einrichten

Ist der Datenträger bewusst entfernbar und hängt kein notwendiger Dienst davon ab, dokumentierte nofail-Richtlinie und passendes Gerätezeitlimit für diesen Eintrag setzen. Abhängige Arbeitslasten dürfen nicht in leeren Mountpunkt schreiben.

Vorsicht: nofail nicht zum Verbergen von Fehlern bei /, /usr oder notwendigen Anwendungsdaten nutzen. Das System kann ohne verfügbare optionale Daten starten.

Wiederherstellung / Rücknahme: Vorherige Mount-Optionen und Abhängigkeitsrichtlinie wiederherstellen, falls Volume wieder notwendig sein soll.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Quellen und Prüfung

Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.