Bug 1698550 - Fedora install media error out with SecureBoot or Grub error in UEFI-only mode on T450s
Summary: Fedora install media error out with SecureBoot or Grub error in UEFI-only mod...
Alias: None
Product: Fedora
Classification: Fedora
Component: shim
Version: 30
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Matthew Garrett
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On:
Blocks: F30FinalFreezeException
TreeView+ depends on / blocked
Reported: 2019-04-10 15:17 UTC by Kamil Páral
Modified: 2020-05-26 17:07 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-05-26 17:07:37 UTC
Type: Bug

Attachments (Terms of Use)
SecureBoot error (135.29 KB, image/jpeg)
2019-04-10 15:18 UTC, Kamil Páral
no flags Details
GRUB error (54.22 KB, image/jpeg)
2019-04-10 15:19 UTC, Kamil Páral
no flags Details
efivars-1.35-sb-on (835 bytes, application/zip)
2019-04-12 06:54 UTC, Kamil Páral
no flags Details
efivars-1.35-sb-off-csm-off (833 bytes, application/zip)
2019-04-12 06:55 UTC, Kamil Páral
no flags Details
all-efivars-1.35-sb-off-csm-off (9.04 KB, text/plain)
2019-04-12 06:57 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2019-04-10 15:17:38 UTC
Description of problem:
On my Thinkpad T450s laptop, Fedora 30 install media don't start into the boot menu (syslinux?), if you have set your laptop to UEFI-only mode (CSM disabled).

If I have Secure Boot enabled (which implies CSM disabled), I see an error message (see attachment):
> Image failed to verify with *ACCESS DENIED*.
> Press any key to continue.
(and reboots)

If I have Secure Boot disabled, and CSM disabled, I see this (see attachment):
> error: ../../grub-core/kern/fs.c:120:unknown filesystem.
> Entering rescue mode...
> grub rescue>
(I don't know whether this is a separate bug, not related to the error above).

Only if I disable Secure Boot, and enable CSM, only then I can display the install image boot menu in UEFI mode.

I tried F29 install media as well, and it exhibits the same problem:
* Fails to verify with SB on.
* With SB off and CSM off, I see just a black screen (I assume the grub error is the same, but it doesn't show up).

With F28 install media, there's a difference:
* Again fails to verify with SB on.
* Boots completely fine with SB off and CSM off, unlike F29 and F30.

Please note that this seems to affect only install media, and not installed systems. I have F29 installed on the laptop, and it works without problems with SB on, or with SB off and CSM off. (The system got installed as F28 and upgraded to F29 though, so it's possible some boot bits were set up with F28 code and then never touched again, I don't know how that works).

Overall, it's possible to boot Fedora install media on the system, but the user has to jump through multiple hoops and must know what they're doing. Furthermore, the problem has regressed in recent Fedoras, implying this isn't (at least entirely) a firmware issue.

I have also tested Thinkpad T480s and this problem is not present in there (both SB on, or SB off and CSM off show the boot menu just fine). I have only seen this with T450s.

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

How reproducible:

Steps to Reproduce:
1. put some install media on a USB stick (I tested Workstation Live and Everything netinst)
2. try to boot up from the stick, see an error message depending on firmware configuration (either SB on, or SB off and CSM off)

Comment 1 Kamil Páral 2019-04-10 15:18:22 UTC
Created attachment 1554269 [details]
SecureBoot error

SB error when SB is enabled

Comment 2 Kamil Páral 2019-04-10 15:19:00 UTC
Created attachment 1554270 [details]
GRUB error

GRUB error when SB is disabled and CSM is also disabled

Comment 3 Kamil Páral 2019-04-10 15:24:34 UTC
I'm proposing this for consideration as a blocker bug. The fact that a machine can't boot into an install image boot menu is pretty serious. Yes, there's an non-obvious workaround, and yes, this definitely affects only some hardware (asking the community to test this on wide selection of hardware is probably a good idea). It has been present in F29, and partly in F28 (regressed from that state).

Comment 4 Adam Williamson 2019-04-10 15:42:57 UTC
'shim' component is a trap...

if this affects at least a few different Thinkpads, I'm inclined to +1 blocker on it. Secure Boot is a thing we ideally want to encourage people to use, turning it off is a bad workaround.

Comment 5 Chris Murphy 2019-04-10 18:41:43 UTC
It might be useful to see contents of efivars. Boot UEFI mode however possible and

$ ls -l /sys/firmware/efi/efivars/

Also, is the firmware for this T450s at 1.35 or other?

Comment 6 Peter Jones 2019-04-10 20:17:04 UTC
I've tried to reproduce this with shim-15-8 and grub2-efi-x64-2.02-75.fc30 with the following setups:

- SB unsupported
- SB supported but disabled
- SB supported and enabled

I can't get any of these symptoms to occur at all, so I suspect something is wrong with the firmware setup on the machine (no idea about the filesystem problem.)

Can you get attach of the following UEFI files from /sys/firmware/efi/efivars:


(Some may not be present.)

Comment 7 Kamil Páral 2019-04-12 06:52:22 UTC
Alright, so, I had 1.34 bios installed, even though it's supported by fwupdmgr and it didn't show any updates available. Lenovo obviously haven't uploaded the latest bios to LVFS (so most Linux users are probably still running 1.34). After updating to 1.35 manually, things have completely changed (even though the changelog only lists one security fix):

* The SecureBoot=on path now boots OK.
* The SecureBoot=off and CSM=off path still doesn't boot, but the grub filesystem error is gone. I only see a black screen and nothing happens (so effectively the same thing I originally saw with F29 media). The installed system can still be booted just fine with these firmware settings.

I'll attach the efivars requested, but only these 3 out of those mentioned are available:

They differ between the cases, so I upload them in both versions. They are from 1.35 bios, but I also have them saved from 1.34 bios, if you want to debug that.

Comment 8 Kamil Páral 2019-04-12 06:54:49 UTC
Created attachment 1554711 [details]

Requested efivars from 1.35 bios with SB on (working boot).

Comment 9 Kamil Páral 2019-04-12 06:55:37 UTC
Created attachment 1554712 [details]

Requested efivars from 1.35 bios with SB off and CSM off (broken boot, black screen).

Comment 10 Kamil Páral 2019-04-12 06:57:37 UTC
Created attachment 1554713 [details]

A list of all available efivars from 1.35 bios with SB off and CSM off.

Comment 11 Geoffrey Marr 2019-04-15 21:01:00 UTC
Discussed during the 2019-04-15 blocker review meeting: [1]

The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made as for now this appears to be too specific to justify accepting as a blocker, we only know that it affects one laptop model with one specific non-default firmware configuration. However, for affected users it's a critical bug, so we would consider a safe fix for post-freeze inclusion. This decision may be changed based on further investigation.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-04-15/f30-blocker-review.2019-04-15-16.03.txt

Comment 12 Adam Williamson 2019-09-17 02:38:41 UTC
kamil: random note - I never included this in f30 common bugs as I was kinda assuming you were going to do it. But it looks like you didn't?

Comment 13 Kamil Páral 2019-09-17 11:52:34 UTC
No, I didn't, and it doesn't matter now. Removing the commonbugs keyword.

Comment 14 Ben Cotton 2020-04-30 21:07:28 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 15 Ben Cotton 2020-05-26 17:07:37 UTC
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

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