I have a similar situation as reported in Secure Boot dbx update?, but since that post is already closed I am starting this one. A few days ago, my Intel motherboard died and I chose as replacement ASRock B550M PG Riptide, with AMD Ryzen 7 5700G with Radeon. This is Fedora Silverblue 37. Contrary to my worst fears, everything went fantastic. Silverblue is working as if nothing happened, except that is moving faster. I also saw rpm-ostree installing several AMD-related pieces. But then I got this offer from Software:
I was recently hit by the TPM error in a quite old HP all-in-one workstation, which I fixed. But before pushing the update button, I would like to get some feedback.
Thanks in advance.
You do not say how or when you upgraded to F37. The release of F37 was delayed to wait for a security fix in ssl, so that likely is not directly related, but there was also a recent update to the tpm keys and it is possible your machine is not yet updated for that. It is up to you to verfify if the upgrade is needed and to respond accordingly. You really should make certain everything security related is up to date. If not then problems may occur.
I think an update should be done just as a regular thing and the update is supposed to take care of any issues. This is a warning that if your system is running improperly signed software and your recovery images are also older that recovery may become a problem.
Thanks for your reply. I upgraded to F37 more than a month ago, when it hit beta status. Since then, I kept updating almost every day. My workstation broke down on November 12 and was fixed with the new CPU on November 18. That day, I updated everything again and was then when I got this secure boor update offer. I just ran rpm-ostree and found no new updates, so I guess I’m in a good position to proceed.
I survived. To my surprise, Software didn’t ask me to reboot once this firmware updated was applied (which took around 5 seconds). Software reloaded and offered updates for 2 flatpaks apps, which I also applied. Just in case I rebooted and everything went OK.
Well, there is something else going on here. The offer is back and no firmware is installed. Other regular updates were offered and applied on reboot, but the firmware one just keep hanging there in Software. So I guess I should disable it or find another way to apply it. Suggestions are welcome.
This update is applied in motherboard’s UEFI variable store, so after changing motherboard it might require reapplying.
If you look though linked topic, you’ll find my answers with tools able to install this update without GNOME Software or to verify whether it’s been installed.
[francisco@principal ~]$ sudo fwupdmgr update
Devices with no available firmware updates:
• CT2000BX500SSD1
• Portable SSD T5
╔══════════════════════════════════════════════════════════════════════════════╗
║ 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]:
Downloading… []
Downloading… []
Downloading… []
Decompressing… []
Authenticating… []
Waiting… []
Writing… [***************************************]
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
[francisco@principal ~]$
It’s ironic, but I am relieved this is a bug. I was apprehensive about buying an AMD motherboard instead of Intel (besides it would cost more, it wouldn’t be available for 3 long weeks). Now I’m sure I made a good choice.
New development. Today I got some dracut updates for Silverblue 37 and my workstation failed to boot. I went to the BIOS and disabled secure boot, after which booting resumed. I intend to keep secure boot off until the firmware update bug is solved or when I reinstall Silverblue, if ever.
Somehow my dbx has been updated despite the reported bug (2127995) still being open and proposed fix not having been implemented yet. So I’m wondering how this has been resolved.
Used to be stuck at version 77, but now at 371:
$ fwupdmgr get-devices
? ??UEFI dbx:
? Device ID: 362301da643102b9f38477387e2193e57abaa590
? Summary: UEFI revocation database
? Current version: 371
? Minimum Version: 371
? Vendor: UEFI:Linux Foundation
? Install Duration: 1 second
? GUIDs: f8ba2887-9411-5c36-9cee-88995bb39731 ? UEFI\CRT_A1117F516A32CEFCBA3F2D1ACE10A87972FD6BBE8FE0D0B996E09E65D802A503&ARCH_X64
? d07ff664-b0e1-5f4e-a723-d7fbcbfcb94f ? UEFI\CRT_3CD3F0309EDAE228767A976DD40D9F4AFFC4FBD5218F2E8CC3C9DD97E8AC6F9D&ARCH_X64
? 5c6c0596-253d-560d-a120-cb32286764c6 ? UEFI\CRT_9C25AE3ECE9D93079A158B01AE21E92E520B05D6BBD5CE6C4FA95249D300E38B&ARCH_X64
? Device Flags: ? Internal device
? ? Updatable
? ? Supported on remote server
? ? Needs a reboot after installation
? ? Device is usable for the duration of the update
? ? Only version upgrades are allowed
? ? Signed Payload
? Device Requests: ? Message
? ? Image
?
$ fwupdmgr get-updates
Devices with no available firmware updates:
? Force MP510
? Force MP600
? SSD 860 EVO 1TB
? SSD 970 EVO 1TB
? System Firmware
? UEFI Device Firmware
? UEFI Device Firmware
? USB2.1 Hub
? USB2.1 Hub
Devices with the latest available firmware version:
? UEFI dbx
No updates available
$ rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run 47min ago
Deployments:
● fedora:fedora/39/x86_64/kinoite
Version: 39.20240104.0 (2024-01-04T01:45:12Z)
BaseCommit: 9c483275cf704df76482c9c206997b818776ceb6e5a255915ef5009c2728d752
GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
RemovedBasePackages: firefox firefox-langpacks 121.0-3.fc39
LayeredPackages: cockpit cockpit-machines cockpit-ostree cockpit-podman doas qt-virt-manager rocm-clinfo rocm-opencl rocminfo tmux vim zsh
fedora:fedora/39/x86_64/kinoite
Version: 39.20240103.0 (2024-01-03T00:42:45Z)
BaseCommit: f19d5f66e767f8ed8933f416f325fbe2c7c5047f031ad2ce2b3c59372ae447a7
GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
RemovedBasePackages: firefox firefox-langpacks 121.0-2.fc39
LayeredPackages: cockpit cockpit-machines cockpit-ostree cockpit-podman doas qt-virt-manager rocm-clinfo rocm-opencl rocminfo tmux vim zsh
