Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1938630 - include new bootloaders on Fedora 34 install media so UEFI Secure Boot enabled systems can boot from them
Summary: include new bootloaders on Fedora 34 install media so UEFI Secure Boot enable...
Alias: None
Product: Fedora
Classification: Fedora
Component: shim
Version: 34
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On: 1784546 1784548
Blocks: F34FinalBlocker
TreeView+ depends on / blocked
Reported: 2021-03-15 01:58 UTC by Chris Murphy
Modified: 2021-04-28 13:08 UTC (History)
18 users (show)

Fixed In Version: shim-15.4-4
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-04-23 21:03:28 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github rhboot shim pull 362 0 None open Don't set user_insecure_mode and ignore_db in import_one_mok_state 2021-04-09 17:25:03 UTC

Description Chris Murphy 2021-03-15 01:58:20 UTC
Short summary: As part of UEFI Secure Boot support, Fedora must include newly signed versions of the bootloader binaries (shim and grub) on Fedora 34 installation media and images so that UEFI Secure Boot enabled systems can boot the installation media and images themselves.

Current bootloaders: shim 15, grub2 2.04
New bootloaders: shim 15.3, grub2 2.06

Detail: the current shim was signed in 2018 and its signing key was revoked last year due to the Boothole vulnerability. Wide scale delivery of the revocation file (dbx) by Windows Update, and likely some Linux distros, has been postponed but is expected to happen in Q2/Q3 2021. This will render shim unloadable on UEFI Secure Boot enabled systems with a recent dbx (revocation file), and means those systems won't boot current Fedora installation media at all. Fedora's shim 15.3 and GRUB 2.06 have fixes and enhancements, including a new SBAT generation based revocation regime needed to address the limitations of dbx based revocation.

Essentially three things are needed at once: security fixes and enhancements for both shim and grub, and they need to be signed with new keys.

The new versions are expected to land in Rawhide and Fedora 34 updates-testing this week.


Replaces bug 1883609.

SBAT, generation based revocation

Comment 1 Fedora Blocker Bugs Application 2021-03-15 02:04:37 UTC
Proposed as a Blocker for 34-final by Fedora user chrismurphy using the blocker tracking app because:

 Basic: All release-blocking images must boot in their supported configurations. UEFI Secure Boot is an explicitly supported firmware type/mode.

Final: Shim and GRUB are Critical Path packages used on install media and needed for booting the install media when UEFI Secure Boot is enabled. The problem cannot be fixed with an update, we need it on media in order to boot from it. And the problem/bug severity is high.

Comment 2 Adam Williamson 2021-03-15 16:08:01 UTC
+3 in , marking accepted.

Comment 3 Adam Williamson 2021-03-27 01:00:23 UTC
Peter - where are we with this? This is an accepted F34 Final blocker, and Final freeze is coming up April 6. I'd like us to be out in front of accepted blockers at this point. Thanks!

Comment 4 Fedora Update System 2021-04-06 19:47:45 UTC
FEDORA-2021-cab258a413 has been submitted as an update to Fedora 34.

Comment 5 Fedora Update System 2021-04-06 19:47:50 UTC
FEDORA-2021-f5540ef3d6 has been submitted as an update to Fedora 32.

Comment 6 Chris Murphy 2021-04-07 17:54:58 UTC
Availablity of updated shim answers needinfo I think :)

