Bug 2451630 - System hangs when using grub2 themes after grub2 update [NEEDINFO]
Summary: System hangs when using grub2 themes after grub2 update
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 43
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Nicolas Frayer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-03-26 09:14 UTC by Andrea Santilli
Modified: 2026-05-27 22:38 UTC (History)
12 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:
lsandova: needinfo? (fedora)
lsandova: needinfo? (marcdeop)


Attachments (Terms of Use)

Description Andrea Santilli 2026-03-26 09:14:45 UTC
After updating grub2 from version 1:2.12-40.fc43 to 1:2.12-42.fc43 , grub2 suddenly stopped working and I got a blank screen with unresponsive keys.

My system configuration has both EFI and LUKS encryption enabled, but graphical themes turned out to be the culprit. Disabling them from a live system finally allowed grub2 to show its menu, even though the terminal mode is still gfx, as confirmed by the terminal_output command.

You can reproduce this by installing grub2-breeze-theme, enabling it in /etc/defaults/grub by setting GRUB_THEME appropriately and rebuilding the configuration. I get the same results with the grub themes from my copr repository (asan). 

Reproducible: Always

Steps to Reproduce:
1. install grub2 version 1:2.12-40.fc43
2. install some grub theme and enable it in the configuration 
3. make sure the theme works
4. update grub2 to version 1:2.12-42.fc43
5. system hangs at boot



Additional Information:
EFI and LUKS encryption are both enabled

Comment 1 Leo Sandoval 2026-03-27 17:24:34 UTC
(In reply to Andrea Santilli from comment #0)
> After updating grub2 from version 1:2.12-40.fc43 to 1:2.12-42.fc43 , grub2
> suddenly stopped working and I got a blank screen with unresponsive keys.
> 
> My system configuration has both EFI and LUKS encryption enabled, but
> graphical themes turned out to be the culprit. Disabling them from a live
> system finally allowed grub2 to show its menu, even though the terminal mode
> is still gfx, as confirmed by the terminal_output command.
> 
> You can reproduce this by installing grub2-breeze-theme, enabling it in
> /etc/defaults/grub by setting GRUB_THEME appropriately and rebuilding the
> configuration. I get the same results with the grub themes from my copr
> repository (asan). 
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. install grub2 version 1:2.12-40.fc43
> 2. install some grub theme and enable it in the configuration 

can you indicate the steps here? I am trying to reproduce it but somehow I am not able to reproduce it. I am on VM with graphics of course.

> 3. make sure the theme works
> 4. update grub2 to version 1:2.12-42.fc43
> 5. system hangs at boot


Can you enable debug logging through, e.g 

sudo grub2-editenv - set debug=all,-lexer,-scripting

then attach the log here?

> 
> 
> 
> Additional Information:
> EFI and LUKS encryption are both enabled

I do not think LUKS plays a factor here, first worth trying duplicating without LUKS.

Comment 2 Philippe L 2026-03-27 20:34:56 UTC
I believe the issue is when using a custom theme while secure boot is enabled. I had the same issue (with another theme), no problem with the theme installed and grub2 version 1:2.12-40, but the system wouldn't boot after the upgrade to version 1:2.12-42. Disabling secure boot fixed the issue.

This Reddit thread has a few other people who experienced the issue: https://www.reddit.com/r/Fedora/comments/1s2zjgj/secure_boot_broken/

Comment 3 Andy Bogle 2026-03-30 12:26:59 UTC
I've also reproduced this issue on a Dell Latitude 5300 dual-booting Windows 11 with Fedora 43 (Kernel 6.19.9-200.fc43.x86_64) and Secure Boot enabled. After a standard `sudo dnf update` and reboot, the system would not progress past the OEM boot logo and never reached the GRUB boot menu. Windows 11, however, remained bootable via the F12 Boot Menu. The issue appears specifically tied to the use of a graphical GRUB theme. I successfully recovered the system via a Live USB chroot by commenting out `GRUB_THEME` in `/etc/default/grub` and regenerating the grub configuration file using `grub2-mkconfig -o /boot/grub2/grub.cfg`. Disabling the theme allowed the standard text-based grub menu to appear and the system to boot normally.

Comment 4 Marta Lewandowska 2026-03-30 14:21:46 UTC
Hi, could someone please turn on verbosity in shim and debugging in grub and paste the output here? Or make a movie? Or somehow copy at least the last bits of output to the bug? We are unable to reproduce this on a VM.

$ sudo mokutil --set-verbosity true
$ sudo grub2-editenv - set debug=all,-lexer,-scripting

thank you!

Comment 5 Jason Tibbitts 2026-03-30 17:52:03 UTC
I think I'm hitting the same issue on a number of Intel NUC11 machines.  I have no custom theming installed as far as I know.  The machines just hang at boot with no display at boot.  I can get into the GRUB menu and look at things; interestingly, what should be the line characters to draw the box around the menu don't show up properly, as if the wrong font was loaded.  The machines boot if I disable secure boot in the BIOS.

Let me see if I can get useful debugging output.

Comment 6 Jason Tibbitts 2026-03-30 18:14:32 UTC
So after running mokutil and grub2-editenv as shown above, I stepped through the voluminous output and had to take a video to capture the last bits of output before the screen goes blank.  There really isn't much there.  Grub shows "Executed config file" and "Entering menu" and then (typed by hand from the video)

kern/verifiers.c:226:verify: string: setparams UEFI Firmware Settings, type: 2
commands/efi/tpm.c:281:tpm: log_event, pcr = 0, size = 0x20, grub_cmd: setparams UEFI Firmware
Settings
kern/verifiers.c:228:verify: string: fwsetup, type: 2
commands/efi/tpm.c:281:tpm: log_event, pcr = 0, size = 0x7, grub_cmd: fwsetup

and then the screen blanks and there is no further output.

Oddly, at this point after a while the machine enters the BIOS.  The behavior before I turned on debugging was just to hang.

I doubt that's actually useful, but there's such a volume of output that I'm not sure how to identify anything important.

Comment 7 Marta Lewandowska 2026-03-31 12:27:30 UTC
Thank you for that, Jason. :)

