I use a LUKS1-encrypted /boot partition. As expected, GRUB prompts for the LUKS password to unlock /boot, and I can then successfully boot. However, if I press [e] to edit a GRUB entry, I'm prompted again to enter the LUKS password for the /boot partition. This behavior is new in Fedora 42. Downgrading the grub2* packages to the ones from Fedora 41 (2.12-20.fc41) brings back the old behavior (no need to enter the password again when editing a GRUB entry because the /boot partition is already unlocked at this time). Reproducible: Always Steps to Reproduce: 1. Install Fedora 42 Server on a UEFI host with GPT partitioning. Use automatic partitioning. No need to encrypt anything during the setup to keep the reproducer simple. 2. After the installation use the following commands to encrypt /boot and adjust the GRUB configuration accordingly (vda2 is /boot): dnf -y update grub2* umount /boot/efi/ cp /boot/ /boot.bak -rp umount /boot cryptsetup luksFormat /dev/vda2 --type luks1 # interactive command cryptsetup luksOpen /dev/vda2 crypt_boot # interactive command mkfs.xfs /dev/mapper/crypt_boot mount /dev/mapper/crypt_boot /boot rm /boot/lost+found/ -rf mv /boot.bak/* /boot/ mv /boot.bak/.vmlinuz* /boot/ mount /boot/efi/ restorecon -Rv /boot/ rm /boot.bak/ -rf sed -i -e 's/^UUID=.*\( \/boot \)/UUID='$(blkid -s UUID -o value /dev/mapper/crypt_boot)'\1/' /etc/fstab # Update UUID for /boot in fstab echo "luks-$(blkid -s UUID -o value /dev/vda2) UUID=$(blkid -s UUID -o value /dev/vda2) none discard" >> /etc/crypttab # Add cryptab entry for vda2 (/boot) echo GRUB_ENABLE_CRYPTODISK=y >> /etc/default/grub dracut -vf --regenerate-all grub2-mkconfig > /boot/grub2/grub.cfg dnf -y reinstall grub2-efi-x64 grub2-tools-extra shim-x64 sed -i 's/^search.*$/insmod cryptodisk\ninsmod luks\ncryptomount -u '$(blkid -s UUID -o value /dev/vda2|sed -e 's/-//g')'\nsearch --no-floppy --fs-uuid --set=dev '$(blkid -s UUID -o value /dev/mapper/crypt_boot)'\n/' /boot/efi/EFI/fedora/grub.cfg # Update /boot UUID, unlock LUKS /boot before loading /boot/grub2/grub.cfg 3. Reboot 4. Enter the LUKS password for /boot. 5. As soon as the GRUB menu appears, press [e] to edit an entry. Actual Results: GRUB prompts again for the LUKS password of the /boot partition, even if it was already unlocked before (otherwise, the GRUB menu wouldn't be visible) Expected Results: GRUB should not prompt again for the LUKS password when a user wants to edit a menu entry because the /boot partition was already unlocked before. * In Fedora 41 and earlier, GRUB never prompted for the LUKS password again when I wanted to edit an entry. * I compared /boot/grub2/grub.cfg and /boot/efi/EFI/fedora/grub.cfg from Fedora 41 and 42. They are the same (only different UUIDs, of course). * Manually downgrading the grub2* packages on Fedora 42 to the packages from Fedora 41 (2.12-20.fc41) brings back the old behavior.
The problem now also exists on an up-to-date Fedora 41 (with GRUB 2.12-21). It seems that one of the recent GRUB updates introduced this problem. If the user already entered the password and the partition was successfully encrypted, then there's no need to prompt for the LUKS password again when the user wants to edit the GRUB entry.
Hi, you may be hitting (I have not verified) a stricter LUKS authentication introduced recently on f42 (starting at 2.12-24) [1,2] and f41 (starting at 2.12-18), so this is expected. [1] https://src.fedoraproject.org/rpms/grub2/c/9002ed87b0e756461f08a85881dd6a791636bc1e?branch=f42 [2] https://src.fedoraproject.org/rpms/grub2/blob/9002ed87b0e756461f08a85881dd6a791636bc1e/f/0312-disk-cryptodisk-Require-authentication-after-TPM-unl.patch
Thanks for the info. This could be the cause. I'm not saying that the patch should be reverted (especially if it adds security), but the need to unlock the same partition twice seem to be a bug caused by this patch. If I have already manually entered the LUKS passwort for the /boot partition so that GRUB can display the menu, I see no sense if GRUB prompts me again to unlock /boot if I press [e] to edit one of the entries.
Agree Marc, it makes no sense to unlock the same partition twice. Feel free to propose a solution on the grub's upstream mailing list if possible.
I reported the bug in the upstream bug tracker: https://savannah.gnu.org/bugs/index.php?67063
I compiled GRUB from upstream git master. With this version, the bug is not reproducable. It seems to be bug either in 2.12 or it is Fedora specific. ---- Just for reference, this is how I replaced GRUB on Fedora 42 with the self-compiled one from upstream: dnf update dnf group install development-tools dnf install autoconf automake texinfo bison flex freetype-devel ncurses-devel gettext-devel cryptsetup-devel dnf builddep grub2 rm /etc/dnf/protected.d/{grub,shim}* dnf remove grub2* git clone https://git.savannah.gnu.org/git/grub.git cd grub ./bootstrap ./configure --prefix=/opt/grub --with-platform=efi --target=x86_64 make CFLAGS="-Wno-error" make install cp /opt/grub/lib/grub/x86_64-efi/* /boot/efi/EFI/fedora/ cp /opt/grub/sbin/grub-mkconfig /usr/sbin/ cp /opt/grub/sbin/grub-install /usr/sbin/ mkdir /opt/grub/etc/default/ ln -s /etc/default/grub /opt/grub/etc/default/ grub-install --efi-directory=/boot/efi --bootloader-id=GRUB-UPSTREAM --boot-directory=/boot grub-mkconfig -o /boot/grub/grub.cfg Once I reboot, it shows "2.13" in the GRUB menu, so I assume the procedure works, and I really use the version from upstream git master.