Bug 2353335

Summary:	GRUB prompts for LUKS password again when trying to edit a GRUB entry
Product:	[Fedora] Fedora	Reporter:	Marc Muehlfeld <mmuehlfe>
Component:	grub2	Assignee:	Nicolas Frayer <nfrayer>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	44	CC:	lkundrak, lsandova, mlewando, nfrayer, pjones
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marc Muehlfeld 2025-03-19 09:59:05 UTC

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.

Comment 1 Marc Muehlfeld 2025-04-09 07:43:32 UTC

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.

Comment 2 Leo Sandoval 2025-04-09 17:59:07 UTC

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

Comment 3 Marc Muehlfeld 2025-04-10 07:33:27 UTC

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.

Comment 4 Leo Sandoval 2025-04-10 15:45:36 UTC

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.

Comment 5 Marc Muehlfeld 2025-05-01 13:48:21 UTC

I reported the bug in the upstream bug tracker: https://savannah.gnu.org/bugs/index.php?67063

Comment 6 Marc Muehlfeld 2025-05-02 08:53:59 UTC

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.

Comment 7 Fedora Release Engineering 2026-05-06 12:29:29 UTC

This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '42'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 42 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 8 Marc Muehlfeld 2026-05-07 12:55:36 UTC

The problem still exists with GRUB 2.12-56 on Fedora 44.

Comment 9 Leo Sandoval 2026-05-07 17:02:24 UTC

(In reply to Marc Muehlfeld from comment #8)
> The problem still exists with GRUB 2.12-56 on Fedora 44.

Sorry for the delay Marc.

As you may know, GRUB upstream has moved to [1]. Can you file a issue there [2]? Also, there was recently a commit (partially related) [3]. 
On gitlab, one gets much better traction than savannah, so reporting in [2] is important.


[1] https://gitlab.freedesktop.org/gnu-grub/grub
[2] https://gitlab.freedesktop.org/gnu-grub/grub/-/work_items
[3] https://gitlab.freedesktop.org/gnu-grub/grub/-/commit/6f59551489783b717470f3acb147b704c9559e2b

Comment 10 Marc Muehlfeld 2026-05-08 06:17:43 UTC

I reported the problem upstream last year (see #c5) and was told to try if it's reproducible in master. It worked in master (see #c6).
So my guess was that it's a bug only in 2.12.x or is Fedora specific.

Should I again report it upstream?

I can set up a VM an try to reproduce it with the latest 2.14 branch if you want. Are there any plans to switch to 2.14 in Fedora 44? It's available since some months.

Comment 11 Marc Muehlfeld 2026-05-08 07:29:11 UTC

I re-used the procedure from #c6. I cloned the repo from GitLab, checked out the grub-2.14 tag from January, and built GRUB. The bug doesn't is not present in upstream 2.14.

Comment 15 Leo Sandoval 2026-05-08 18:06:02 UTC

(In reply to Marc Muehlfeld from comment #10)
> I reported the problem upstream last year (see #c5) and was told to try if
> it's reproducible in master. It worked in master (see #c6).
> So my guess was that it's a bug only in 2.12.x or is Fedora specific.
> 
> Should I again report it upstream?

no need as upstream has no issues.

> 
> I can set up a VM an try to reproduce it with the latest 2.14 branch if you
> want.

no need

> Are there any plans to switch to 2.14 in Fedora 44? It's available
> since some months.

yes, there are plans. Our plan is to start this summer (2026) this summer.