Does that mean your system is recovered now? - and you don’t know how it happened?
Or did I misunderstand?
I’m explaining really bad, sorry!
My testing system #1 is not recovered. I only access to my disk using a live USB. Is the system of this topic.
My testing system #2 works well and I succefully change the iteration time to speed up boot.
My testing system #3 is a fresh new installation (the last video) in the same state as system #1, because I did the same mistake.
All I want is to know how (if its possible) to recover systems #1 and #3
Thanks for your patience
bedtime here - I will keep at it though - tomorrow 
Just to clarify, I perfectly know what is the root cause of bad state of systems 1 and 3 (killed slot 1).
But I don’t know, why I cannot kill slot 1 and keep slot 0 with a known password and got a bootable system. Or, another question is, possible to recover my systems 1 and 3? How?
Here too. Thank’s anyway
Finally I can upload images and add links in this forum.
I edited my first post with some snapshots that can help to understand the situation.
Cannot boot after recover from crypto_keyfile.bin - #19 by mserra
Also I edited the video link.
Finally I uploaded a new video version (same link), of the half of time (4:50) speeding up some parts.
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
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
Yes
You changed, added to and then killed Slot 1.
Yes and not… On my system #1 yes, but on system #3 is not necessary do the three steps. Only killing slot 1 it’s enough to broke the system.
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.
Incredible, I followed your indications but my system remains not bootable 
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.
Big thank’s for you patience.
I created a test system #4 (fresh install):
On boot I entered the passphrase (1234):
Slot 0 is unlocked and boots as expected (pay a attention: no grub menu screen, as expected. This is important for later):
I have two used slots:
Now (from the recently installed system) I change iter time for slot 0 and (intentionally) killed the slot 1:
Reboot
I entered my passphrase and I can see slot 0 unlocked, but the boot process not success:
Now I’m on busybox:
I try to recover in your way:
Now slots 0 and 1 and empty. Slots 2 and 3 in use:
umount, close and reboot:
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.
What I’m doing wrong?!
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
@mserra , I suggest you read my featured topic in my profile, click my avatar of this reply.
I explain some stuff which will help you to understand certain stuff involved with encryption and boot sequence…
To help with language barriers I also suggest:
1 Like
I never even attempted to use the 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/sdaXthat 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!
Really an interesting reading. I take a look this morning. Thanks!
Tests done. Here the results:
- 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
luksAddKeythe 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.
I’m not accustomed to identify and report bugs.
Can you (or someone else) help me to identify the actor related whit this (possible) bug?
With actor I’m mean LUKS, GRUB, calamares, Ubuntu, …
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.
but you are agree with that this is not a normal behavior… or yes?
If this behavior is not intentional, this is a bug, correct?
If this behavior it’s intentional, it’s horrible! 
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)