Dear GRUB mailing list,
Since a few Days I have a similar Problem which may have to with GRUB.
Using xubuntu: Starting xubuntu from the GRUB-list the initram starts
fine but ends with some loop steps and then results in a black screen.
regards
--
Dr. Heiko Pollmeier , Bonn <[email protected]>
Bevorzugter PGP-Schlüssel / Preferred PGP key ID 0x00695B1E
Am 21.03.2026 um 21:55 schrieb Yves Salathe:
Dear GRUB mailing list,
I'm running a Fedora 43 / Windows 11 dual boot system using GRUB2
(v2.12) on a Gigabyte B650 AORUS ELITE AX Rev 1.0 motherboard with an
AMD Ryzen 9 7950X3D (see more details in Appendix D). After updating the
BIOS from F38 (AMD AGESA 1.2.0.3g) to F40 (AMD AGESA 1.2.8.0) and later
F41a (AMD AGESA 1.3.0.0a), GRUB's chainloader no longer works for any
EFI binary. Selecting any chainloader-based GRUB menu entry results in a
silent black screen with no error message and no timeout. The system
hangs permanently until power-cycle. This affects:
- Windows Boot Manager (/EFI/Microsoft/Boot/bootmgfw.efi) - see Appendix A
- memtest86+ (/memtest86+x64.efi) - see Appendix B
In both cases GRUB successfully locates and loads the target binary (no
"file not found" or similar error), but execution never transfers. The
memtest86+ entry is a custom chainloader entry (Appendix B). Running the
commands manually from the GRUB command line works without error but
also hangs silently on 'boot'.
Boot Loader Specification (BLS) entries work correctly. The memtest86+
BLS entry boots fine, while an identical 40_custom chainloader entry for
the same binary hangs.
In contrast, Windows boots correctly when the EFI BootNext variable is
set from Linux before rebooting:
efibootmgr -n 0000 && systemctl reboot
This confirms the issue is not with the Windows bootloader itself.
Could this be a regression caused by the latest AGESA versions 1.2.8.0
and 1.3.0.0a that is specific to the chainloader hand off? I have seen
some reports about boot issues with AGESA 1.2.8.0, e.g. https://
www.techpowerup.com/343647/amd-agesa-v1-2-8-0-may-prevent-bios-entry-
and-crash-systems .
See Appendix C for my grub config. Disabling the gfxterm, theme, and
gfxmode configs made no difference.
I have also filed a bug report with Gigabyte. Given that the BLS boot
path works correctly while only the chainloader path is affected, I
suspect this may be a change in how AGESA 1.2.8.0+ handles EFI protocol
calls during application handoff — but I'm not sure whether a workaround
might be possible on the GRUB side. Is there anything further I can do
to narrow down the issue, or any GRUB-side workaround worth trying?
Thanks in advance for your help!
Best regards,
Yves
Appendix A: failing 30_os_prober entry
menuentry 'Windows Boot Manager (on /dev/nvme1n1p1)' --class windows --
class os $menuentry_id_option 'osprober-efi-E69D-D85A' {
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root E69D-D85A
chainloader /efi/Microsoft/Boot/bootmgfw.efi
}
Appendix B: Failing 40_custom entry
menuentry 'Memory Test (memtest86+)' --class memtest {
insmod part_gpt
insmod fat
insmod chain
search --no-floppy --fs-uuid --set=root 25AC-06B1
chainloader /memtest86+x64.efi
}
Appendix C: /etc/default/grub
GRUB_TIMEOUT=15
GRUB_TIMEOUT_STYLE=menu
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="gfxterm"
GRUB_CMDLINE_LINUX="rhgb quiet rd.driver.blacklist=nouveau,nova_core
modprobe.blacklist=nouveau,nova_core"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
GRUB_GFXMODE=auto
GRUB_THEME="/usr/share/grub/themes/Cyberpunk/theme.txt"
Appendix D: system configuration
- GRUB version: 2.12
- Fedora: 43 (kernel 6.19.8-200.fc43.x86_64)
- Motherboard: Gigabyte B650 AORUS ELITE AX Rev 1.0
- CPU: AMD Ryzen 9 7950X3D
- Memory: G.Skill Trident Z5 Neo F5-6000J3038F16G 2x16GB DDR5-6000
- Secure Boot: Enabled (Custom mode)
- CSM: Disabled
- Above 4G Decoding: Enabled
- Resizable BAR: Enabled
- Boot drives: 3x NVMe SSDs
