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
@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)
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.
Understandable. Thank’s anyway!
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!
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…
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
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…
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
Not today though …
I’m telling you what is wrong, you are free to ignore that info
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
linux /boot/vmlinuz-5.15.0-58-generic root=UUID=c13ff99a-57b7-4da0-bc1d-15aecce10660 ro quiet splash $vt_handoff
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
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…
Section 4 of my tutorial
Perhaps Ubuntu specific, but I can tell you with confidence that nothing is wrong/needs to change here.
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
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
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
mount /dev/mapper/lubuntu /lubuntu
cp /lubuntu/crypto_keyfile.bin ./
cryptsetup luksClose lubuntu
cryptsetup luksAddKey -S 1 /dev/sda1 crypto_keyfile.bin
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
but this is another topic.