Bug 2010595
Summary: | Cannot install firmware if secureboot is enabled | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | mattias.eriksson |
Component: | shim | Assignee: | Peter Jones <pjones> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 35 | CC: | awilliam, cody6730, dennis.schridde, devurandom, fmartine, gmarr, javierm, kparal, linux, mcatanza, mjg59, nhfed, pbrobinson, pjones, rharwood, rhughes, robatino, rvkagan, stanislav.polasek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | RejectedBlocker | ||
Fixed In Version: | shim-15.6-1 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-06-17 01:19:09 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
mattias.eriksson
2021-10-05 06:31:30 UTC
*** Bug 2012220 has been marked as a duplicate of this bug. *** 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. It's fixed upstream and will be in the 15.5 release due soon, there's been unforeseen delays. *** Bug 2014257 has been marked as a duplicate of this bug. *** 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 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)? 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. 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 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 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? 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. (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). > 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) 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 (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? FEDORA-2022-98830efc68 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-98830efc68 FEDORA-2022-98830efc68 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-98830efc68` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-98830efc68 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2022-98830efc68 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. |