Thannk you for reporting

This is my favourite setup too :)

I have three systems with separate ext4 /boot, and LVM on an LUKS encrypted pv, / /home swap in the LVM.  No problems noted with any kernel yet, incl all three flavours of 6.6.74-1

CC our kernel guru about ideas how to see what is going on.


A couple ideas to begin with:

§ Do you see text messages scrolling during boot?  If not, enable by removing splash quiet by editing kernel parameters from grub boot menu (button "e")

§ Try kernel-linus variant (it is less patched by us)

CC: (none) => fri, ghibomgx
Source RPM: kernel-desktop-latest => kernel
Assignee: bugsquad => kernel

(In reply to Morgan Leijström from comment #1)
> 
> This is my favourite setup too :)
 
Yes, it is a useful setup, better for laptops (IMHO). One feature that has to be in the insallation GUI is to proprely configure an external USB keyfile though.  
 
> § Do you see text messages scrolling during boot?  If not, enable by
> removing splash quiet by editing kernel parameters from grub boot menu
> (button "e")

On GRUB console --> removed "splash quiet", after the passphrase, it shows the message "No key available with this passphrase", no further information displayed: 

https://filedn.eu/lRcVFGenfMnV2EQ3udYiGbz/pubfiles/bugs_mageia_org-id_33997/IMG_20250208_125213906.jpg

(please note in the picture, that /dev/sdb1 is an aditional HDD encrypted with a keyfile used with crypttab) 
 

> § Try kernel-linus variant (it is less patched by us)

I've tried 6.6.74 (kernel-linus RPM) the result is the same: "No key available with this passphrase"

Does it might be cipher support with this newer kernel version? Does a cryptsetup luksDump may help?

Finally I was able to boot the system with kernel 6.6.74-desktop-1.mga9. And found something interesting:

On my previous comment, I mentioned that my system has an aditional HDD. This device has also LVM on LUKS, on its own volume group. This HDD was added recently and setup using drakconf.  

With cryptsetup, added a new keyfile, also modified crypttab in order to unlock the HDD during boot. When the system was running, two symlinks were shown in /dev/mapper: crypt_sda5 (SO device), and crypt_sdb1 (which is the recently hdd added) 

That was working fine until kernel 6.6.74. The image posted on my previous comment gives a glimpse of what's going on:

Booting 6.6.74 asks for the passphrase for /dev/sda5 (crypt_sda5) but I did not noticed that actually the passphrase was approoved, I mean the "No key available with this passphrase" error is from /dev/sdb1. So it seems it tries to use the same passphrase input for the previous device.

What I did was to add a new key with the same passphrase on /dev/sdb1, and it worked! By typing the passphrase on boot once, both drives are unlocked and the system boots smoothly. 

What interests me is that crypttab seems not been used anymore. I mean (maybe I'm wrong) on previous kernel versions, I put the passphrase for sda5, it unlocked the SO drive, read the crypttab and unlocked the second drive, done. But now, two passphrases has to be input (just one if it is the same)

Once again, the image posted on my previous comment shows:

luksOpen /dev/sda5 crypt_sda5
luksOpen /dev/sdb1 luks-xxxxxx... << I was expecting to be crypt_sdb1

In fact now with the system runing with 6.6.74, /dev/mapper does not show show crypt_sdb1 anymore, it shows luks-<uuid>

Is there a way to unlock the second device as before, by using a keyfile? 
maybe there is something in the initrd file? I dont know... :)

Unfortunately I know less about LVM and LUKS than you.  I just use then the simplest way - only keyed in passphrase.

Wonder if Lewis or Dave may know what to look for. CC-ing them.

Even if it is diskdrake that have not set up things correctly (if we find so, file a bug) it is interesting that the different kernel versions act differently.  Maybe Giuseppe can tell what that difference may be.

Kernel 6.6.76-1 is now in testing, but not yet assigned to QA.
If we are lucky there is a related issue in .74 fixed in .76.

CC: (none) => davidwhodgins, lewyssmith

As Morgan suggested, it might be worthwhile to test with 6.6.76 as well, even though it hasn't been assigned to QA yet.
  
Beyond removing "splash" and "quiet", consider testing (on any kernel you test) with the following boot option: "maxcpus=1 vga=normal". This 
might helps avoid plymouth screens or potentially spawning too many parallel cryptsetup processes that prompts for passwords. Try entering the password prompted for each partition, even if it's the same as the previous one. Probably you would still see the "No key available with this passphrase" message even on kernels where things work correctly.

As far as I know, there were no changes to crypto features in 6.6.74|76 compared to 6.6.65. A possibility is that the issue might have triggered or brought to surface a bug in our cryptsetup management that was previously hidden.

Also, regenerate the initrd image with "dracut -f" if you make any modifications to your setup. "lsinitrd" will show what is included.

By the way, are you using an NVidia card? If so, try booting also with adding "nouveau.modeset=0" your boot cmdline, or alternatively boot in console mode (by adding "3" to the end of booting cmdline), so to avoid X11 is started before all the cryptsetup prompting passwords are completed.

Hello Giuseppe. 

I've tried to test the behavior with your suggestions but it is the same.  

So far I have been very busy without little time to spare to issue other tests. I'm thinking to setup a VM and try to replicate the same scenario. I believe it will be easier and/or faster; or maybe find if I did something wrong. 

I think for now, as a workaround, have both passphrases the same to boot smoothly.