Full Disk Encryption decrypting problem: no such cryptodisk found

Big Scorpio · 2024-12-28 15:20:36

Hello Arch Friends,

I am setting up Edward Snowden like level security & privacy on my system by utilizing FDE (and no, let's not start with Qube OS for that). I ran into a decryption problem but first here's my structure:

nvme0n1 _______________// my NVME M.2 SSD
- nvme0n1p1 ____________// the unencrypted 
- myencrypteddrive _______// the set up encrypted "partition" using cryptsetup luksFormat (to create it) and luksOpen (to decrypt and access it)
-- VolGroup-boot _________// logical volume for encrypted boot
-- VolGroup-swap ________// also logical volume for encrypted swap memory
-- VolGroup-root _________// and for root
-- VolGroup-home ________// and for home too

The mounting points are (assuming it's the live environment of Arch Linux)

nvme0n1p1 -> /mnt/boot/efi
VolGroup-boot -> /mnt/boot
VolGroup-root -> /mnt
VolGroup-home -> /mnt/home

Since I am using GPT and not MBR.

Now since I have 2 boot partitions I am unsure of the correct structurization in order for the system to boot into the unencrypted boot first and then boot into the encrypted boot partition and initialize the kernel and initramfs.

What I did do was generate 2 GRUBs, although i am sure that's where i am making a mistake here. The default GRUB config contains (from "/etc/default/grub")

# For context i extracted the drive and volume UUID's as follows (for simplicity reasons i shorten it)
# > blkid /dev/nvme0n1p2 -o value -s UUID
# Nvmep2-1234-abcd
# > blkid /dev/mapper/myencrypteddrive -o value -s UUID
# MyEncr-ypte-dDri

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet cryptdevice=/dev/nvme0n1p2:myencrypteddrive root=/dev/mapper/VolGroup-root"
GRUB_CMDLINE_LINUX="loglevel=3 quiet cryptdevice=/dev/nvme0n1p2:myencrypteddrive root=/dev/mapper/VolGroup-root"

GRUB_PRELOAD_MODULES="part_gpt part_msdos"

GRUB_ENABLE_CRYPTODISK=y

# Alternative default grub settings i have tried
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet cryptdevice=UUID=Nvmep2-1234-abcd:myencrypteddrive root=/dev/mapper/VolGroup-root" # just like found in the Arch Wiki's dm-crypt
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet cryptdevice=UUID=Nvmep2-1234-abcd:myencrypteddrive root=UUID=MyEncr-ypte-dDri"

The rest is left per default values.
Then i ran

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=myGrub
grub-mkconfig -o /boot/grub/grub.cfg

I created a EFI boot manager too like this

efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "Arch Linux" --loader /EFI/GRUB/grubx64.efi

And then there's the "/etc/mkinitcpio.conf" containing

MODULES=(f2fs)
HOOKS=(base udev autodetect microcode modconf keyboard keymap consolefont block encrypt lvm2 filesystems fsck)

Of course i did not forget to execute "mkinitcpio -P" afterwards.

Now.

I *can* open the LUKS container using the "cryptsetup luksOpen /dev/nvme0n1p2" command and mount it and access it like i described above in the first 2 code sections (using "mount /dev/VolGroup/root /mnt" and "mount /dev/VolGroup/boot /mnt/boot" and so on).

What I *can't* do is booting into the encrypted partition from the unencrypted boot partition.
I am seeing the "Enter passphrase for hd6,gpt2 (<UUID string here>)"
Entering the passphrase right or wrong yields this outcome

error: Invalid passphrase.
error: no such cryptodisk found, perhaps a needed disk or cryptodisk module is not loaded.
error: disk `lvmid/<a string, that looks like UUID but includes any alphabetic letters too>/<a string, that too looks like a UUID with alphabetic letters> not found.`
// for example: Lg2fTs-VEwy-VNXf-Z363-owMc-A0h4-FeMb0y/<and another one like that here too>
Entering rescue mode...

There are 3 error messages at once. Which is the real one? It can't really be the passphrase because i and luksOpen it in the live environment, or can it be?
What went wrong here?
This is confusing. I keep guessing what it might be and end up incorrect. My next guess is, am i missing to specify boot and home in /etc/default/grub or what?

Last edited by Big Scorpio (2024-12-28 16:16:24)

nl6720 · 2024-12-29 12:41:27

Since you didn't mention it, I'm assuming you used the default options of cryptsetup luksFormat, i.e. with the Argon2id PBKDF. In which case, the warning in https://wiki.archlinux.org/title/Dm-cry … ion_(GRUB) applies to you.
Also mind that GRUB has some issues with F2FS. Which file system is on VolGroup-boot?

IMO you could avoid a lot of pain by not encrypting /boot and simply mounting the ESP to /boot.

Big Scorpio · 2024-12-29 17:34:59

nl6720 wrote:

Since you didn't mention it, I'm assuming you used the default options of cryptsetup luksFormat, i.e. with the Argon2id PBKDF. In which case, the warning in https://wiki.archlinux.org/title/Dm-cry … ion_(GRUB) applies to you.

Gah, what's with these nooby and simple FDE guides out there? I did it similarly but with some other parameters "cryptsetup luksFormat /dev/nvme0n1 --cipher aes-xts-plain64 --key-size 256 --hash sha256" - I heard these 3 arguments are redundant because luksFormat uses these 3 parameters as default already but it can't hurt to be precise with that.

Now, am I to start all over again but with "--pbkdf pbkdf2" when performing luksFormat ?

Or should I try making grub work with what i have now using grub-improved-luks2-git ( https://aur.archlinux.org/packages/grub … -luks2-git ) ?

nl6720 wrote:

Also mind that GRUB has some issues with F2FS. Which file system is on VolGroup-boot?

I double checked that. I formatted both VolGroup-boot and nvme0n1p1 (the unencrypted /boot/efi one) in FAT32. Performing the "blkid" command i saw, that they are both of TYPE="vfat"

nl6720 wrote:

IMO you could avoid a lot of pain by not encrypting /boot and simply mounting the ESP to /boot.

Yeah, that may be easier and more convenient but not so Edward Snowden like. It's the undesirable fallback option for me.
What is ESP? Is it the EFI targeted boot thingy?

Last edited by Big Scorpio (2024-12-29 17:37:06)

nl6720 · 2024-12-29 17:55:56

Big Scorpio wrote:

I did it similarly but with some other parameters "cryptsetup luksFormat /dev/nvme0n1 --cipher aes-xts-plain64 --key-size 256 --hash sha256" - I heard these 3 arguments are redundant because luksFormat uses these 3 parameters as default already but it can't hurt to be precise with that.

You can check the defaults by running

$ cryptsetup --help

and looking at the "Default compiled-in device cipher parameters".
You're actually reducing the encryption strength to AES-128 with your --key-size 256 since the default for XTS mode is 512 (AES-256).

Big Scorpio wrote:

Now, am I to start all over again but with "--pbkdf pbkdf2" when performing luksFormat ?
Or should I try making grub work with what i have now using grub-improved-luks2-git ( https://aur.archlinux.org/packages/grub … -luks2-git ) ?

It's your decision whether to use a patched GRUB or not. If you're going with PBKDF2, then you don't need to start over, you can simply convert the keyslot. See https://wiki.archlinux.org/title/Dm-cry … 2_and_back.

Big Scorpio wrote:

Yeah, that may be easier and more convenient but not so Edward Snowden like. It's the undesirable fallback option for me.

If your adversary is a state actor, then your biggest threat will be rubber-hose cryptanalysis. And your encrypted /boot alone doesn't protect against evil maid attacks.

Big Scorpio wrote:

What is ESP? Is it the EFI targeted boot thingy?

ESP is the EFI system partition.

Last edited by nl6720 (2024-12-29 18:13:42)

Big Scorpio · 2024-12-30 00:31:43

nl6720 wrote:

You can check the defaults by running
$ cryptsetup --help
and looking at the "Default compiled-in device cipher parameters".
You're actually reducing the encryption strength to AES-128 with your --key-size 256 since the default for XTS mode is 512 (AES-256).

Got it. It created the volume with LUKS2 by default with Argon2 i saw on the dump.
I first tried the grub-improved-luks2-git thingy installing it from AUR. During build time it failed with an error code 4 - "failure occurred in prepare() aborting". Yeah, I'm turning away from that.
I had it reencrypt with "cryptsetup reencrypt --cipher aes-xts-plaintext64 --key-size 512 --hash sha256" to AES-256 using Key size 512.
And then I did the "cryptsetyp luksConvertKey --hash sha256 --pbkdf pbkdf2 /dev/nvme0n1p2" to convert the key to PBKDF2. // For users with the same problem, this here << did it for me

Now the initial error has vanished for the "Enter passphrase for hd6,gpt2 (<UUID here>):". I got past it, at last. Thanks for that man.

But now I'm encountering a new problem. The system asks me for a second time for the passphrase before getting into the Arch Linux environment. This prompt says "A password is required to access the myencrypteddrive volume:"

Me confused. Why are there 2 layers of that? I decrypted the partition and now it asks me for the same passphrase to access the encrypted volume? That's once too much for me. I'd be willing to automate an auto-unlock thingy once past the initial prompt.

Furthermore (and that's more where I screwed up to configure grub) I encounter a mounting error after I entered the passphrase correctly

mount: /new_root: can't find UUID=<UUID>.
ERROR: Failed to mount 'UUID=<UUID>' on real root
You are now being dropped into an emergency shell.

For this problem it appears I need to tune the /etc/default/grub accordingly. That or something's not right with the real root as per the error message. The UUID number I see corresponds to the UUID of "/dev/mapper/myencrypteddrive"

In my /etc/default/grub I have defined it as

GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet cryptdevice=UUID=<UUID of '/dev/nvme0n1p2'>:myencrypteddrive root=UUID=<UUID of '/dev/mapper/myencrypteddrive'>"

I'm going to double check that now just in case.

nl6720 wrote:

If your adversary is a state actor, then your biggest threat will be rubber-hose cryptanalysis. And your encrypted /boot alone doesn't protect against evil maid attacks.

I see your point. For my purposes (at least currently) that level of security suffices. Welp, can't really think of a way to mitigate an Evil maid attack. I liked how you explain it briefly using a simple image.

nl6720 wrote:

ESP is the EFI system partition.

Got it (insert a thumbs up emoji here)

Last edited by Big Scorpio (2024-12-30 00:32:08)

kermit63 · 2024-12-30 01:05:24

check your /etc/default/grub, specifically the GRUB_ENABLE_CRYPTODISK=y line. It should be commented out since you're not using the built-in GRUB decryption algorithm, but the kernel parameter "cryptdevice=...."

Otherwise, check if you have any entry in /etc/cryptttab.

Last edited by kermit63 (2024-12-30 01:06:50)

nl6720 · 2024-12-30 11:00:22

kermit63 wrote:

check your /etc/default/grub, specifically the GRUB_ENABLE_CRYPTODISK=y line. It should be commented out since you're not using the built-in GRUB decryption algorithm

They are using it, /boot is encrypted.

Big Scorpio wrote:

But now I'm encountering a new problem. The system asks me for a second time for the passphrase before getting into the Arch Linux environment. This prompt says "A password is required to access the myencrypteddrive volume:"
Me confused. Why are there 2 layers of that? I decrypted the partition and now it asks me for the same passphrase to access the encrypted volume? That's once too much for me. I'd be willing to automate an auto-unlock thingy once past the initial prompt.

The first password prompt is from GRUB, the second one is from cryptsetup or systemd-cryptsetup in early userspace. The https://wiki.archlinux.org/title/Dm-cry … ion_(GRUB) scenario which you called "nooby and simple" has detailed instructions on avoiding having to enter the passphrase twice.

Big Scorpio wrote:

Furthermore (and that's more where I screwed up to configure grub) I encounter a mounting error after I entered the passphrase correctly
mount: /new_root: can't find UUID=<UUID>.
ERROR: Failed to mount 'UUID=<UUID>' on real root
You are now being dropped into an emergency shell.
For this problem it appears I need to tune the /etc/default/grub accordingly. That or something's not right with the real root as per the error message. The UUID number I see corresponds to the UUID of "/dev/mapper/myencrypteddrive"
In my /etc/default/grub I have defined it as
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet cryptdevice=UUID=<UUID of '/dev/nvme0n1p2'>:myencrypteddrive root=UUID=<UUID of '/dev/mapper/myencrypteddrive'>"

If you run

# ls /dev/disk/by-uuid/

in the emergency shell, is that UUID there?

Your shouldn't even need to specify the root= parameter manually when using GRUB with a grub-mkconfig generated /boot/grub/grub.cfg.

Last edited by nl6720 (2025-01-02 11:15:38)

Big Scorpio · 2024-12-30 19:02:09

nl6720 wrote:

The first password prompt is from GRUB, the second one is from cryptsetup or systemd-cryptsetup in early userspace. The https://wiki.archlinux.org/title/Dm-cry … ion_(GRUB) scenario which you called "nooby and simple" has detailed instructions on avoiding having to enter the passphrase twice.

Hold on, this is a misunderstanding. I was not referring to the arch wiki as "nooby and simple". I was referring to guides like this and similar online resources, leaving behind gaps or much to be desired. Those are nooby and simple as in they don't take into consideration using all relevant partitions (swap, home) and using an encrypted boot partition.

nl6720 wrote:

If you run
# ls /dev/disk/by-uuid/
in the emergency shell, is that UUID there?
You shouldn't even need to specify the root= parameter manually when using GRUB with a grub-mkconfig generated /boot/grub/grub.cfg.

That figures. The cryptdrive UUID matches from the list and the UUID defined in "root=UUID=<UUID>" is not found in there. Those results have all true UUID values from 0 to f. Guess where I got that from? Actually from both, the youtube guide and the arch wiki.

Anyway, I removed the "root=UUID=<UUID>" part from the kernel command line found in "/etc/default/grub" (GRUB_CMDLINE_LINUX_DEFAULT)
And then I followed the instructions here to avoid entering the passphrase twice

This worked for me. I am now successfully using Arch Linux with FDE enabled. Finally.
Thanks for the great help nl6720. You're quite knowledgeable about these things.

I'm thinking about taking a few more steps to defend myself against Evil Maid attacks with cryptboot and utilizing chkcryptoboot to encrypt the /boot partition to protect against offline tampering threats. Just to complete my defenses. So far I see, that chkcryptoboot is being an alarm system to detect possible tampering and not doing any actual boot encryption?
However this is new territory for me as it was with FDE in Linux.
I wonder if either of those conflicts with one another? Can I make it?

nl6720 · 2025-01-02 11:20:52

Oh. Sorry for misunderstanding that.
I wouldn't call myself knowledgeable, it's just that I've played around with various types of setups

I've never tried chkboot, chkcryptoboot or things like that. They've always looked too overcomplicated for me. IMO the simplest solution would be Secure Boot, but, IIRC, setting up GRUB with Secure Boot is a pain (GRUB tends to be a pain in general...).

Arch Linux

#1 2024-12-28 15:20:36

Full Disk Encryption decrypting problem: no such cryptodisk found

#2 2024-12-29 12:41:27

Re: Full Disk Encryption decrypting problem: no such cryptodisk found

#3 2024-12-29 17:34:59

Re: Full Disk Encryption decrypting problem: no such cryptodisk found

#4 2024-12-29 17:55:56

Re: Full Disk Encryption decrypting problem: no such cryptodisk found

#5 2024-12-30 00:31:43

Re: Full Disk Encryption decrypting problem: no such cryptodisk found

#6 2024-12-30 01:05:24

Re: Full Disk Encryption decrypting problem: no such cryptodisk found

#7 2024-12-30 11:00:22

Re: Full Disk Encryption decrypting problem: no such cryptodisk found

#8 2024-12-30 19:02:09

Re: Full Disk Encryption decrypting problem: no such cryptodisk found

#9 2025-01-02 11:20:52

Re: Full Disk Encryption decrypting problem: no such cryptodisk found

Board footer