Comment 8 Andrea Santilli 2026-04-02 00:40:00 UTC
Hi, sorry for the delay. Unfortunately, I'm afraid I can't save all the verbose output that I get after setting mokutil options as shown above. Besides, the screen goes blank before I can even read the last lines. I guess this is not of much help.

Comment 9 Leo Sandoval 2026-04-06 17:47:35 UTC
(In reply to Jason Tibbitts from comment #6)
> So after running mokutil and grub2-editenv as shown above, I stepped through
> the voluminous output and had to take a video to capture the last bits of
> output before the screen goes blank.  There really isn't much there.  Grub
> shows "Executed config file" and "Entering menu" and then (typed by hand
> from the video)
> 
> kern/verifiers.c:226:verify: string: setparams UEFI Firmware Settings, type:
> 2
> commands/efi/tpm.c:281:tpm: log_event, pcr = 0, size = 0x20, grub_cmd:
> setparams UEFI Firmware
> Settings
> kern/verifiers.c:228:verify: string: fwsetup, type: 2
> commands/efi/tpm.c:281:tpm: log_event, pcr = 0, size = 0x7, grub_cmd: fwsetup
> 
> and then the screen blanks and there is no further output.
> 
> Oddly, at this point after a while the machine enters the BIOS.  The
> behavior before I turned on debugging was just to hang.

Apparently the `fwsetup` command is the one giving trouble and unfortunately the command has no grub prints (no debug output) and this is why we are not seeing anything once execution runs `fwsetup` and fails in the process. 

If possible, can you stop the execution and go into the GRUB shell, and from there type `fwsetup`? in theory this should hand and showing that this command is the possible culprit. Not sure if this is possible but better to ask.


> 
> I doubt that's actually useful, but there's such a volume of output that I'm
> not sure how to identify anything important.

yeah, it is pretty verbose, both shim and GRUB, but we are basically enabling all possible log except some parsing log which is just noise.

Comment 10 Leo Sandoval 2026-04-08 00:01:53 UTC
team,

I am suspecting that a recent change (and OOM fix) introduce on both f44 and f43 is impacting (somehow) the theme loading and possible another behavior related to unsigned kernels (see https://bugzilla.redhat.com/show_bug.cgi?id=2453022).

This is WIP so please share the log in case you have not.

Comment 11 Philippe L 2026-04-12 12:26:02 UTC
For what it's worth, the recent update to grub2 2.12-43.fc43 seems to have fixed things, grub loads correctly with secure boot enabled with or without a theme enabled for me.

Comment 12 Leo Sandoval 2026-04-13 16:34:52 UTC
(In reply to Philippe L from comment #11)
> For what it's worth, the recent update to grub2 2.12-43.fc43 seems to have
> fixed things, grub loads correctly with secure boot enabled with or without
> a theme enabled for me.

thanks for the testing Philippe, I am glad that we are back to normal.

My action item is to investigate why such an 'unrelated change', requesting memory from EFI pages instead of GRUB's memory pool is impacting this area.

Comment 13 Leo Sandoval 2026-04-13 16:45:10 UTC
Marc, any idea about this issue? 

GRUB has reverted the below changes (f44, f43) and allow GRUB + GRUB Theme + SB to boot fine again


https://src.fedoraproject.org/rpms/grub2/pull-request/215
https://src.fedoraproject.org/rpms/grub2/pull-request/214

Comment 14 Leo Sandoval 2026-05-27 22:38:08 UTC
I am back to debugging the OOM fix + SB + grub theme.

I launched two VM, rawhide and f44, with the latter configuration and none of them has the issue. As mentioned, this is VM and not baremetal. I will proceed to test it on baremetal.

In the meanwhile, can someone (I hope more than one participant) try to reproduce the issue on latest rawhide, e.g https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/Fedora-Workstation-Live-Rawhide-20260526.n.0.x86_64.iso  ? rawhide still has the OOM fix so my assumption is that we would see the problem but it has not being the case, at least on virtual environments.


Note You need to log in before you can comment on or make changes to this bug.