2

Upgrading firmware via fwupdmgr results in following error:

$ fwupdmgr update

Devices with no available firmware updates: 
 • USB2.0 Hub
 • USB2.0 Hub
 • USB3.1 Hub
 • USB3.1 Hub
 • Integrated Camera
 • SSD 970 EVO Plus 1TB
 • UEFI Device Firmware
 • UEFI Device Firmware
 • UEFI Device Firmware
 • UEFI Device Firmware
 • UEFI Device Firmware
Devices with the latest available firmware version:
 • Prometheus
 • Prometheus IOTA Config
 • System Firmware
╔══════════════════════════════════════════════════════════════════════════════╗
║ 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…             [***************************************]
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 [af79b14064601bc0987d4747af1e914a228c05d622ceda03b7a4f67014fee868] is present in dbx

How to proceed? I'm guessing /boot/efi/EFI/BOOT/BOOTX64.EFI needs to be replaced. Shall I pull it from latest debian installation image? Is that the only file that should be replaced? What's the chance for bricking the system?

$ uname -a
Linux p14s 6.1.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) x86_64 GNU/Linux
$ sudo tree /boot/efi/
/boot/efi/
└── EFI
    ├── BOOT
    │   ├── BOOTX64.EFI
    │   ├── fbx64.efi
    │   └── grubx64.efi
    └── debian
        ├── BOOTX64.CSV
        ├── fbx64.efi
        ├── fw
        │   └── fwupd-01453b71-da0c-4832-9f4f-e378245339c7.cap
        ├── fwupdx64.efi
        ├── grub.cfg
        ├── grubx64.efi
        ├── mmx64.efi
        └── shimx64.efi

Edit:

$ sudo efibootmgr -v | grep "Boot$(sudo efibootmgr -v | awk '/BootCurrent/{print $2}')"
Boot0000* debian    HD(1,GPT,488c1b76-c8f0-4e08-a48d-d4a0a3a4fa81,0x800,0x106000)/File(\EFI\debian\shimx64.efi)

Note File(\EFI\debian\shimx64.efi) -- does this imply the file /boot/efi/EFI/BOOT/BOOTX64.EFI fwupdmgr complained about is not even used?

3
  • Yes, /boot/efi/EFI/BOOT/BOOTX64.EFI is the fallback EFI, used on USB disks for example. Mine seems to be from my Windows installation, but it's also not used.
    – Freddy
    Jan 27, 2023 at 19:04
  • @Freddy any idea what the correct course of action is here - remove the file altogether?
    – laur
    Jan 27, 2023 at 19:05
  • Other people just moved/deleted the file, e.g. here and I would do the same. Sounds to me that booting with secure boot enabled will fail on such EFIs in future. Do you care about that? Have a look at it (xxd, hexdump), check its timestamp, maybe you can find out where it came from and then decide what to do.
    – Freddy
    Jan 27, 2023 at 19:27

0

You must log in to answer this question.

Browse other questions tagged .