-
Bug
-
Resolution: Done
-
Minor
-
None
-
CentOS Stream 9
-
None
-
No
-
Moderate
-
rhel-bootloader
-
13
-
False
-
False
-
-
None
-
None
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
None
What were you trying to do that didn't work?
Kickstart a new UEFI-based CentOS 9 System, booting normally for first time
What is the impact of this issue to you?
New c9s systems are unbootable after kickstart. I have to revert shim package to shim-x64-15-15.el8_2.x86_64.rpm or enter the UEFI shell and launching grubx64.efi by hand
Please provide the package NVR for which the bug is seen:
shim-x64-15.8-2.el9.x86_64
How reproducible is this bug?:
I have two Supermicro A1SRi / Intel Atom systems I can reliably reproduce this on. Secure Boot is not enabled, systems do not have TPMs
Steps to reproduce
- Install c9s, which brings in the shim-x64-15.8-2.el9.x86_64 package
- Reboot
- Let system attempt to boot or go into UEFI shell and run fs0:\EFI\centos\shimx64.efi directly
- System locks up, often require power reset
Expected results
Expect shim to load grub, and then load the kernel and boot normally.
Actual results
System locks up as soon as shimx64.efi, shim.efi, or shimx64-centos.efi are run
fs0:\EFI\centos> dir
Directory of: fs0:\EFI\centos
09/22/25 10:47p <DIR> 4,096 .
09/22/25 10:47p <DIR> 4,096 ..
08/19/25 07:53a 856,552 mmx64.efi
08/19/25 07:53a 947,880 shim.efi
08/19/25 07:53a 949,456 shimx64-centos.efi
08/19/25 07:53a 947,880 shimx64.efi
08/19/25 07:53a 108 BOOTX64.CSV
09/22/25 10:58p 144 grub.cfg
09/09/25 05:31p 2,565,672 grubx64.efi
7 File(s) 6,267,692 bytes
2 Dir(s)
fs0:\EFI\centos> shimx64.efi
...no more output...
If I'm in the UEFI shell I can skip shim and run grubx64.efi directly and this boots the system just fine. mmx64.efi works too, but all shim binaries lock up the system.
If I downgrade to shim-x64-15-15.el8_2.x86_64.rpm the system boots normally without any problems.