I did not watch the video - instead I played around with my system to understand how it works.
My installation was default choices and full encryption
but I didn’t pay attention and ended up with a / and a swap partition
No big difference …
What I found you did:
there are two key slots
Slot 0 can be opened with the password
Slot 1 has got no password, it is opened by the key file instead
You changed, added to and then killed Slot 1.
The key file is now useless and the system can’t access the partitions after the initrd stage
Of course there is a password - but you will not get asked for one again.
(… or something to that effect - my mental picture of the situation might not be accurate)
What I did was:
add a new password to a new slot (slot 2) - also at the same time setting a low iteration value
add the existing key file to another new slot (slot 3)
Now there are 3 slots in your case, 4 slots in mine
Then I killed the first two slots.
Now slot 2 and 3 are used - for the password and the keyfile respectively
Slot 0 and 1 are now empty.
System works as before.
cryptsetup luksAddKey -S 2 /dev/sdaX /crypto_keyfile.bin
to add the key file to new slot
cryptsetup luksAddKey -S 3 -i 30 /dev/sdaX
for the new password slot
the simple solution is to add the key file to an empty slot, I guess
Since it doesn’t boot, boot a live system.
With Luks v. 1 there are 8 slots, if I recall correctly.
Look at which slots are empty
and use these
to add a password to one and the (existing) key file to the other.
Adding another password slot can be done from just the live system.
To add the key file
(really the contents of it)
you have to open the container and mount the partition where the key file is
so you can access and use it
(the path to it)
in the command that adds it to an empty slot.
Then you are sure that you have two slots - one of which can be opened by the key file, the other by password.
I’m not sure whether one can (accidentally or deliberately) kill all slots.
Make sure that at least one slot is accessible through password at all times - else the system will be beyond repair.
Killing slot 1 will remove the possibility to open the container using the key file.
You need to add that again - to the same or to a different, empty slot.
Don’t set a password - use the key file.
Again, I write my passprhase and I read slot 0 unlocked:
Grub menu screen (first incoherence! remember: on successfully boot, no grub screen, directly to desktop as expected):
and the system not boots. If I press enter, stucks on this screen (blocked, cannot navigate over the grub menu). If I press “c”, blocked. If I press “e” blocked, …
The only thing can I do is boot from a live system to test your recomentations.
I don’t know.
I eventually ended up at the same point you are at now.
This happened after I removed the slot 1 (keyfile slot) to see what happens -
I landed in the initramfs - and tried to work from there.
I never again got past the Grub menu that was never shown before.
The difference between what you did and what I did up to that point is:
I never even attempted to use the initramfs.
I booted a live system and used that to make my changes.
reinstall is in progress
I’ll not use the initramfs …
No idea why it worked 5 times, but not anymore as soon as I had first landed in initramfs.
… and I’ll not continue to debug this if that happens again
I don’t know the peculiarities of working with the Ubuntu initramfs.
Apparently (from quick and superficial research) you have to type “exit” and then can start working on whatever problem there is.
I’ll not invest time to find out how to use it - when I see it I’ll just power off and reboot with a live system
with a familiar environment which I know how to operate.
I use a live system.
All you really need to do to get to a quicker decryption time is: sudo cryptsetup luksChangeKey -S 0 -i 30 /dev/sdaX
that lowers the iterations drastically, making decryption faster
no need to mess with the other slots or with the key file or with initramfs
Ok, I have tried to recover an already broke system #4 with a live CD instead of initramfs. With no luck.
I also tried to add/remove/kill keys after umount and close the disk (before I copied the keyfile). Same result.
and I’ll not continue to debug this if that happens again
I don’t know the peculiarities of working with the Ubuntu initramfs
I understand. Thank’s for for time.
Apparently (from quick and superficial research) you have to type “exit” and then can start working on whatever problem there is.
I’ll not invest time to find out how to use it - when I see it I’ll just power off and reboot with a live system
with a familiar environment which I know how to operate.
Add this point, I give it a last try: create a test system #5 and never use the initiramfs, directly use live system. I comment here the results in a couple two or three hours.
All you really need to do to get to a quicker decryption time is: sudo cryptsetup luksChangeKey -S 0 -i 30 /dev/sdaX
that lowers the iterations drastically, making decryption faster
no need to mess with the other slots or with the key file or with initramfs
Thanks, I learned this a few days ago. But again, thanks by your clarification!
If I kill slot 1 (the key file slot) when I’m logged in the recently installed system and before reboot I recover the slot with luksAddKey the recovery works and the system is bootable. OK!
If I kill slot 1 (the key file slot) when I’m logged in the recently installed system before it the system becomes unbootable (forever?!?!). No way to recover from initramfs. No way to recover from live system. KO!
In every case I tested the keyfile with sudo cryptsetup luksOpen --key-file crypto_keyfile.bin --test-passphrase --key-slot 1 /dev/sda1 with a successful result.
I that a bug? LUKS bug? busybox bug? Ubuntu/Debian bug? Calamares bug?
It almost looks like it to me.
But user error/ignorance is still more probable
Once you see the Grub menu - the game is over.
Whatever you do - even though it is the very same that you did before successfully, what worked -
once there, I found no way to recover.
The Grub menu acts a bit like a trap - no way out. Nothing happens.
Very strange.
Since I don’t use Ubuntu normally, I don’t really have to deal with it or find out what the reason for this strange behavior is.
Certainly not me.
One big part of the reason is:
I still believe that I just don’t know exactly what I’m doing, whether this is just incompetence on my part.
That may be due to a bug in my brain “software” - but not in anyone elses.
The probability that we encountered an actual bug is pretty low.
To be honest i don’t think anyone reading is actually understanding what the problem is… (I certainly have a hard time understanding what your actual problem is)
Have you tried using Luks2 (Note that Luks2 is problematic with Grub when rootfs is encripted with it, eg. has problems with Luks2 to boot from)
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…
After reboot, I write the passphrasse of slot 0 (I see slot 0 unlocked)…
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
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.
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
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,
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.
I’m sorry!
