Grub fails to decrypt partition while it can be done from a USB Live Fedora just fine

Ask Fedora
, ,
1

I managed to boot a Macbook Air 1369 (2012) from a USB drive and installed Fedora 37 on it, on an encrypted partition.

During installation an error popped up, saying the system will fail to boot, but luckily it offered the option to continue installing.

Long story short, I booted again from the live image and was able to mount the encrypted partition just fine:

$ sudo blkid
/dev/sda1: UUID="..." TYPE="hfsplus" LABEL="LINUX HFS+ ESP"
/dev/sda2: UUID="..." TYPE="ext4"
/dev/sda3: UUID="..." TYPE="crypto_LUKS"

$ sudo cryptsetup luksOpen /dev/sda3 crypt_1
Enter passphrase for /dev/sda3: topsecret

$ sudo lsblk
- sda3      ... 232.2G 0 part
  - crypt_1 ... 232.2G 0 crypt

$ sudo mount /dev/mapper/crypt_1 /mnt

$ ls /mnt
home root

When booting from the SDD, grub only shows a single “UEFI Firmware Settings” option. So the question is how to boot the installed Fedora.

There is an EFI partition (hd1,gpt1), a boot partition (hd1,gpt2) and the encrypted partition (hd1,gpt3). In the grub prompt I tried to manually decrypt the partition:

grub> cryptomount -a
Enter passphrase for hd1,gpt3 (96bc151a...):
error: ../../grub-core/disk/luks2.c:748:Invalid passphrase.

Am I misusing cryptomount? Why can it be opened from Linux but not from Grub?

If I try to boot the thing on the boot partition, the CPU fan starts spinning but nothing else happens:

grub> echo $kernelopts
root=UUID=b57f39e6-... ro 
    rootflags=subvol=root 
    rd.luks.uuid=luks-96bc151a-... 
    rhgb quiet

grub> linux (hd1,gpt2)/vmlinuz-6.0.7-301.fc37.x86_64 $kernelopts
grub> boot

The “10_linux” section in the grub.cfg file runs blscfg which should create the relevant menu entries in the Grub boot menu:

grub> cat (hd1,gpt2)/grub2/grub.cfg
[...]
### BEGIN /etc/grub.d/10_linux ###
[...]
# The blscfg command parses the BootLoaderSpec files stored in /boot/loader/entries and
# populates the boot menu. Please refer to the Boot Loader Specification documentation
# for the files format: https://systemd.io/BOOT_LOADER_SPECIFICATION/.

set kernelopts="root=UUID=... ro rootflags=subvol=root rd.luks.uuid=luks-... rhgb quiet "

insmod blscfg
blscfg
### END

For some reason blscfg fails to create the menu entries. As per the URL in grub.cfg, entries can be defined in two ways:

  • One of them is “Boot Loader Specification Entries” files in $BOOT/loader/entries folder, but this one is missing altogether.
  • The other is “EFI Unified Kernel Images” which should be placed in $BOOT/EFI/Linux, which also does not seem to exist.
grub> ls (hd1,gpt2)
./
../
lost+found/
efi/
symvers-6.0.7-301.fc37.x86_64.gz
grub2/
.vmlinuz-6.0.7-301.fc37.x86_64.hmac
System.map-6.0.7-301.fc37.x86_64
config-6.0.7-301.fc37.x86_64
initramfs-6.0.7-301.fc37.x86_64.img
vmlinuz-6.0.7-301.fc37.x86_64

grub> ls (hd1,gpt2)/grub2
./ ../ fonts/ grubenv grub.cfg

Any idea how is this Fedora system supposed to boot? Thanks

2

As can be seen in anaconda/bootloader.py at 0c49565e79f60539f0da01d05591dd3233e2fe62 · rhinstaller/anaconda · GitHub the BLS entries are created after the Bootloader is installed, but the failure of the bootloader installation prevents the BLS entries to be created.

This can be fixed by running the kernel-install and grub2-mkconfig commands manually, as per anaconda/utils.py at 0c49565e79f60539f0da01d05591dd3233e2fe62 · rhinstaller/anaconda · GitHub

$ sudo cryptsetup open /dev/sda3 crypt1
$ sudo mount /dev/mapper/crypt1 /mnt
$ sudo mount /dev/sda2 /mnt/root/boot
$ sudo mount /dev/sda1 /mnt/root/boot/efi
$ sudo mount --bind /dev /mnt/root/dev
$ sudo mount --bind /sys /mnt/root/sys
$ sudo mount --bind /proc /mnt/root/proc
$ sudo chroot /mnt

$ ls /lib/modules
6.0.7-301.fc37.x86_64
$ sudo kernel-install --verbose add 6.0.7-301.fc37.x86_64 /lib/modules/6.0.7-301.fc37.x86_64/vmlinuz
$ sudo grub2-mkconfig -o /etc/grub2.cfg
$ sudo ls /mnt/boot

The grub menu now shows a Fedora entry which has the following commands:

PXL_20221130_004924897.MP
PXL_20221130_004924897.MP2595Ă—1730 413 KB

Booting it shows the Fedora logo at the bottom but then it times out because the root drive cannot be found, because it does not even ask for a password to decrypt it. Any idea why it does not ask for a password?

3

I was able to boot by selecting the Fedora Rescue option. Then upgrading the system updated the kernel and the system now also boots from the normal Fedora non-Rescue option.

2 Likes
4

I guess encryption has nothing to do with the problem.