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 Fedora-Workstation-Live-x86_64-30-20190408.n.0.iso Fedora-Everything-netinst-x86_64-30-20190408.n.0.iso How reproducible: always 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)
Created attachment 1554269 [details] SecureBoot error SB error when SB is enabled
Created attachment 1554270 [details] GRUB error GRUB error when SB is disabled and CSM is also disabled
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).
'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.
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?
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: KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c KEKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c PK-8be4df61-93ca-11d2-aa0d-00e098032b8c PKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c SignatureSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c VendorKeys-8be4df61-93ca-11d2-aa0d-00e098032b8c dbDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c dbxDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c (Some may not be present.)
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: SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c SignatureSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c 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.
Created attachment 1554711 [details] efivars-1.35-sb-on Requested efivars from 1.35 bios with SB on (working boot).
Created attachment 1554712 [details] efivars-1.35-sb-off-csm-off Requested efivars from 1.35 bios with SB off and CSM off (broken boot, black screen).
Created attachment 1554713 [details] all-efivars-1.35-sb-off-csm-off A list of all available efivars from 1.35 bios with SB off and CSM off.
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
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?
No, I didn't, and it doesn't matter now. Removing the commonbugs keyword.
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.
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.