Can't update dbx via fwupdmgr

[davidstrauss]

Updated issue summary

Trying to update the dbx via fwupdmgr results in:

$ sudo fwupdmgr update
...
╔══════════════════════════════════════════════════════════════════════════════╗
║ Upgrade UEFI dbx from 77 to 217?                                             ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ This updates the dbx to the latest release from Microsoft which adds         ║
║ insecure versions of grub and shim to the list of forbidden signatures due   ║
║ to multiple discovered security updates.                                     ║
║                                                                              ║
║ Before installing the update, fwupd will check for any affected executables  ║
║ in the ESP and will refuse to update if it finds any boot binaries signed    ║
║ with any of the forbidden signatures.If the installation fails, you will     ║
║ need to update shim and grub packages before the update can be deployed.     ║
║                                                                              ║
║ Once you have installed this dbx update, any DVD or USB installer images     ║
║ signed with the old signatures may not work correctly.You may have to        ║
║ temporarily turn off secure boot when using recovery or installation media,  ║
║ if new images have not been made available by your distribution.             ║
║                                                                              ║
╚══════════════════════════════════════════════════════════════════════════════╝

Perform operation? [Y|n]: y
Downloading…             [***************************************]
Decompressing…           [***************************************]
Authenticating…          [***************************************]
Decompressing…           [                                       ]Blocked executable in the ESP, ensure grub and shim are up to date: /boot/efi/EFI/BOOT/BOOTX64.EFI Authenticode checksum [0ce02100f67c7ef85f4eed368f02bf7092380a3c23ca91fd7f19430d94b00c19] is present in dbx

This is the issue to collect workarounds and temporary solutions.

Duplicates:

• https://bugzilla.redhat.com/show_bug.cgi?id=2127995
• Properly re-enable Secure Boot on Silverblue 36 (or 37) after updating dbx from 77 -> 217 #375

The final fix will be: #120

---

Original issue text: LVFS update problems on a ThinkPad T16 Gen 1

Describe the bug
The fwupd team thinks that an issue I'm having updating the firmware on my laptop is related to LVFS + Silverblue. I've attempted the troubleshooting they suggested on that side already.

The fwupd issue is here: fwupd/firmware-lenovo#269

To Reproduce

1. Wipe the machine.
2. Install Fedora Silverblue 36.
3. Attempt to update the main device firmware.

Even manually booting (F12) into the firmware update UEFI entry just shows a black screen and then reboots into Fedora proper.

Expected behavior
A successful firmware update.

Screenshots

n/a

OS version:

[straussd@t16 Downloads]$ rpm-ostree status -b
State: idle
BootedDeployment:
● fedora:fedora/36/x86_64/silverblue
                  Version: 36.20220919.0 (2022-09-19T00:44:56Z)
               BaseCommit: a36d2542999f5e374772e1b34abeee25e102a771be4905a564f118feb21033e4
             GPGSignature: Valid signature by 53DED2CB922D8B8D9E63FD18999F7CBF38AB71F4
      RemovedBasePackages: firefox 104.0.2-1.fc36
          LayeredPackages: /usr/bin/efivar ansible baobab exfat-utils f2fs-tools ffmpeg
                           ffmpeg-libs file-roller gnome-boxes gnome-screenshot
                           gnome-tweak-tool google-chrome-stable gstreamer1-vaapi h264enc
                           libva-intel-driver libva-utils libva-vdpau-driver libvdpau-va-gl
                           ltunify pass powertop python3-psutil steam-devices udftools
            LocalPackages: rpmfusion-free-release-36-1.noarch
                           rpmfusion-nonfree-release-36-1.noarch

Additional context

I'm seeing similar issues on my ThinkPad T580, also with Silverblue 36.

[travier]

Looks like the same underlying issue as https://bugzilla.redhat.com/show_bug.cgi?id=2127995 which should be fixed by #120.

We need to write some workaround commands for folks to update the bootloader manually until it is resolved or directly include bootupd in Silverblue 35+ and write docs to let folks run the update manually.

The workaround without bootupd is to update the content of /boot/efi with the content of /usr/lib/ostree-boot/efi. I have not tested this yet and we probably want to use bootupd for that instead of having folks manually update their bootloader.

[davidstrauss]

@travier I've attempted a couple of the steps, and I'm hoping for some further guidance on working around this.

