Verschlüsseltes Root lässt sich beim Start nicht entsperren · Linux Fix Lab

Symptome und Geltungsbereich

Eine bekannte Passphrase wird nur beim frühen Start abgelehnt.
Die Initrd meldet fehlende Schlüsseldatei oder erzeugt erwartete verschlüsselte Zuordnung nicht.

Betroffene Umgebung

LUKS-verschlüsseltes Linux-Root mit cryptsetup/systemd-cryptsetup, eventuell Schlüsseldatei, TPM oder Hardware-Token im frühen Startpfad.

Erkennbare Meldungen (synthetische Beispiele)

systemd-cryptsetup[400]: Failed to activate with specified passphrase.

Umgebenden Fehler und Gerätekennung prüfen; Meldung allein beweist weder falsches Passwort noch Header-Schaden.

systemd-cryptsetup[400]: Failed to activate with key file '/run/keys/root.key': No such file or directory

Frühe Dateiaufnahme und Quellgeräteverfügbarkeit prüfen; Schlüsseldatei nicht veröffentlichen und verschlüsseltes Volume nicht neu erzeugen.

Mögliche Ursachen

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

Frühes Tastaturlayout, gewählter Container oder zwischengespeicherter Schlüssel können von normaler Sitzung abweichen.
Fehlender Token/Schlüsseldatei, geänderte TPM-Messung oder fehlende cryptsetup-Einbindung können das automatische Entsperren verhindern; dies beweist keinen Verlust verschlüsselter Daten.

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

/dev/nvme0n1p3 durch verifizierten verschlüsselten Container ersetzen. Dies liest Header-Metadaten und braucht normalerweise Administrator-Gerätezugriff; keine Volume-Key-Ausgabeoption ergänzen.

cryptsetup luksDump /dev/nvme0n1p3

Ergebnis einordnen: LUKS-UUID, Version, Keyslots und Tokenmetadaten prüfen. Gültiger Header prüft kein eingegebenes Geheimnis; innere Dateisystem-UUID ist andere Kennung.

Prüfschritt 2

crypttab der betroffenen Installation aus wiederhergestellter oder Rettungsumgebung lesen; Datei kann Pfade zu sensiblen Schlüsseln enthalten, nicht deren Inhalte selbst.

cat /etc/crypttab

Ergebnis einordnen: Container-UUID, Zuordnungsname, Schlüsselquelle und Initrd-Optionen mit gescheitertem Prompt vergleichen. crypttab des Live-Systems gilt nicht für installiertes System.

Nächste Schritte nach Befund

Bekanntes interaktives Wiederherstellungsgeheimnis nutzen

Scheitert automatisches Entsperren, bereits registrierte Passphrase oder Wiederherstellungsschlüssel über normalen Ersatz-Prompt der Distribution nach Layout- und Containerprüfung nutzen. Klappt es in Rettungsumgebung, aber nicht beim Start, frühe Tastenbelegung/Konfiguration korrigieren.

Vorsicht: Geheimnis nie in Protokoll oder Chat eingeben und keine Keyslots entfernen, TPM-Registrierung löschen oder luksFormat zur Lösung nutzen.

Wiederherstellung / Rücknahme: Vorherige Tastenbelegung oder Schlüsselquellen-Konfiguration wiederherstellen; bestehende registrierte Schlüssel bleiben Rettungsweg.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Benötigte Schlüsselquelle und Initrd-Einbindung wiederherstellen

Nennt Fehler fehlende Schlüsseldatei/-gerät oder Tokenpfad, Quelle gemäß dokumentierter Verschlüsselungs-Boot-Einrichtung zurückbringen und betroffene Initramfs nach Prüfung der Aufnahmeregeln erneuern. Bei TPM-Änderungen vor dokumentierter Neuregistrierung interaktiv wiederherstellen.

Vorsicht: Vor Registrierungsänderungen Header-Sicherung und verifizierten unabhängigen Entsperrweg bereithalten. Schlüsseldatei nie breit lesbar machen, um Boot-Fehler zu umgehen.

Wiederherstellung / Rücknahme: Bei fehlerhaftem neuem automatischem Pfad vorhandene Initramfs starten und zugehörige crypttab-/Schlüsselquellen-Konfiguration zurückstellen.