Recent update destroyed everything. Disk password cannot be unlocked in any environment

I recently just started using my qubesos laptop again, and it was all fine, but after updating everything after a few boots everything just stopped working. Here’s what happens;

I recently just started using my qubesos laptop again, and it was all fine, but after updating everything after a few boots everything just stopped working. Here’s what happens;
I open the laptop and see the disk password screen and then it all goes wrong. It gives me a few tries to put in the password but no matter what I put is wrong and the 3rd password attempt no matter what I put in seems to be accepted but the progress bar takes a long time to load and when it does after about 7 minutes~ it just crashes, sends me to emergency shell and says I need to regenerate initramfs.

So I get a live boot qubes usb and choose rescue a qubes os system and I try to unlock it there but.. it never accepts the password even though I know it’s right. I’ve also tried unlocking the partition in a live boot mint ubuntu usb but still no luck.
In Qubes after the 3rd attempt and it “accepts” it, I press esc and it says FAILED to start systemd-cryptsetup@luks … - Cryptography Setup for luks …
and then after dracut error queue it sends me to emergency shell..

Sorry did not mean to write it in code I hope it’s still readable it’s just really late at night I’ve been at this for a few hours.

You were just mislead by the visual loading + unlock screen. It also fails each time you put in your password and just doesn’t show you.

Just press escape when you see that mask you’ll fallback to the raw systemd messages + disk unlock.

Yes I already said that. I’ve tried that already, and the disk cannot be unlocked even using another OS to try and unlock the disk. How am I supposed to regenerate initramfs if the disk password is bugged? I have no idea what went so wrong here..

You did not.


Look into luks - it is not a qubes os topic by itself. Maybe start with a cryptsetup luksDump /dev/sdX

Yeah I tried that and it seems to be sane somehow. Honestly.. I’m about to give up and reinstall, because it seems no one has ever encountered this specific problem before. It can’t accept any disk password without the initramfs being regenerated but I don’t think I can do that without unlocking the disk password first.

It really sucks because I have all my btc and monero in there. If it helps sweeten the pot maybe I can set a bounty for whoever helps me solve this?

It only hints you to regenerate, because the unlock failed.

Did you?

I guess you already tried to boot up with previous kernel, the one that worked before updating?

A good suggestion from @balder86…

Some maybe not so good or too obvious ideas:

Have you looked at the password you are typing? I had a lot of problems with a faulty keyboard (I think ‘s’ was unreliable). I only saw it when the pw was displayed.

Also, is it possible there is a keyboard layout change? Even right language but wrong variant can move the special characters…

(edit: you can use a live or rescue system to back up your disk before reinstalling. You may find the solution later!)

Sorry, what exactly are you asking? I’m having a little bit of a brainfart reading that, my english isn’t the best.

Nope I really doubt that. I did try to boot with it AFTER this problem and still got the same issue..

Yeah that was the first thing I tried and after realizing this wasn’t the issue I really started panicking. I REALLY hope my system isn’t bricked, I keep all my personal info and crypto here. That 100% isn’t the issue, it doesn’t matter what I type something is definitely deeply wrong in my system.

Yeah thanks for the suggestion, I’m planning of doing this but if I lose all that it would really suck and defeat the whole purpose I got into qubes in the first place. This is just insane to me and I feel so dumb.

Surely I’m just overlooking something and being an idiot. I’m not a programmer or anything but I’ve been really into linux and hopping between distros since covid, but this problem just seems a little out of my field here.. Is it maybe worth getting in contact with a developer or something?

My English might not be 100% I’m sorry, it’s my second language, but I feel like I’ve perfectly communicated the problem I’m experiencing. I can even provide photos of what exactly it’s telling me if it’s needed. I feel like I’ve tried everything that I can.

Your issue has nothing to do with qubes os - you can’t even unlock your disk via a live boot environment.

Therefore - dive into checking luks.

Yeah exactly it just doesn’t accept the password even though it’s right even in live boot environment so maybe you’re right that it’s not 100% qubes related.

Well it stopped working like a day after I updated it that’s most likely the cause of all this, but yeah you’re right, where else should I ask this then? It seems it’s not a simple fix and I’ll need to ask someone who is more knowledgeable about luks specifically.

I don’t get what you mean that’s kind of vague. You mean do research and learn about luks? Sounds like a time waste I really doubt that’ll help me here.

I’d be better off just asking someone who already knows because I don’t think this is something simple I could learn the fix to in a few days. I’m not really familiar with super advanced linux code and not sure what exactly I can do here without unlocking the disk.

Do you at least have an idea of what’s happening here? I have a few guesses but I’m not really sure. The luks header doesn’t look corrupted and the password is definitely not wrong so I’m stuck here. Plz help on this.

First thing: did you do a backup of the full disk yet? I recommend the full device, including boot and efi partitions. Everything!

If you did that during recent tries, then did do it before, when the unlock was working?

I am still thinking of keyboard layout… default for early boot is en_us, but it can be changed.

After that backup, you can make a backup of the header using
cryptsetup luksHeaderBackup --header-backup-file a_filename.img /dev/your-disk
(Of course, put a useful filename and device)

Then you can take the file to any linux with recent cryptsetup for testing with
cryptsetup luksOpen --test-passphase a_filename.img

At least it lets you play with kb layout, and other things, without waiting for a whole reboot!

Not yet but yes I’ll do it now and just keep it stored while I reinstall hopefully someone helps me find the solution later

No it wasn’t that either I checked and it was the same symbol