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: | 42 | 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
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.
|