|
Bugzilla – Full Text Bug Listing |
| Summary: | fwupdmgr update fails: Secure boot is enabled, but shim isn't installed to EFI/opensuse/shimx64.efi | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Robert Munteanu <rombert> |
| Component: | Other | Assignee: | Gary Ching-Pang Lin <glin> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | arvidjaar, dimstar, dominik.gedon, fkrueger, peters.chris |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Robert Munteanu
2023-11-14 16:11:45 UTC
Looking at https://build.opensuse.org/package/view_file/openSUSE:Factory/fwupd/fwupd.changes?expand=1, maybe related to - Drop fwupd-bsc1130056-change-shim-path.patch: no longer applicable. cc-ing submitter. I have that problem, too. Here my terminal output: fwupdmgr update WARNING: UEFI ESP partition may not be set up correctly See https://github.com/fwupd/fwupd/wiki/PluginFlag:esp-not-valid for more information. Devices with no available firmware updates: • Integrated RGB Camera • MK5059GSXP • SSD 980 PRO 2TB • UEFI Device Firmware • UEFI Device Firmware • UEFI Device Firmware • UEFI Device Firmware • UEFI Device Firmware • UEFI Device Firmware • UEFI Device Firmware Devices with the latest available firmware version: • Embedded Controller ╔══════════════════════════════════════════════════════════════════════════════╗ ║ Upgrade System Firmware from 0.1.41 to 0.1.46? ║ ╠══════════════════════════════════════════════════════════════════════════════╣ ║ This release contains the following changes: ║ ║ ║ ║ • [Important] Remove MSC mode. ║ ║ • (New) Add support for Maori keyboard. ║ ║ • (New) Enable smart card preboot function. ║ ║ • (Fix) Fixed issue where Lenovo logo interface lost during restart after ║ ║ set Supervisor Password/Power-On Password/NVMe1Password. ║ ║ • (Fix) Fixed issue where keyboard backlight does not remain after ║ ║ returning from modern standby. ║ ║ • (Fix) Fixed issue where system hang up at Pre-Boot Authentication ║ ║ interface after perform a normal scan operation with unregistered ║ ║ fingerprint for 3 attempts. ║ ║ • (Fix) Fixed issue where system will shutdown when dock power button is ║ ║ pressed for 4s in the process of BIOS upgrade. ║ ║ • (Fix) Fixed issue where “invalid critical threshold” issue under ║ ║ linux. ║ ║ • (Fix) Fixed issue where system can't change power-saver mode under ║ ║ linux after wake up from DC+Lid open. ║ ║ ║ ║ 21CHCTO1WW must remain plugged into a power source for the duration of the ║ ║ update to avoid damage. ║ ╚══════════════════════════════════════════════════════════════════════════════╝ Perform operation? [Y|n]: y Decompressing… [ ] Secure boot is enabled, but shim isn't installed to EFI/opensuse/shimx64.efi System information: Operating System: openSUSE Tumbleweed 20231110 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 Kernel Version: 6.6.1-1-default (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 PRO 6850U with Radeon Graphics Memory: 30.1 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: LENOVO Product Name: 21CHCTO1WW System Version: ThinkPad T16 Gen 1 (In reply to Robert Munteanu from comment #1) > - Drop fwupd-bsc1130056-change-shim-path.patch: no longer > applicable. The patch most certainly remains valid, just line numbers are off. https://github.com/fwupd/fwupd/blob/1045695f8fa0c793022c2f513bb8894c19612f19/plugins/uefi-capsule/fu-uefi-bootmgr.c#L408C1-L413C17 /* test if we should use shim */ secure_boot = fu_efivar_secure_boot_enabled(NULL); if (secure_boot) { shim_app = fu_uefi_get_esp_app_path("shim", error); if (shim_app == NULL) return FALSE; This bug seems to persist and prevented me effectively from updating my Lenovo Thinkpads Firmware. I think, it should be fixed soon - especially considering the fact, that it should not be too complicated and firmware updates are to be considered security relevant! Other distros seem to have no problem with that. I used an Ubuntu 22.04.3 and the fwupd worked flawless. Also, when I was still using openSUSE Leap, fwupdmgr worked. It's a little emberrassing, that a "leading edge" distro messes that up. Gary, Can you please have a look at this? The patch is originally yours. I think it had been rebased (numerous times since its original inception) - but apparently no longer does work as intended. Does the issue persist even in fwupd 1.9.9 and later? I've checked 'strings libfwupdengine.so' in fwupd 1.9.9, and at least "%s/shim.efi" is inside the binary, so I suppose fwupd would look for shim.efi instead of shimx64.efi. I see the following entry in the changelog * Thu Nov 16 2023 Dominique Leuenberger <dimstar@opensuse.org> - Re-add fwupd-bsc1130056-change-shim-path.patch: patch was dropped in error (boo#1217138). And fwmgr update successfully executes for me. I think this is fixed, does anyone else have problems? (In reply to Gary Ching-Pang Lin from comment #6) > Does the issue persist even in fwupd 1.9.9 and later? I've checked 'strings > libfwupdengine.so' in fwupd 1.9.9, and at least "%s/shim.efi" is inside the > binary, so I suppose fwupd would look for shim.efi instead of shimx64.efi. I get no actual warning at this point when using fwupdmgr (get-devices). But as I already applied the pending firmware updates using Ubuntu, I can't confirm that it really works as I have no firmware updates at the moment. If I will have the same error in the future, I will reopen this ticket. Based on the feedbacks, I'm closing this bug. Feel free to reopen it if the issue happens again. I was testing the experimental systemd-boot in Tumbleweed and got the same error. I took a look where the shim.efi file is expected to be and with systemd-boot it is located in a different location.
Normally, it is found in /boot/efi/EFI/opensuse. However, with systemd-boot it is located under /boot/efi/EFI/systemd instead. I tested this with a fresh Tumbleweed installation without GRUB2.
$ tree /boot
/boot
├── efi
│ ├── EFI
│ │ ├── BOOT
│ │ │ ├── BOOTX64.EFI
│ │ │ ├── fallback.efi
│ │ │ └── MokManager.efi
│ │ ├── Dell
│ │ │ └── Bios
│ │ │ └── Recovery
│ │ │ └── BIOS_CUR.RCV
│ │ ├── opensuse
│ │ │ ├── fw
│ │ │ └── fwupdx64.efi
│ │ └── systemd
│ │ ├── boot.csv
│ │ ├── grub.efi
│ │ ├── installed_by_sdbootutil
│ │ ├── MokManager.efi
│ │ └── shim.efi
│ ├── loader
│ │ ├── entries
│ │ │ ├── opensuse-tumbleweed-6.8.1-1-default-1.conf
│ │ │ ├── opensuse-tumbleweed-6.8.1-1-default-2.conf
│ │ │ ├── opensuse-tumbleweed-6.8.1-1-default-3.conf
│ │ │ └── opensuse-tumbleweed-6.8.1-1-default-4.conf
│ │ ├── entries.srel
│ │ ├── loader.conf
│ │ └── random-seed
│ └── opensuse-tumbleweed
│ └── 6.8.1-1-default
│ ├── initrd-87d723dcc75cd25b16a5e37cb8c271deb9dacf8d
│ └── linux-9266ed9b47842380f0895cf130ef0b6126674133
└── grub2
├── i386-pc
└── x86_64-efi
The quick and dirty fix I tried, was simply copying shim.efi to /boot/efi/EFI/opensuse and executed fwupdmgr update again. Then the UEFI update worked fine.
Since I am using this experimental bootloader, I am not sure if this qualifies to reopening this bug report.
|