Dateisystem-UUID in fstab stimmt nicht mehr · Linux Fix Lab

Symptome und Geltungsbereich

Der Start wartet auf eine derzeit nicht vorhandene Geräte-UUID.
Ein Daten-Mount fehlt nach Ersetzen oder neuem Anlegen eines Dateisystems.

Betroffene Umgebung

Systeme mit /etc/fstab und lokalen UUID-Mounts, einschließlich systemd-generierter Mount-Units.

Erkennbare Meldungen (synthetische Beispiele)

systemd[1]: Timed out waiting for device /dev/disk/by-uuid/11111111-2222-3333-4444-555555555555.

fstab-Kennung und Geräteerkennung prüfen; die Zeitüberschreitung beweist keine falsche UUID.

Mögliche Ursachen

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

Neues Anlegen erzeugt eine neue Dateisystem-UUID, während fstab noch die alte verwendet.
Ein getrenntes oder unerkanntes Laufwerk macht eine korrekte UUID unerreichbar; identische geklonte UUIDs können mehrdeutig sein.

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

Vorhandene Gerätekennungen und Dateisystem-UUIDs lesen; einige Felder können auf der Distribution erhöhte Leserechte benötigen.

lsblk -o NAME,PATH,MODEL,SERIAL,FSTYPE,UUID,MOUNTPOINTS

Ergebnis einordnen: Modell, Seriennummer, Partition und Dateisystem abgleichen, statt UUIDs allein anhand von /dev/sdX zu ersetzen. Bei fehlendem Gerät zuerst die Erkennung prüfen.

Prüfschritt 2

/etc/fstab lesen und prüfen, ohne sie einzubinden; für manche Quellprüfungen können erhöhte Leserechte nötig sein.

findmnt --verify --verbose

Ergebnis einordnen: Eine nicht auflösbare UUID stützt eine veraltete Referenz oder ein fehlendes Gerät. Erfolgreiche Prüfung bestätigt Syntax und Verfügbarkeit, nicht die richtigen Daten im Mount.

Nächste Schritte nach Befund

Geprüfte fstab-Quelle korrigieren

Wenn das gewünschte Dateisystem eindeutig identifiziert ist und eine andere UUID besitzt, fstab sichern und nur dessen Quellfeld ändern. Datei erneut prüfen und das einzelne Nicht-Root-Mount in einem lokalen Wartungsfenster testen.

Vorsicht: Nicht jede UUID ersetzen oder Root-/Boot-Einträge nach Analogie ändern. Sicherstellen, dass ohne das gewünschte Laufwerk keine neuen Daten in dessen Mountpoint geschrieben werden.

Wiederherstellung / Rücknahme: Bei falschem Mount die gesicherte fstab wiederherstellen. Vor Neustart nach bootrelevanten Änderungen lokalen Rettungszugang behalten.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Richtlinie für optionale Laufwerke bewusst setzen

Wenn die UUID stimmt, das Laufwerk aber bewusst entfernbar ist, nur dieses Mount mit dokumentiertem nofail- oder Automount-Verhalten optional machen. Unerkannten dauerhaft benötigten Speicher reparieren, statt sein Fehlen zu verstecken.

Vorsicht: Ein optionales Mount kann den Start fortsetzen, während Anwendungen in den leeren Mountpoint schreiben. Datenabhängige Dienste an das tatsächliche Mount binden.

Wiederherstellung / Rücknahme: Bei ungeeignetem Verhalten ursprüngliche Mount-Optionen und abhängige Dienstkonfiguration aus der dokumentierten Sicherung wiederherstellen.