(HELP) LUKS Encryption Corrupted, Locked Out Of My Computer

Hello qubes forum,

Yesterday I was messing around with my device which is running qubes 4.2

I inserted a flash drive into one of the USB ports and set the computer to hibernate mode.

I left the computer for a few hours and came back, hit the power button and everything came back as normal out of hibernation.

I left to use the bathroom and after I came back I was presented with the lock screen. I put in my correct password and the password failed to unlock the user account.

I tried several variations of the password, questioning my sanity a bit. Only to find out I was locked out.

I booted down the computer and ended up going to sleep.

I woke up today, turned the computer on, put in my password to decrypt the full disk encryption (the gray qubes os screen) and now no password works.

After some reading I have a hunch that the LUKS encryption container is corrupted, most likely from using hibernate with an active USB stick.

Computer boots up and turns off fine, it’s just rejecting my password to decrypt the volume.

I need help as to how I can get back into my computer and access my data.

I do not have any backups of the encrypted partitions.

Thank you for the help!

could you try to type on Escape on the keyboard before the password prompt and see if there are weird messages?

In addition, if you are not using a qwerty layout, maybe the password prompt switched to qwerty for some reasons, try to type your password using this layout :confused:

1 Like

I hit esc as well as f8, I can see that the password I am using is correct.

Could you share the exact error message or text displayed when you enter your password?

Here is what I am seeing after putting in my correct password three times in a row in the full disk encryption screen.

As you can see, its treating my password as if it is incorrect.



I can’t help with your problem, but let’s all use this as a reminder to backup our headers.

In dom0 type sudo cryptsetup luksHeaderBackup /dev/yourdevice --header-backup-file qubes-os-header.luks and save it securely on a separate device.


You can try to boot from some Live USB Linux OS and decrypt your LUKS partition there.
Maybe it’s not the header that is corrupted but initramfs or something else.
You can also dump the LUKS header and check its content.
I don’t know if it’s possible to somehow recover the corrupted LUKS header from your disk.


Hello everyone,

Here is an update to my situation so-far.

I have backed up the entire damaged LUKS partition to a 2TB backup disk using ubuntu live bootable USB and stored a copy of the damaged encrypted LUKS volume off on another storage device for now while I tinker with the active instance.

I have installed Qubes 4.2 on second live bootable flashdrive and I have been using the Qubes recovery mode function to directly manipulate and poke at the encrypted volume.

I have been reading up on how LUKS encryption works.

When I use the command sequence of:


This allows me to see that I have a volume, in this case titled nvme0n1p3. That has a total size of 475.4 GB. This is the encrypted partition.

After identifying the encrypted volume I run:

cryptsetup luksDump /dev/nvme0n1p3

This command dumps a header, header appears to be in-tact. I am not exactly sure what I am looking for here?

I see that there only one key file attached to this drive, in this case it is keyslot 0.

When I attempt to add a new keyslot or open the drive my password does nothing and I am instead greeted with

No key available with this passphrase.

I am pretty stumped at this point as it appears no matter what I need that password to work in order to change settings and open the drive, but the drive in it’s damaged state fails to open with the password.

Please check the update and let me know what you think.

I am able to dump the LUKS header and read it, it’s just that as of right now for some reason my password fails to decrypt the volume.

When running:

cryptsetup luksOpen /dev/nvme0n1p3 qubes --debug

I am presented with promising output, but when I put in my password the password is rejected.

Please look over this sequence and let me know what you think.

this looks fine to me

this user on arch linux forums reported a similar issue, the unlock stopped working after updating the system firmware. It also contain a link to someone with a similar issue due to a bad RAM.


1 Like

Looked over your problem, and depending on what has actually gone wrong, it may be recoverable. If you have the actual password for it, then it would be recoverable unless there is mass corruption on the drive. If there is only a little corruption, then it may be recoverable.

It is an expensive operation depending on the severity though.

So be aware that recovery may be required, but it could be doable.

You can try to decrypt your LUKS partition on another PC to make sure that it’s not a problem with your current PC.

Hello researchers,

This is the final update and conclusion to my situation for those who may encounter something like this in the future.

After trying many different things, I decided to leave the computer alone for a few days. I comeback, boot up the machine (Last ditch effort before I do a fresh install of qubes 4.2 and overwrite the disk erasing the data).

After boot I am greeted with the gray global disk encryption screen out of desperation I put in my password once, says it’s wrong. I put in my password one more time and the disk accepts it, the white bar loads and the disk in unlocked!

I login to my user account, copy out everything of value.

I leave for the bathroom again and I comeback and I am locked out again from my user account. I boot down the machine and I boot it back up to see if I can get back in again and nothing works again. I must have gotten lucky once.

I installed a fresh copy of qubes 4.2 from USB. I overwrote the corrupted disk and am starting afresh.

I plan on backing up my headers and making frequent offline copies of my data this-time round. Luckily I was able to get everything of value off before getting locked out again but next time I may not be so lucky.

Thank you for the help all.

1 Like

Glad you saved your data!

You should make sure your hardware is working correctly now before starting using it again. Run a memtest for a few years to check if your system memory is correctly working.

1 Like