Bug 2010595 - Cannot install firmware if secureboot is enabled
Summary: Cannot install firmware if secureboot is enabled
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: shim
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker
: 2012220 2014257 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-10-05 06:31 UTC by mattias.eriksson
Modified: 2022-05-17 17:32 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github rhboot shim pull 379 0 None Merged shim: another attempt to fix load options handling 2022-02-28 15:48:06 UTC
Launchpad 1929471 0 None None None 2022-02-28 15:48:06 UTC

Description mattias.eriksson 2021-10-05 06:31:30 UTC
Description of problem:
When you get a firmware notification and try to install the firmware using fwupd / gnome-software, it will just not install anything. It will just reboot and start up as normal. The cause for this was tracked down to a option parsing bug in the shim. This has been present for months in F34, and known by fwupd people and people working on the shim. A fix exists upstream, so I assumed it would be included in F35, but the problem persists. 
Upstream pull request that was merged: https://github.com/rhboot/shim/pull/379

Version-Release number of selected component (if applicable):
shim-x64-15.4-5.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Ensure secure boot is enabled
2. Try to install Lenovo firmware upgrades


Actual results:
Nothing is installed on reboot

Expected results:
Firmware would be installed

Additional info:
The workaround is to temporary switch off secureboot in the BIOS, then install the firmware, and then switch it back on after the upgrade is done. That is however not an obvious and easy workaround for end users.

Comment 1 Peter Robinson 2021-10-15 07:41:45 UTC
*** Bug 2012220 has been marked as a duplicate of this bug. ***

Comment 2 mattias.eriksson 2021-11-19 10:33:24 UTC
This is still not fixed in the released F35. The impact of this is that a lot of Lenovo latops are unable to upgrade the firmware.

Comment 3 Peter Robinson 2021-11-19 12:14:35 UTC
It's fixed upstream and will be in the 15.5 release due soon, there's been unforeseen delays.

Comment 4 Peter Robinson 2021-11-29 21:43:13 UTC
*** Bug 2014257 has been marked as a duplicate of this bug. ***

Comment 5 nh 2021-12-21 09:08:09 UTC
Exact same problem on Thinkpad X1 Carcon Gen 9 / Fedora Workstation 35 (up to date).

Problem also occurs with fwupdmgr as described here: https://bugzilla.redhat.com/show_bug.cgi?id=2029396

Comment 6 Kamil Páral 2022-02-28 15:48:06 UTC
I can confirm this problem on Thinkpad P1 gen3 running F35, and Thinkpad T480s running latest F36:
shim-x64-15.4-5.x86_64
fwupd-efi-1.2-1.fc36.x86_64
fwupd-1.7.5-1.fc36.x86_64
efibootmgr-16-12.fc36.x86_64

Disabling SecureBoot resolves the problem (however, it makes re-testing this bug problematic, because I don't know how to downgrade firmware, once I successfully upgraded it).

It seems Ubuntu already released the fix:
https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1929471

Shim 15.5 is out now:
https://github.com/rhboot/shim/releases

Peter, can you please tell us whether all machines are affected, or just some? Perhaps only Lenovo laptops (all/newer models)?

Comment 7 Kamil Páral 2022-02-28 15:55:07 UTC
I'm proposing this as a final blocker for Fedora 36. Preventing users from applying security fixes to their firmware is a pretty big deal. Even if this affected just some portion of our audience (e.g. Lenovo users with some recent laptop models), it's still a huge amount of people. If this isn't accepted as a blocker, it should definitely be accepted at least as a prioritized bug.

Comment 8 Geoffrey Marr 2022-02-28 21:15:24 UTC
Discussed during the 2022-02-28 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as there was some support in principle for this being a blocker, but also some opposition, and it doesn't obviously violate the existing criteria. We will ask how software updates are affected if a firmware update is queued but fails (if the software update also does not happen in this case, that could be a blocker issue). Someone may also choose to propose specific criteria for firmware updates.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-02-28/f36-blocker-review.2022-02-28-17.00.txt

Comment 9 Geoffrey Marr 2022-03-07 22:42:46 UTC
Discussed during the 2022-03-07 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as there hasn't been much movement on this from last week (info about how this affects software updates is not yet provided), so we will delay the decision again.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-03-07/f36-blocker-review.2022-03-07-17.01.txt

Comment 10 cody6730 2022-03-08 01:39:58 UTC
What information about how software updates are affected are you looking for, exactly? Right now, unless secure boot is disabled, firmware updates cannot be applied for at least a number of Lenovo/Thinkpad laptops (mine included). Disabling secure boot should not be a requirement for this, and updating to the latest upstream release, which supposedly fixes this bug, seems like a reasonable thing to do, does it not?

Comment 11 Adam Williamson 2022-03-08 18:41:49 UTC
Yes, but the question is not whether it's a *bug*, but whether it's a *release-blocking* bug. That's the determination we try to make in the meetings.

The thing we wanted clarity on is what happens if both a firmware update and regular Fedora package updates are available at the same time. Do the Fedora updates get installed successfully or not? I would expect that they do, but we wanted to be sure about that.

Comment 12 Dennis Schridde 2022-03-08 20:20:39 UTC
(In reply to Adam Williamson from comment #11)
> Yes, but the question is not whether it's a *bug*, but whether it's a
> *release-blocking* bug. That's the determination we try to make in the
> meetings.
> 
> The thing we wanted clarity on is what happens if both a firmware update and
> regular Fedora package updates are available at the same time. Do the Fedora
> updates get installed successfully or not? I would expect that they do, but
> we wanted to be sure about that.

They will be installed successfully (on my system).

Comment 13 Peter Robinson 2022-03-11 00:09:37 UTC
> Yes, but the question is not whether it's a *bug*, but whether it's a
> *release-blocking* bug. That's the determination we try to make in the
> meetings.

The upstream shim maintainers are also the maintainers in Fedora, it needs to go through signing with Microsoft so that it works with secure boot and their may be issues with other platform/device issues they're dealing with too. The iterations between firmware, early boot and other vendors is a nuanced and complicated one.

While I agree the inability to update firmware with secure boot enabled is unfortunate but if the update then may cause something else not to boot or some other problem we're just moving the problem, I'm sure there will be an update as soon as possible I don't think we can block a release on this given it's hardware specific and some what out of our control.(In reply to Adam Williamson from comment #11)

Comment 14 Geoffrey Marr 2022-03-14 18:57:13 UTC
Discussed during the 2022-03-14 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Final)" was made as this is a sad bug for affected owners, but firmware update functionality is not covered in the release criteria, and nothing that is covered in the criteria is broken by this bug.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-03-14/f36-blocker-review.2022-03-14-16.01.txt

Comment 15 Chris Adams 2022-05-17 17:32:35 UTC
(In reply to Peter Robinson from comment #3)
> It's fixed upstream and will be in the 15.5 release due soon, there's been
> unforeseen delays.

It's been six months since the release was "due soon"... I understand that shim has to have special handling, but could we get an update on the delays?


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