Comment 7 Fedora Update System 2021-04-07 18:15:53 UTC
FEDORA-2021-cab258a413 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-cab258a413`
You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 8 Ben Cotton 2021-04-09 17:25:06 UTC
New shim fails to boot with SecureBoot enabled, at least on some hardware:

Adam has a potential fix upstream:

Setting status to POST.

Comment 9 Adam Williamson 2021-04-09 18:42:44 UTC
So in testing, I discovered a bug in this version of shim:

The known practical effect of the bug is that if Secure Boot is enabled at the firmware level but signature validation is disabled at the mok level, the system will not boot. With the previous shim build it displayed the message "Booting in insecure mode" for two seconds, then booted; with this version of shim it shows "Bootloader has not verified loaded image. System is compromised.  halting." and shuts down.

The bug also affects another case (the "MokDBState" variable), but I don't know what the practical consequence of that variable not being respected is. If anyone does, it would be useful to know.

According to Javier, Dell "Sputnik" (developer edition) laptops ship in the affected state from the factory. That is indeed exactly the laptop I have. So we can at least say, AIUI: any Fedora UEFI install on a Dell developer edition laptop with default factory configuration will stop booting after installing this update. Also, I believe, UEFI booting install media built with this version of shim on Dell developer edition laptops with default factory configuration will fail.

We don't know what (if any) other systems shipped in this state, how many (if any) other people are likely to have got into it manually (though I'd guess that number would be small).

pjones is working on a build of shim with the bug fixed "right now". It will then have to go through the SB signing process, which takes a few days I believe. I think if that all goes smoothly we should be able to pull in the fixed build without delaying the release, but if not, we may have to make a decision whether this bug is significant enough to delay the release for, or whether we should just accept it and release with it broken.

Comment 10 Adam Williamson 2021-04-13 00:59:27 UTC
OK, update on status here: after I found that bug, cmurf found two others, one that breaks boot on early Intel Macs (with initial EFI, not UEFI, firmware) and one that caused an apparently non-fatal message on boot of some other systems.

There is now an unsigned build which is tested to fix these bugs:

we would need a signed build to include in the release, however. pjones, is there an update on what build(s) is/are in for signing, and what the expected turnaround time will be?

Note there is also a single boot failure with SB enabled reported in the Test Day results, by geraldosimiao:
but we have no details as yet on what went wrong.

Comment 11 nh 2021-04-20 17:17:14 UTC
Fedora 34 Workstation Beta 1.3 also fails to boot with secure boot enabled on Thinkpad X1 Carbon Gen 9 with BIOS version 1.23.

Comment 12 Adam Williamson 2021-04-20 17:42:56 UTC
nh: can you please test with a recent nightly? Beta does not have the newer build under discussion here, it has the same one as F33 (IIRC). You can get the current nightly at . thanks!

Comment 13 nh 2021-04-20 18:25:36 UTC
 Adam Williamson: Same problem: fails to boot with secure boot enabled.

Comment 14 Chris Murphy 2021-04-20 19:00:31 UTC
Can you try either of these images?

Those are the only two right now that have shim-15.4 on it.

Another possibility is that there's a grub 2.06 bug that nh's Thinkpad X1 is running into. Does that computer boot a Fedora 33 ISO?

Comment 15 nh 2021-04-20 19:13:16 UTC
Chris Murphy:

- I'll try and report (Downloading now).

- Same problem with Fedora 33 iso: fails to boot with secure boot enabled;

Sidenote: all of the tried iso's boot / install fine without secure boot.

Comment 16 nh 2021-04-20 19:30:17 UTC
Chris Murphy: of the two iso's in the provided link, I tried the Workstation one:
- It boots flawlessly!

The output of "mokutil --sb-state" is: "SecureBoot enabled".

Thanks a lot for all your work!

If needed I'll be willing to test other things tomorrow from 20:00 UTC.

Comment 17 Adam Williamson 2021-04-20 21:16:52 UTC
welp, that's another reason we need the fixed shim, I guess...thanks for the info.

Comment 18 Fedora Update System 2021-04-21 11:20:25 UTC
FEDORA-2021-cab258a413 has been submitted as an update to Fedora 34.

Comment 19 Peter Robinson 2021-04-21 11:25:40 UTC
Clearing needinfo as we now have a new signed build in bodhi

Comment 20 Fedora Update System 2021-04-21 15:00:55 UTC
FEDORA-2021-cab258a413 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-cab258a413`
You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 21 Adam Williamson 2021-04-23 17:11:11 UTC
I did check the fix for my Dell issue, and cmurf confirmed the fix for his Intel Mac issue, and so far as the bug description goes, new bootloaders certainly are in RC2.

Comment 22 Fedora Update System 2021-04-23 21:03:28 UTC
FEDORA-2021-cab258a413 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 23 Andreas 2021-04-28 13:08:03 UTC
I still have this issue Dell Precession 7530 Developer Edition.

Security Boot on - black screen without errors
Security Boot off - "The Matrix" screen

Version-Release number of selected component (if applicable):
I tested
Fedora 34 Release
Fedora 34 RC 1.1
Fedora 34 RC 1.2
Fedora 34 nightly from 24.04
Fedora 34 Beta with updated shim to 15.4-4

This shim versions does not boot
shim 15.4-3
shim 15.4-4

Steps to Reproduce:
1. Boot Fedora 34 from USB or installed system
2. Update shim 15.8 to 15.4-4 on Fedora 34 Beta 1.3

Actual results:
By default, the system boots with \EFI\fedora\shimx64.efi. In Bios i can create Boot Option with \EFI\fedora\grubx64.efi and Fedora boot from USB Live or SSD.

I opened a new bug report because I didn't know what to write here.

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