Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1713033

Summary: Fwupd refuses to update firmware on UEFI with Secure boot enabled
Product: Red Hat Enterprise Linux 8 Reporter: Jakub Bittner <jbittner>
Component: fwupdAssignee: Richard Hughes <rhughes>
Status: CLOSED ERRATA QA Contact: Erico Nunes <ernunes>
Severity: high Docs Contact:
Priority: medium    
Version: 8.2CC: adam.winberg, admiller, dennis.schridde, ernunes, fmartine, jloscar, lmiksik, mthacker, pgozart, rchanter, rhughes, rvr, sbarcomb
Target Milestone: rcKeywords: Regression
Target Release: 8.0Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: fwupd-1.1.4-6.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 17:02:16 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 Jakub Bittner 2019-05-22 17:43:58 UTC
Description of problem:

Fwupdate refuses to update firmware on Lenovo T470s with RHEL8 with UEFI and secure boot enable due to missing shim on EFI partition.
"Secure boot is enabled, but shim isn't installed to the EFI system partition"

Version-Release number of selected component (if applicable):
fwupd-1.1.4-1.el8.x86_64
fwupdate-efi-11-3.el8.x86_64
fwupdate-libs-11-3.el8.x86_64
shim-x64-15-8.x86_64
kernel-4.18.0-80.el8.x86_64

fwupdmgr --version
client version:	1.1.4
compile-time dependency versions
	appstream-glib:	0.7.12
	gusb:	0.3.0
	efivar:	36
daemon version:	1.1.4


How reproducible:


Steps to Reproduce:
1. Install RHEL8 on Lenovo Thinkpad T470s with UEFI and Secure Boot
2. Boot
3. run fwupdmgr -v update

Actual results:

fwupdmgr -v update
Downloading 0.1.32 for 20HGS22D0W System Firmware...
(fwupdmgr:13567): FuCommon-DEBUG: 19:42:05.227: creating path /root/.cache/fwupd
(fwupdmgr:13567): FuMain-DEBUG: 19:42:05.239: skpping download as file already exists
(fwupdmgr:13567): Fwupd-DEBUG: 19:42:05.241: Emitting ::status-changed() [decompressing]
Decompressing…         [ -                                     ](fwupdmgr:13567): Fwupd-DEBUG: 19:42:05.302: Emitting ::status-changed() [idle]
Decompressing…         [***************************************]
(fwupdmgr:13567): Fwupd-DEBUG: 19:42:05.378: Emitting ::status-changed() [waiting-for-auth]
Authenticating…        [  -                                    ](fwupdmgr:13567): Fwupd-DEBUG: 19:42:05.379: Emitting ::status-changed() [idle]
Authenticating…        [***************************************]
(fwupdmgr:13567): Fwupd-DEBUG: 19:42:05.406: Emitting ::status-changed() [scheduling]
Updating 20HGS22D0W System Firmware…                           ]
Scheduling…            [  -                                    ](fwupdmgr:13567): Fwupd-DEBUG: 19:42:05.406: Emitting ::device-changed(84149fb78009cf27cc1dd5520911f46f8792dbfe)
Scheduling…            [    \                                  ](fwupdmgr:13567): Fwupd-DEBUG: 19:42:05.487: Emitting ::status-changed() [idle]
Scheduling…            [***************************************]
(fwupdmgr:13567): Fwupd-DEBUG: 19:42:05.487: Emitting ::device-changed(84149fb78009cf27cc1dd5520911f46f8792dbfe)
Secure boot is enabled, but shim isn't installed to the EFI system partition

Expected results:

Updated firmware.

Additional info:

# efibootmgr -v
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0001,0018,0019,001A,001C,001D,001E,0017,001B
Boot0000* Red Hat Enterprise Linux	HD(1,GPT,0fe4b357-7c42-4ba2-8222-bc35096eb852,0x800,0x12c000)/File(\EFI\redhat\shimx64.efi)
Boot0001* Windows Boot Manager	HD(1,GPT,68115ba0-e84a-4d2c-8c90-bf880bf934e9,0x800,0x64000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot0010  Setup	FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)
Boot0011  Boot Menu	FvFile(126a762d-5758-4fca-8531-201a7f57f850)
Boot0012  Diagnostic Splash Screen	FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380)
Boot0013  Lenovo Diagnostics	FvFile(3f7e615b-0d45-4f80-88dc-26b234958560)
Boot0014  Startup Interrupt Menu	FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8479)
Boot0015  Rescue and Recovery	FvFile(665d3f60-ad3e-4cad-8e26-db46eee9f1b5)
Boot0016  MEBx Hot Key	FvFile(ac6fd56a-3d41-4efd-a1b9-870293811a28)
Boot0017  USB CD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55)
Boot0018  USB FDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49)
Boot0019* NVMe0	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,001c199932d94c4eae9aa0b6e98eb8a400)
Boot001A  ATA HDD0	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600)
Boot001B* USB HDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)
Boot001C  PCI LAN	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)
Boot001D  Other CD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35406)
Boot001E  Other HDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f606)
Boot001F* IDER BOOT CDROM	PciRoot(0x0)/Pci(0x14,0x0)/USB(11,1)
Boot0020* IDER BOOT Floppy	PciRoot(0x0)/Pci(0x14,0x0)/USB(11,0)
Boot0021* ATA HDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6)
Boot0022* ATAPI CD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a354)
Boot0023* PCI LAN	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)