• I saw on a linked issue (SB36 boots to a blank screen unless any usb drive is plugged in #349) the suggestion of installing from a fresh ISO. I'm not sure if you mean something like a nightly (or otherwise revised) image, but the laptop with this issue was installed directly with Silverblue 36, not upgraded from any prior release.
• I've been struggling to integrate bootupd with Silverblue and can't find much documentation. Since the EFI partition is referenced by UUID, I was okay altering the label to "EFI-SYSTEM" from the Silverblue default to fix discoverability, but the utility still complains about not being able to adopt or update anything.
• To manually update, I'm attempting this: sudo rsync -av /usr/lib/ostree-boot/efi/ /boot/efi/. Is this the intent of your suggestion? I'm hoping not, as this makes my system unbootable.

[travier]

Installing and using bootupd should be (warning untested!):

$ sudo rpm-ostree install --apply-live bootupd
$ sudo bootupctl status
$ sudo bootupctl adopt-and-update

[davidstrauss]

Here's how I installed it in more detail:

1. Added bootupd with rpm-ostree. I didn't do any live application, though. I just rebooted.
2. I needed to enable and start the socket via systemd.
3. I needed to rename my EFI partition to EFI-SYSTEM (mentioned this in my previous comment).
4. The "status" subcommand mostly shows that it isn't set up yet.
5. The "adopt-and-update" just complains that there's nothing to adopt.

[travier]

CC @cgwalters. We likely need some small fixes for Silverblue.

[travier]

Another workaround is #120 (comment) until we fix bootupd (which is going to be included in F36+ soon).

[davidstrauss]

Should the workaround fix this issue with fwupdmgr detecting an obsolete shim (because it isn't for me)?

[straussd@phoenix ~]$ fwupdmgr update 
Devices with no available firmware updates: 
[...snip...]
╔══════════════════════════════════════════════════════════════════════════════╗
║ Upgrade UEFI dbx from 83 to 217?                                             ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ This updates the dbx to the latest release from Microsoft which adds         ║
║ insecure versions of grub and shim to the list of forbidden signatures due   ║
║ to multiple discovered security updates.                                     ║
║                                                                              ║
║ Before installing the update, fwupd will check for any affected executables  ║
║ in the ESP and will refuse to update if it finds any boot binaries signed    ║
║ with any of the forbidden signatures. If the installation fails, you will    ║
║ need to update shim and grub packages before the update can be deployed.     ║
║                                                                              ║
║ Once you have installed this dbx update, any DVD or USB installer images     ║
║ signed with the old signatures may not work correctly. You may have to       ║
║ temporarily turn off secure boot when using recovery or installation media,  ║
║ if new images have not been made available by your distribution.             ║
║                                                                              ║
╚══════════════════════════════════════════════════════════════════════════════╝

Perform operation? [Y|n]: y
Downloading…             [***************************************]
Decompressing…           [***************************************]
Authenticating…          [***************************************]
Waiting…                 [***************************************]
Writing…                 [***************************************]
Decompressing…           [                                       ]
Blocked executable in the ESP, ensure grub and shim are up to date: /boot/efi/EFI/fedora/shimx64-fedora.efi Authenticode checksum [0ce02100f67c7ef85f4eed368f02bf7092380a3c23ca91fd7f19430d94b00c19] is present in dbx

[travier]

It probably should but I've not tested it.

[heyakyra]

The workaround without bootupd is to update the content of /boot/efi with the content of /usr/lib/ostree-boot/efi. I have not tested this yet and we probably want to use bootupd for that instead of having folks manually update their bootloader.

Tried this, can no longer boot.

GRUB version 2.0

Minimal BIOS-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists possible device or file completions.

grub> _

Any ideas on how to recover my system now?

3. I needed to rename my EFI partition to EFI-SYSTEM

Wish I'd seen this before! Trying this on my other system:

Another workaround is #120 (comment) until we fix bootupd (which is going to be included in F36+ soon).

[heyakyra]

Both systems are stuck at GRUB now. Hope there's some way to recover from a live USB?

Edit: I tried combining various things to recover:

• https://unix.stackexchange.com/questions/441925/how-to-repair-a-broken-fedora-boot-partition
• https://thomas-leister.de/en/repair-fedora-efi-bootloader/
• https://discussion.fedoraproject.org/t/boot-entries-gone-after-upgrade/8026/12
• Use bootupd and remove ostree-grub2 (was: All deployments are shown twice in grub) #120 (comment)
• https://mildred.fr/quick-posts/2020-04-28-moving-fedora-silverblue-to-another-hdd/

…but ended up re-installing fresh

[Naheem]

Now that unified core will miss Fedora 38, what are the plans for this?

I and many others are "stuck" with missing dbx updates because the shim/grub in your silverblue install is too old and the bootupd feature was going to enable that.

[fedelibre]

In #120 I read that the fix has been pushed to rawhide and deferred to F39.

If I rebase my Silverblue installation to rawhide, I can finally update the firmware without having to manually tweak any file?

[fedelibre]

I rebased to rawhide and overlayed the bootupd package.
But there's something wrong here:

# bootupctl status
No components installed.
Detected: EFI: unknown
Boot method: EFI

# bootupctl adopt-and-update
error: internal error: Component EFI has no available update

# bootupctl validate
No components installed.

[fedelibre]

Maybe my hardware is too old:

# fwupdtool get-devices
Loading?                 [****                                   ]19:51:10.771 FuPluginUefiCapsule  SMBIOS BIOS Characteristics Extension Byte 2 is invalid -- UEFI Specification is unsupported, but /sys/firmware/efi exists: System does not support UEFI mode
Loading?                 [************************************** ]
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
Dell Inc. Dell System XPS L322X
... [cut] ...

[travier]

#120 (comment)

[travier]

See #543 (comment) for a lightly tested set of commands to update your EFI bootloader until we have full bootupd support in Fedora Atomic Desktops.

I'm going to close this one as duplicate as the root of the issue and the solution is the same as #543 and #120.