LUKS-Passphrase wird sporadisch nicht akzeptiert (NVMe / APST Bug)

Kurzfassung

Nach einem vollständigen Stromverlust (Akku abgesteckt, Gerät komplett spannungslos) wurde die LUKS-Passphrase beim Booten nur sporadisch akzeptiert – oft erst nach 3–10 Versuchen.
Tastatur, Passwort, Keymap und Benutzerfehler konnten ausgeschlossen werden.

Ursache:
Ein NVMe-Firmware/Power-Management-Problem (APST) in Kombination mit frühem LUKS-Unlock.

Lösung:
Abschalten der aggressiven NVMe-Tiefschlafzustände per Kernel-Parameter.

Symptome

LUKS-Passphrase korrekt, aber:

Versuch → „falsch“

mehrere Wiederholungen nötig

Problem tritt plötzlich auf, vorher jahrelang stabil

USB-Tastatur zeigt identisches Verhalten

Häufiger nach:

Akku abgesteckt

Gerät komplett stromlos

BIOS/Hardware-Arbeiten

Betroffene Hardware (Beispiel)

Notebook: Lenovo ThinkPad P15s

NVMe: Kingston SNVS2000G

Verschlüsselung: LUKS (manuelle Passphrase)

Distribution: Debian (systemd, initramfs)

Technischer Hintergrund (Kurz erklärt)

Moderne NVMe-SSDs nutzen APST (Autonomous Power State Transitions), um sehr tiefe Stromsparzustände zu erreichen (PS3/PS4).

Bei bestimmten Consumer-NVMe-SSDs (u. a. Kingston) führt das zu:

instabilem PCIe/NVMe-Timing

sporadisch falschen oder verzögerten Daten beim frühen Boot

LUKS bekommt inkonsistente Daten beim Header-Zugriff

Ergebnis:

korrektes Passwort → Hashvergleich schlägt trotzdem fehl

Nach erneutem Versuch ist das Device „wach“ → Passwort wird akzeptiert.

Das ist kein Kryptographie-Fehler.

Hinweise in den Logs

Typische Auffälligkeiten:

nvme nvme0: using unchecked data buffer
nvme nvme0: 8/0/0 default/read/poll queues (mehrfach)

Diese Meldungen sind ein starkes Indiz für NVMe-Power-State-Probleme.

Lösung (bewährt)
NVMe-Tiefschlaf deaktivieren (APST aus)

Kernel-Parameter setzen:

nvme_core.default_ps_max_latency_us=0
Umsetzung (GRUB)

Datei bearbeiten:

nano /etc/default/grub

Beispiel:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvme_core.default_ps_max_latency_us=0"

Danach:

update-grub
update-initramfs -u
reboot

Ergebnis

LUKS-Passphrase wird sofort beim ersten Versuch akzeptiert

reproduzierbar stabil

Na ja:
habe jetzt noch

#cat /etc/modprobe.d/nvme-latency.conf 
options nvme_core default_ps_max_latency_us=0

gesetzt, damit ist die Option bereits mit initramfs verfügbar

auch nach Akku-Abklemmen / Kaltstart

Was nicht die Ursache war ...

❌ falsches Passwort

❌ Tastatur / Keymap

❌ Sonderzeichen

❌ Benutzerfehler

❌ LUKS-Defekt

❌ RAM-Probleme

Hinweise / Langfristig

Kernel-Parameter dauerhaft behalten!

BIOS-Updates können das Verhalten ändern

Bei NVMe-Tausch ggf. erneut testen

Enterprise-NVMe (Samsung, WD) sind hier meist robuster

Merksatz

Wenn LUKS sich „sporadisch vertippt“, ist fast immer die NVMe schuld – nicht das Passwort.