No LUKS Password Prompt at Boot – Ubuntu 24.04 + Calamares

[DanielSilva]

Hello Linux World friends, I customized an Ubuntu 24.04 using the Penguin-Eggs project, but I noticed that whenever the option to encrypt the disk (to require a password at boot to decrypt the /) is selected, it simply drops to the initramfs screen.


I would like to know if there is a way to fix this. I’m not sure if it’s something specific to Calamares or something like that.

When the system installation finishes with encryption enabled, after the boot loading, the system drops to the initramfs prompt, as if it can’t automatically mount the encrypted partition. I need to enter the password manually inside initramfs.If I’m not mistaken, Calamares uses LUKS2 encryption inside the /dev/sd* — in my case, /dev/vda since it’s a VM.

From what I can tell in the initramfs, the encryption is actually in place — it just doesn’t prompt for the password at boot and fails to start the system.
Can someone help me with this?

 

[Trml]

It is an interesting project I have not used before. I notice a recent bug report related to its boot loader cloning on Ubuntu and your issue may well be linked to it. If that's the case, you should be able to
(1) unlock the encrypted root on the initramfs commandline, e.g.

cryptsetup open /dev/vda2 ubuntu

(2) detect LVM

vgscan /dev/mapper/ubuntu
vgchange -ay /dev/mapper/ubuntu

(note "ubuntu" may not be the right dmname (device mapper name) - I forgot what's used by default, but you can check on your cloned system)
(3) Let the initramfs mount the volumes and boot automatically with

exit

If that works, double check how to manually run grub-install and grub-mkconfig after.

 

[DanielSilva]

The problem isn't mounting the system through initramfs, but rather that Calamares performs the encryption and then drops into initramfs.


After the Calamares installer runs, the system should be installed normally by default, but that's not what happens. A normal installation without encryption works perfectly, but when encryption is selected (as shown in the image I sent), it boots into initramfs.

 

[Trml]

Well, the installer you show in the first picture is not the default Ubuntu, so I assume it's the front-end from the penguin-eggs project. Have you looked at its bug report I linked above in the second sentence, or verified the bootloader installation did complete? If yes (e.g. you arrive at the grub menu), you can probably just boot manually from the initramfs, verify the /boot mount is correct and run Ubuntu's update-grub to let repeat generating its config.

 

[Alexzee]

Did the integrity of the .iso file check out?

 

[theLegionWithin]

agreed, that is an interesting project - assuming the resulting iso functions without error it could be a way to keep a snapshot on hand (assuming user data was backed up separately - including it would cause the iso to balloon in size to much I'd think).

i'm going to play around with that later on this week.

 

[DanielSilva]

Good morning everyone, I managed to fix it; it was just a simple setting in GRUB.

 

[Alexzee]

Good morning everyone, I managed to fix it; it was just a simple setting in GRUB.

Details please on what you did-

 

[DanielSilva]

Issue with LUKS 2 on GRUB and how it was resolved:We encountered a problem where GRUB was unable to properly handle LUKS 2 encrypted partitions. The issue was due to GRUB not supporting the newer LUKS 2 format by default.To resolve this, we updated GRUB to a version that includes support for LUKS 2. Additionally, we regenerated the GRUB configuration files to ensure it recognizes the encrypted partitions correctly.After these steps, GRUB was able to decrypt and boot from the LUKS 2 encrypted volumes without issues.

 

[Alexzee]

Issue with LUKS 2 on GRUB and how it was resolved:We encountered a problem where GRUB was unable to properly handle LUKS 2 encrypted partitions. The issue was due to GRUB not supporting the newer LUKS 2 format by default.To resolve this, we updated GRUB to a version that includes support for LUKS 2. Additionally, we regenerated the GRUB configuration files to ensure it recognizes the encrypted partitions correctly.After these steps, GRUB was able to decrypt and boot from the LUKS 2 encrypted volumes without issues.

Good information.
Thanks for the details.
Alex

 

[Trml]

For posterity, the trouble to update GRUB with LUKS2 support was unnecessary. It is only needed when you use LUKS2 to encrypt /boot. The root volume is decrypted by the cryptsetup in the initramfs. What will have fixed is the regeneration of GRUB configuration, correcting the UUID the initramfs tries to unlock.