LUKS2 passphrase not working after automatic update - Epoch 3 - need help recovering

User Support
1

Hello,

I have a serious problem with my Qubes OS installation
and I need help recovering access to my encrypted disk.

What happened:

  • Yesterday I logged in normally, everything worked fine
  • Today the system boots into emergency mode
  • LUKS passphrase is not accepted anymore
  • I did not change anything manually

System info:

  • Device: Lenovo ThinkPad E580
  • LUKS version: 2
  • Epoch: 3 (was probably modified during automatic update)
  • UUID: 7fda813e-8a27-4deb-b14d-20d9fc7c97f0
  • Cipher: aes-xts-plain64
  • Keyslots: 0 (luks2, 512 bits)
  • Two kernels in /boot: 6.12.54 and 6.12.47

Error from cryptsetup:

  • “No usable token is available”
  • “No key available with this passphrase”
  • “Command failed with code -2 (no permission or bad passphrase)”

What I already tried:

  • Qubes OS rescue mode - passphrase not accepted
  • Debian rescue mode - passphrase not accepted
  • Different kernels via GRUB rescue shell
  • cryptsetup --disable-keyring luksOpen
  • cryptsetup --key-slot 0 luksOpen
  • luksHeaderRestore - backup not compatible

I am 100% sure about my passphrase as I used it
every day. The Epoch 3 suggests the header was
modified 3 times, possibly during an automatic update.

Is there any way to recover access or repair
the LUKS header?

Thank you very much for any help!

2

UPDATE - additional diagnostics:

  • Key material test: dumped keyslot area with dd,
    compressed with xz. Result was NOT compressible
    (265800 bytes from 256000 input) - suggests key
    material is intact, not corrupted/zeroed.

  • Verified passphrase characters visually with “cat” -
    all characters correct, ruled out keyboard layout.

  • The rescue ISO I used was Qubes 4.3 (cryptsetup 2.8.1),
    but my system was installed around 2024, likely Qubes
    4.2. I suspect a cryptsetup/kernel version mismatch.

  • Planning to retry rescue using a Qubes 4.2.4 ISO to
    match the original cryptsetup version.

Questions: Can a newer cryptsetup (2.8.1) reject a
correct passphrase for a LUKS2 container made under an
older release? Are there known argon2/cryptsetup
regressions causing “No key available” with a correct
passphrase?

3

I’d be careful with the “automatic update changed the LUKS header” assumption. A normal Qubes/dom0 package update should not rewrite LUKS keyslots; the epoch only says the LUKS2 metadata changed at some point, not why. Before trying more repair commands, I would make a fresh header backup from the current disk and keep it read-only, then test only with non-destructive commands like cryptsetup luksDump --dump-json-metadata and cryptsetup open --debug --test-passphrase. If 4.2 rescue media gives the same “No key available”, the hard answer may be that there is no repair path without a matching header backup or another valid keyslot.

4

I’m curious - did you solve it?

1 Like
5

no…