Cannot boot after recover from crypto_keyfile.bin

I’m 99% sure I already changed that. In a chroot environtment, I did…

# changed */crypto_keyfile.bin* to *none* as password on /etc/crypttab line
# comented the line *KEYFILE_PATTERN=/crypto_keyfile.bin* on /etc/cryptsetup-initramfs/conf-hook
update-initramfs -u -k all
update-grub

@Nachlese thank’s for the aclaration.

100% agree. But I just want to learn and understand because this can happen, and how to solve that (is is possible)

Understandable. Thank’s anyway!

Exactly!

The same key or a different key? If it is a key file is it stored in the initramfs? Is the mount config updated to effect the changes?

However Ubuntu might do it differently, my post was only about a Arch based OS.

If this is a Ubuntu topic, a Ubuntu forum should be used.

the same key - it is stored in / as crypto_keyfile.bin

… unless, of course, this is a remnant of some sort and not the actual key … but I don’t think so

The same key. The key is stored on the root (/) of filesystem.

Sure, but as I said, a lot of Google search results pointed me to this forum. And I am impressed with the quality of the answers in this forum.

Sorry if I make you fell uncomfortable. When you tell me not to bother anymore, I won’t! :saluting_face:

And the same options are used to add key as before and the keyfile is really the same that is stored in the initramfs? Probably better to rebuild it with mkinitcpio.

Just a note here…

That root= kernel parameter is wrong because it needs to point to the container name as in /dev/mapper/xxxx which will be used to mount the root filesystem after the container is decrypted…

Just saying that you can’t really use anything posted here for Ubuntu. It works differently.

yes, yes, I understand! and I am very grateful for the patience and understanding you all have.

I don’t know which options are used during installation - I tried to dig a bit but didn’t find any lead.

I was unable to find anything in the initramfs - just the kernel
I found that strange - probably the wrong file. But I didn’t see another candidate.
Unfamiliar with Ubuntu.

Guys pay close attention what i wrote in

I’d say that this is the wrong path to go down.
The system boots just fine.
Until you kill the key and add it again.
Nothing elsewhere changes.

A few minutes ago I deleted the VM -
perhaps I’ll reinstall - and make sure to make a snapshot before I go to work :slightly_smiling_face:
Not today though …

I’m telling you what is wrong, you are free to ignore that info :wink:

are you saying I must change

linux /boot/vmlinuz-5.15.0-58-generic root=UUID=db38bf32-cd67-433b-8098-0720751466dd ro quiet splash $vt_handoff

to

linux /boot/vmlinuz-5.15.0-58-generic root=UUID=c13ff99a-57b7-4da0-bc1d-15aecce10660 ro quiet splash $vt_handoff

???

My idol! :smiling_face_with_three_hearts: :stuck_out_tongue_winking_eye:

But is it wrong for an Ubuntu system, that might add extra stuff while creating the grub config?

If you open your encrypted container as for example Encrypted using the crypttab or luksopen command then:
You would need:

linux /boot/vmlinuz-5.15.0-58-generic root=/dev/mapper/Encrypted ro quiet splash $vt_handoff

And also use the same /dev/mapper/Encrypted in your /etc/fstab
Otherwise you are NOT using the contents inside the encrypted container as root file system…

This has nothing todo with which distro you use, it is how you mount the root filesystem that is inside an encrypted container…

See: Section 4 of my tutorial

Perhaps Ubuntu specific, but I can tell you with confidence that nothing is wrong/needs to change here. :man_shrugging:

this is the UUID of the filesystem in the opened container (equivalent to /dev/mapper/xyz)
the other one is the UUID of the encrypted partition

If that is true then yea no change needed, but makes it more clear and solid vs mistakes :wink:

Thanks to all.

I’m about to throw in the towel, but first, I’ll try some ubuntu or kde neon forums, see if I can get the tangle out.

Again, thanks to all for your help, patience and good manners!

If I manage to figure out what’s going on, I’ll let you know!

Just to keep in touch…

I can confirm it’s a KDE neon problem :face_with_spiral_eyes: :face_with_spiral_eyes: :face_with_spiral_eyes:
I just installed lubuntu (that uses calamares) and I’m able to recover the system from busybox with a few steps:

cryptsetup luksOpen /dev/sda1 lubuntu
mkdir /lubuntu
mount /dev/mapper/lubuntu /lubuntu
cp /lubuntu/crypto_keyfile.bin ./
umount /lubuntu
cryptsetup luksClose lubuntu
cryptsetup luksAddKey -S 1 /dev/sda1 crypto_keyfile.bin
reboot -f

and the system boots correctly

I posted on a KDE neon forum two hours ago. By the moment no answer.

PD: I tried to install Manjaro Linux on Virtualbox (kde and xcfe edtions) but after setup calamares installer crashes on both systems :man_shrugging: but this is another topic.