Cannot boot after recover from crypto_keyfile.bin

:cry: I’m sorry!

A last chance please… Forget all I wrote before and, try to help me to solve this simple question: why after remove slot 1 keyfile (but keeping a slot 0 with a known passphrasse), I cannot boot?

After a fresh install, I log in to the new installed system and the only commands executed are…

image

After reboot, I write the passphrasse of slot 0 (I see slot 0 unlocked)…
image

And cannot boot anymore …

image

I hope this was clear now :pray:

Thank’s to everybody for your time and patience!

No. I think calamares uses luks1 by default. As you said, grub and luks2 are not good friends: dm-crypt/Encrypting an entire system - ArchWiki and (as you know) I’m a newbie using LUKS.

Is your initrd using a keyfile that is targeting the secret in Slot 1?
If so it is only logical because you remove the secret that is used to decrypt the container…

Take note that the secrets in each slot are used to access the master key for the container, that master key is used to decrypt the whole container…

Also after any change to stuff like that you need to make sure the changes are flushed to the device, using sync after closing the container :wink:

The installer uses Luks1 for full disk encryption for that reason - one can’t force it to use Luks2

It is a strange and unexpected behavior only triggered when one kills the key slot that is storing the key file.
If you then use that same key file and add it again, to this slot or to another
the system refuses to boot and you get to a non functioning Grub menu and not even the initramfs can’t be reached.

One could use presumably use luksChangeKey instead of wiping the key slot and then re-adding the key.
Don’t know.
This is something the OP encountered when he accidentally wiped the wrong key slot.

The easy workaround is to be more careful and to just not kill the slot that stores the key file to begin with.

It’s probably better to ask this pretty specific question on the Ubuntu fora - since KDE Neon is built on top of Ubuntu.
It seems to be something pretty deep in the way the decryption process is handeled in Ubuntu and/or how Grub is set up.

I’d ask in Ubuntu fora if I where using Ubuntu.
But I’m not, so I won’t. :man_shrugging:
I was simply curious but I’ll stop at this point.

Maybe that one of the reasons why they made Luks2 and everyone using that, or at least are supposed to :wink:

Now that i think about it, it might be something similar as to overwriting a sector of a device with something that is bigger as the original making changes to stuff after it that is not intended,

That is possible - just set up an UEFI system instead of bios and Luks2 is used.
I’ll not pursue this, however …

No why is it unexpected? This is exactly how this works.

After Grub unlocks the LUKS device and loads the initramfs it, the LUKS device does not stay open. The start of the kernel with initramfs is a completely new step in the boot process. Grub has nothing to do with this. It basically starts form the beginning. Where the kernel starts and then systemd. Systemd (or any other init) starts mounting the root fs, which is in a LUKS device. So the LUKS device needs to be opened by systemd first. Depending on how this is configured, systemd may looks for a key file.

Of course it is expected to not boot when there is no key in the key slot
But even after the key is added it will still not boot.

The Grub “recordfail” function is set to show that Grub menu you see in some of his pictures - with 30 second timeout.

Once this was present I never was able to get past it. Key or no key …

I even reset the recordfail file with grub-editenv - but of course this was futile.
… regenerated the initramfs, updated grub - nothing changed

If you have time on your hands and want to see for yourself … :grimacing:
I did it in a VM - as a bios system with mbr partition.

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

???