# tree /boot
/boot
├── config-4.18.0-80.1.2.el8_0.x86_64
├── config-4.18.0-80.el8.x86_64
├── efi
│   └── EFI
│       ├── BOOT
│       │   ├── BOOTX64.EFI
│       │   └── fbx64.efi
│       ├── redhat
│       │   ├── BOOTX64.CSV
│       │   ├── fonts
│       │   ├── fw
│       │   ├── fwupia32.efi
│       │   ├── fwupx64.efi
│       │   ├── grub.cfg
│       │   ├── grubenv
│       │   ├── grubx64.efi
│       │   ├── mmx64.efi
│       │   ├── shimx64.efi
│       │   └── shimx64-redhat.efi
│       └── rhel
│           └── fw
│               ├── fwupd-3b8c8162-188c-46a4-aec9-be43f1d65697.cap
│               ├── fwupd-7a176688-0960-47ba-931b-7829849e8347.cap
│               └── fwupd-e9124c4a-fdff-42e5-b2ad-f745db345953.cap
├── grub2
│   └── grubenv -> ../efi/EFI/redhat/grubenv
├── initramfs-0-rescue-e8551916e06f4b2aa457d5f64b6e022a.img
├── initramfs-4.18.0-80.1.2.el8_0.x86_64.img
├── initramfs-4.18.0-80.1.2.el8_0.x86_64kdump.img
├── initramfs-4.18.0-80.el8.x86_64.img
├── initramfs-4.18.0-80.el8.x86_64kdump.img
├── loader
│   └── entries
│       ├── e8551916e06f4b2aa457d5f64b6e022a-0-rescue.conf
│       ├── e8551916e06f4b2aa457d5f64b6e022a-4.18.0-80.1.2.el8_0.x86_64.conf
│       └── e8551916e06f4b2aa457d5f64b6e022a-4.18.0-80.el8.x86_64.conf
├── System.map-4.18.0-80.1.2.el8_0.x86_64
├── System.map-4.18.0-80.el8.x86_64
├── vmlinuz-0-rescue-e8551916e06f4b2aa457d5f64b6e022a
├── vmlinuz-4.18.0-80.1.2.el8_0.x86_64
└── vmlinuz-4.18.0-80.el8.x86_64

11 directories, 30 files


# cat /etc/fwupd/uefi.conf 
[uefi]

# the shim loader is required to chainload the fwupd EFI binary unless
# the fwupd.efi file has been self-signed manually
RequireShimForSecureBoot=true

# the EFI system partition path used
# if this is is not /boot/efi, /boot, or /efi
#OverrideESPMountPoint=

# amount of free space required on the ESP, for example using 0x2000000 for 32Mb
#RequireESPFreeSpace=

Comment 1 adam winberg 2019-08-21 12:56:29 UTC
Same problem here, with Lenovo X280 and Lenovo T480

Comment 2 Romain Chantereau 2019-09-30 09:12:46 UTC
Hi,

the way fwupd is looking for shim is quite limited, something like: {ESP}/EFI/{os-release-id}/shim*efi


On RHEL 8, os-release-id is “rhel”, but the uefi loader is in {ESP}/EFI/redhat/shim*efi

Then, until fwupd scheme is fixed, a simple workaround is to copy the shim efi binary in {ESP}/EFI/rhel

Best Regards,

Comment 5 Javier Martinez Canillas 2019-12-20 14:13:10 UTC
Changing the component to fwupd since the comments explain that the issue is there.

Comment 6 Romain Chantereau 2019-12-20 15:36:50 UTC
(In reply to Javier Martinez Canillas from comment #5)
> Changing the component to fwupd since the comments explain that the issue is
> there.

Hi Javier,

It depends :)

If you consider:
* the release-id for RHEL 8.x should be “redhat” then the issue is in “redhat-release”
* the release id for RHEL 8.x should be “rhel” the issue is in “grub2-common” or “shim” (or perhaps “efi-filesystem”)
* the way fwupd is looking for the shim binary should be reworked, then it is “fwupd”

Hope it helps.

Best Regards,

Comment 8 Richard Hughes 2020-02-13 11:18:24 UTC
I think this would be easy to fix in RHEL, later versions of fwupd already have a `-Defi_os_dir=` parameter we can use to hardcode the directory as `redhat`. I agree it's somewhat odd that the release-id isn't the same as the EFI_OS_DIR but I think changing redhat-release or efi-filesystem would be much more likely to cause regressions. With a minor modification, https://github.com/fwupd/fwupd/commit/5d9984e5ad656876858b6c369ec5c0ef14683043 should be able to be backported fairly easily and then the .spec file just has to be changed to specify `-Defi_os_dir=redhat`.

Comment 22 Tomas Popela 2020-04-02 10:28:48 UTC
*** Bug 1759719 has been marked as a duplicate of this bug. ***

Comment 23 jloscar 2020-04-23 17:07:51 UTC
Do we have a status update or a timeframe of the errata release?

Comment 25 errata-xmlrpc 2020-04-28 17:02:16 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1901