Bug 1631989 - x86_64 UEFI installs of Fedora 26 or earlier stop booting when upgraded to Fedora 29 (shim-15-5) due to move of 'shim.efi' from shim-x64 to shim-ia32
Summary: x86_64 UEFI installs of Fedora 26 or earlier stop booting when upgraded to Fe...
Alias: None
Product: Fedora
Classification: Fedora
Component: shim
Version: 29
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
: 1626862 1634386 (view as bug list)
Depends On:
Blocks: F29FinalBlocker
TreeView+ depends on / blocked
Reported: 2018-09-22 23:08 UTC by Jon Burgess
Modified: 2018-10-29 11:14 UTC (History)
9 users (show)

Fixed In Version: shim-15-6 shim-15-7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-10-03 14:28:01 UTC

Attachments (Terms of Use)

Description Jon Burgess 2018-09-22 23:08:06 UTC
Description of problem:

After upgrading my dual-boot laptop from F28 to F29 the system would boot directly into Windows with no option for Fedora. The existing EFI boot entry referenced shim.efi but that file had been removed.

Version-Release number of selected component (if applicable):


How reproducible:
Have not attempted to go back to f28

Steps to Reproduce:
1. Laptop was originally installed with Win10. Boots from EFI with secure boot enabled
2. F24 was installed
3. Upgraded to F25, F26, F27 & F28 successfully
4. Upgraded to F29 beta 1.5 using dnf system-upgrade and machine would boot to Windows only

Actual results:

The problem seems to be that the original EFI boot entry references shim.efi but this was no longer present:

# efibootmgr -v
BootCurrent: 0005
Timeout: 1 seconds
BootOrder: 0002,0000,0005
Boot0000* Windows Boot Manager  HD(1,GPT,799a5b3a-028f-46e8-8f75-de9894c365d0,0x800,0x82000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.}...eF...............
Boot0002* Fedora        HD(1,GPT,799a5b3a-028f-46e8-8f75-de9894c365d0,0x800,0x82000)/File(\EFI\FEDORA\SHIM.EFI)
Boot0005* UEFI: JetFlashTranscend 16GB 1.00, Partition 1        PciRoot(0x0)/Pci(0x14,0x0)/USB(12,0)/HD(1,MBR,0x1fe7b8c,0xc4,0x4de8)..BO

The files in /boot/efi/EFI/fedora/ were:


Expected results:

Either the system should have installed shim-ia32 (which made things work with the original EFI boot entry). Or perhaps it should have added/replaced the boot entry with one referencing shimx64.efi.

Additional info:

I booted from USB and added a boot entry telling the system to boot the shimx64.efi file which worked: efibootmgr -c -l /efi/fedora/shimx64.efi

I then discovered that shim-ia32 included the missing shim.efi and installing that package allowed the original boot entry to work.

The DNF history shows the following upgrade path for the 'shim' related packages:

[jburgess@zen ~]$ sudo dnf history info shim | grep shim
Command Line   : install /boot/efi/EFI/fedora/shim.efi
    Install shim-ia32-15-5.x86_64                    @fedora
    Upgrade    shim-x64-15-5.x86_64                  @fedora
    Upgraded   shim-x64-15-2.x86_64                                               
    Install    shim-x64-13-0.7.x86_64                @fedora
    Obsoleted  shim-0.8-10.x86_64                    @@commandline
    Upgrade    shim-0.8-10.x86_64                    @@commandline
    Upgraded   shim-0.8-9.x86_64                     @koji-override-0
    Install shim-0.8-9.x86_64                        @koji-override-0

I guess that originally shim provided shim.efi. The F28 version of shim-x64-15-2 also provided shim.efi. It was the upgrade to shim-x64-15-5 that looks like it removed shim.efi and caused the system to stop booting.

Comment 1 Ryan 2018-09-25 21:25:58 UTC
Also effected me, and I also have not attempted to revert and reinstall. I have nothing else to add other than:

I merely changed my boot path to the shim64-fedora.efi, and did not reinstall shim32.

