[solved] Initramfs fails to open LUKS root device

[3Nd_R1m]

Issue
After entering a passphrase for the encrypted root device during boot, I get the following error:

Code: Select all

device-mapper: reload ioctl on  failed: Invalid argument
!! Failed to open LUKS device /dev/sdb2
!! Could not find the root in /dev/sdb2
!! Please specify another value or:
!! - press Enter for the same
!! - type "shell" for a shell
!! - type "q" to skip

I then enter the rescue shell, type

Code: Select all

cryptsetup luksOpen /dev/sdb2 root

, provide a valid passphrase, and get the same error:

Code: Select all

device-mapper: reload ioctl on  failed: Invalid argument

Notice the 2 spaces wide blank after "on", it seems the exception itself can't tell what's causing the issue.

Context
I'm currently installing Gentoo for the second time after settling with Artix for two weeks, and I'm using the latest livecd image. Kernel version is 5.10.52, I compile it manually, I don't use any bootloader (I generate an EFIStub) and I use genkernel to generate an initamfs image.

As prescribed here https://wiki.gentoo.org/wiki/Full_Disk_ ... Simplified, I've enabled the following kernel parameters:

• AES cipher algorithms (AES-NI)
• SHA1 digest algorithm (SSSE3/AVX/AVX2/SHA-NI)
• SHA256 digest algorithm (SSSE3/AVX/AVX2/SHA-NI)

Furthermore, I'm able to unlock the device using the same command in the livecd environment.

My config
I use a script to automate the kernel compilation, initramfs and EFI boot entry creation, which should tell pretty much all that's going on:

Code: Select all

kernel_version=5.10.52

# Compile kernel & copy output to /boot/efi/boot
cd /usr/src/linux
make
make modules_install
make install
cp /boot/vmlinuz-${kernel_version}-gentoo /boot/efi/boot/bootx64.efi

# Generate initramfs image & copy output to /boot/efi/boot
genkernel\
    --install\
    --kernel-config=/usr/src/linux/.config\
    --luks\
    initramfs

cp /boot/initramfs-${kernel_version}-gentoo.img /boot/efi/boot/initramfs.img

# Create EFI boot
efibootmgr\
    --disk /dev/sdb\
    --part 1\
    --label "Gentoo"\
    --loader '\efi\boot\bootx64.efi'\
    --unicode 'crypt_root=LABEL=ROOT rw initrd=\efi\boot\initramfs.img'\
    --create
# (/dev/sdb1 being my EFI boot partition)

The script runs successfully with nothing out of the ordinary, appart from these following warnings from genkernel:

• Code: Select all

  Current kernel's LOCALVERSION is set to ''; will ignore set --kernel-localversion value '-x86_64' because kernel was not build...

• Code: Select all

  initramfs: >> Initializing ...
      (...)
      >> Appending modules cpio data ...
          modules: 0 modules copied. Is that correct?
  

• And the usual warning suggesting to add the "crypt_root" and "crypt_swap" kernel parameters that occurs whenever using genkernel with the --luks flag.

I've read several times the manual and my own configs and I can't find the issue, maybe some here could point out what's wrong with my configs or my script.

[alamahant]

Hi plz use a combination of grub and initramfs
In
/etc/default/grub

Code: Select all

GRUB_CMDLINE_LINUX="dolvm crypt_root=UUID=<uuid-of-encrypted-volume> real_root=/dev/mapper/<unencrypted-volume> rootfstype=<ext4?>"
GRUB_PRELOAD_MODULES="part_gpt part_msdos luks lvm"

Then create initrd

Code: Select all

genkernel  --install --luks --lvm  initramfs 

and

Code: Select all

grub-install --target=x86_64-efi --efi-directory=</boot?>
grub-mkconfig -o /boot/grub/grub.cfg
rc-update add dmcrypt boot
rc-update add lvm boot

Plz do NOT use efi stub with this kind of setup.
Even if you wanted to use efistub your efibootmgr invocation seems wrong.
The --loader should be the kernel

Code: Select all

--loader /<kernel>

What you did was to copy the kernel into /boot and rename it bootx64.efi...
I dont know......
Does it work this way?......
Also efistub with luks???
I dont know.....
Do you have

Code: Select all

sys-fs/lvm2
sys-fs/cryptsetup

emerged?

Welcome to Gentoo!

[3Nd_R1m]

Hi, thanks for the reply.

I've always used efibootmgr, and I'm more comfortable using it than higher-level boot toolset, even if it gives me lower-level problem . I know LUKS work with EFISTUB, I got it working on two Arch machine, Artix and on my previous Gentoo machine. The efibootmgr invocation is made as prescribed in the manual https://wiki.gentoo.org/wiki/Handbook:A ... Bootloader, section "Alternative 2: efibootmgr", which recommend copying the loader to /boot/efi/boot/bootx64.efi (probably to protect the target from unintentional overwrite).

Yes, sys-fs/cryptsetup is installed on both my real root and my initramfs. I don't use LVM, so I don't need to specify the --lvm flag when invoking genkernel or to install LVM.

I've yanked and adapted from your grub config the following kernel parameters, hoping than feeding them to efibootmgr would fix the issue:

• real_root=/dev/mapper/root
• rootfstype=ext4

But to no avail.

I don't have much time to fix this issue during the day, so I'll to come back tomorrow with a verbose output of the failing cryptsetup command. I'd like to know the cause of that error message.

[Hu]

Is there anything interesting in dmesg after the cryptsetup call fails?

[3Nd_R1m]

Hi Hu, thanks for joining in.

I found the following in dmesg:

Code: Select all

random: 6 urandom warning(s) missed due to rate limiting
(...)
device-mapper: table: 253:0: crypt: unknown target type
device-mapper: ioctl: error adding target to table

Re-entering the command in the rescue shell logs a second time the two device-mapper messages.

Adding the --debug flag on the cryptsetup invocation gave me the following message:

Code: Select all

device-mapper: target-version ioctl on crypt  failed: invalid argument

I wish googling these errors would've gave me some leads, but it didn't. I'm tempted to re-emerge cryptsetup, though I'd be surprised if changes ensue.

[Hu]

What is the output of cryptsetup luksDump device | grep -e 'Cipher ' -e 'Hash '? I want to check the cipher and hash against your kernel configuration. Those grep filters should avoid showing anything key-specific. My current theory is that your LUKS device requires a kernel feature you did not enable. Please also pastebin the kernel configuration so that we can check it.

[spica]

As prescribed here https://wiki.gentoo.org/wiki/Full_Disk_ ... Simplified, I've enabled the following kernel parameters:

Unfortunately, that is not enough. Look here https://wiki.gentoo.org/wiki/Dm-crypt#K ... figuration

[3Nd_R1m]

You're right, Hu, spica, several kernel features were missing, and enabling those listed in the dmcrypt article solved the issue. Thanks to everyone for the assistance, have a good day.