Talk: Install media don’t boot in UEFI mode on certain motherboards

This is a discussion topic for the following Common Issue:

You can discuss the problem and its solutions here, but please note that debugging and technical feedback should primarily go to the issue trackers (e.g. Bugzilla) linked in the Common Issue, because that’s the place that developers watch, not here.

If there are any updates/changes/amendments for the Common Issue description, which you believe should be performed, please post it here.

2 Likes

Thanks for sharing - my only note would be that, it seems quite possible this isn’t exclusively a Fedora issue - I also play around with Linux Mint some, and the last time I tried to install it I had a heck of a time because of issues related to the shim versions being used by upstream Ubuntu, it seemed.

On Mint, I ended up having to disable Secure Boot to get the installed OS to boot at all, even though the live image worked OK (sounds like almost the inverse of this issue?). On the same machine, though, Fedora 37 installed just fine. Maybe comes down to the different versions of shim-related things that would be in Debian/Ubuntu vs. Fedora?

Is there maybe some broader thing going on with Secure Boot as a whole? In the Bugzilla comments it’s noted that at least some component of a root cause fix for Fedora’s issue would depend on significant kernel changes…which would eventually impact all distributions, I’d think?

It probably impacts all distributions which use the same shim version.

@kparal Can you extend the instructions a bit? I found with the F38 Workstation live there isn’t enough space to replace BOOTX64.EFI. To make space, it’s safe to remove BOOTIA32.EFI and grubia32.efi - these are only needed on weird systems with 32-bit UEFI firmwares (none of which are affected by this bug, AFAIK).

@adamwill Done, please take a look if it seems OK.

Funny, I’ve been booting from the UEFI shell as a workaround and thought there was something wrong with my motherboard’s UEFI implementation (I’m way past due for an upgrade, but my computer has been working fine). Glad I’m not the only one facing this.

BOOTX64.EFI throws the same error if ran from the shell, but is able to “fall back to the default loader” and continue booting.

I had the F38 beta install media not boot for me, but this was on an older motherboard in the BIOS mode. I’d discussed it with folks on the Fedora IRC/Matrix channel but i was going away on leave and didn’t have the time to debug this further to file an issue. I’ll try it out again and file a bug.

I have tested to install with the changed BOOTX64.efi, but i get the message “sb.c:183:bad shim signature”.
Is there any other chance to boot Fedora 37 or 38 in UEFI mode?

Hello, in the guide related to the manual solution for this problem the url for the F36 shim package does not work anymore, so I found it from the archive

https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/36/Everything/x86_64/os/Packages/s/shim-x64-15.4-5.x86_64.rpm

I suggest to modify the link in the guide until the fix comes

@sgob Thanks a lot for your notification, I updated the link in the guide.

Use the following command to extract BOOTX64.EFI from the rpm.

rpm2cpio shim-x64-15.4-5.x86_64.rpm|cpio -idmv

System
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: GenuineIntel
Model name: Intel(R) Core™ i5-4430 CPU @ 3.00GHz

In my case the solution doesn’t work.

The content os ESP in fedora39-kde

❯ ll EFI/BOOT                                                                 
total 5.8M
-rwxr-xr-x. 1 root root 1.2K Nov  1 01:34 BOOT.conf
-rwxr-xr-x. 1 root root 925K Dec 20 08:24 BOOTX64.EFI
drwxr-xr-x. 2 root root 2.0K Nov  1 01:34 fonts
-rwxr-xr-x. 1 root root 1.2K Nov  1 01:34 grub.cfg
-rwxr-xr-x. 1 root root 3.4M Sep 13 00:00 grubx64.efi
-rwxr-xr-x. 1 root root 663K Jul  7  2022 mmia32.efi
-rwxr-xr-x. 1 root root 838K Jul  7  2022 mmx64.efi

The solution did worked when installed fedora38.

Update

I was using shim-x64-15.6-2.x86_64.rpm for fedora39-kde.

Now using the proposed in the post, the shim-x64-15.4-5.x86_64.rpm for fedora39-kde all worked fine.

packages shim-x64 web

I used Fedora Media Writer to get Fedora-KDE-Live-39-1-5 on a SanDisk Cruzer stick. I am unable to remove any files to make room for BOOTX64.EFI. It seems the file system is read only and nothing I have done (chmod and mount) will make it writable, and there is no physical switch. Any ideas on how to delete the unnecessary files to make room?

The device contains two partitions, and the second one should be writable if mounted. The first one as an iso file system and never writable.

1 Like

That is an iso image and cannot be altered. Just like any CD or DVD it is fixed in its structure.

Right, you have to mount and modify the EFI system partition, which is writeable.

Hi, folks. The Problem with some Motherboards are still there. Got an HP Z230 Workstation
and found this bug. Resolved it with VENTOY.
No prob by booting…

This is fixed in Fedora 40 Beta candidates 1.8 and later. :partying_face::partying_face::partying_face:

3 Likes

I appear to still have this problem when attempting to install Beta 1.10 using Fedora-Workstation-Live-x86_64-40_Beta-1.10.iso written to USB using Fedora Media Writer. Using Surface Pro 5 (some system details attached) with Secure Boot disabled. Confirmed that Fedora 36 works.

4 GB RAM is extremely small for running the newer fedora releases. My system uses about 8 GB when running as I normally do. The recommended hardware specs are bare minimum and do not account for extra apps the user may need to run nor for the growing gui overhead as time passes.

That image shows a total 4 GB physical RAM, a processor with 4 virtual CPUs (@ 1.0 GHz) , and mentions a virtual hypervisor. If you are trying to install into a VM with that hardware it may be impossible since the host OS would need to use some of the RAM just to run the hypervisor and thus the VM would have even less memory to use.