$ sudo dnf history info shim | grep shim
    Upgrade    shim-x64-15-5.x86_64        @fedora
    Upgraded   shim-x64-15-2.x86_64                                            
    Install    shim-x64-13-0.7.x86_64      @fedora
    Obsoleted  shim-0.8-10.x86_64          @fedora

Command Line   : install grub2-efi grub2-efi-modules shim
Command Line   : reinstall grub2-efi grub2-efi-modules shim

    Reinstall shim-0.8-10.x86_64           @fedora
    Reinstall shim-0.8-10.x86_64           @anaconda
    Install shim-0.8-10.x86_64             @anaconda

Comment 2 sgiurgiu11 2018-09-26 12:37:15 UTC
Chiming in as another victim of this bug. Simply installing shim-ia32 allowed the grub menu to show up, however none of the Linux entries were able to boot. The windows entry in the grub menu boots just fine.
This may or may not be related with the shim (shim may be 32 bit and the kernels are x64)?

Have not yet attempted to replace the efi entry with shimx64.efi as suggested here, this will be my next step.

Comment 3 Tim Cuthbertson 2018-09-29 22:06:36 UTC
I just had the exact same problem after "dnf system-upgrade" to Fedora 29 Beta.

May I ask how people are fixing these things on systems that will not boot? Are you booting a live image and chroot'ing? I am a little confused.

Comment 4 Tim Cuthbertson 2018-09-29 23:15:12 UTC
I worked around the problem by reinstalling packages grub2-efi  and shim. Then I rebuilt grub.cfg. My system now boots, normally.

The bug should still be fixed, though.

Comment 5 Adam Williamson 2018-10-02 15:49:52 UTC
*** Bug 1634386 has been marked as a duplicate of this bug. ***

Comment 6 Adam Williamson 2018-10-02 16:02:33 UTC
OK, so a bit more info here.

It seems indeed that `shim.efi` moved from shim-x64 to shim-ia32 along the way. Fedora 28's current shim package is shim-signed-15-2:


in that build, `shim.efi` is in the shim-x64 subpackage, not shim-ia32.

Fedora 29 and Rawhide's current shim package is shim-15-5:


in that build, `shim.efi` is in shim-ia32, not shim-x64.

Back in Fedora 27, the changes were made to enable 32-on-64 UEFI. Before this change:


for UEFI installs, anaconda would install the package 'shim', and write an EFI boot manager entry that pointed to 'shim.efi'. After that change, it explicitly installs either 'shim-x64' or 'shim-ia32' and writes a boot manager entry that points to 'shimx64.efi' or 'shimia32.efi' (as appropriate).

Over in the shim source packages, the new 'shim-x64' binary package was set to obsolete and replace the old 'shim' binary package.

So if you installed Fedora 26 or earlier on UEFI then upgraded, you now have the 'shim-x64' package installed (but not shim-ia32), and an EFI boot manager entry that points to 'shim.efi'. That worked for F27 and F28, because 'shim.efi' was in shim-x64...but when you upgrade to F29, it breaks, because 'shim.efi' moved to shim-ia32, which you do not have installed.

pjones, given all the above, it seems wrong that 'shim.efi' was moved to shim-ia32. Was that intentional? If not, can it be reverted? If it was, can you think of something to address this problem for those upgrading from <F27? Thanks!

Comment 7 Fedora Update System 2018-10-02 18:12:29 UTC
shim-15-7 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-12bb418c63

Comment 8 František Zatloukal 2018-10-02 19:32:31 UTC
*** Bug 1626862 has been marked as a duplicate of this bug. ***

Comment 9 Fedora Update System 2018-10-02 21:18:57 UTC
shim-15-7 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-12bb418c63

Comment 10 František Zatloukal 2018-10-03 07:21:42 UTC
Multiple people (including me) indicated that the https://bodhi.fedoraproject.org/updates/FEDORA-2018-12bb418c63 fixes the issue.

Marking as VERIFIED.

Comment 11 Fedora Update System 2018-10-03 14:28:01 UTC
shim-15-7 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

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