UEFI dbx update blocked

Looking at Discover and reading the forum my eye felt on a UEFI dbx update, so I tried to run that update:

Screenshot_20240630_090904

That did not tell me too much, I did re-install Tumbleweed a few weeks ago and zypper is up-to-date.

Did some searching and it looks to me like Discover is trying to run:

> sudo fwupdmgr update
[sudo] password for root: 
Devices with no available firmware updates: 
 • Internal SPI Controller
 • Lexar SSD NM790 2TB
 • System Firmware
╔══════════════════════════════════════════════════════════════════════════════╗
║ Upgrade UEFI dbx from 83 to 371?                                             ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ Insecure versions of the Microsoft Windows boot manager affected by Black    ║
║ Lotus were added to the list of forbidden signatures due to a discovered     ║
║ security problem.This updates the dbx to the latest release from Microsoft.  ║
║                                                                              ║
║ 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.Applying this update may also cause     ║
║ some Windows install media to not start correctly.                           ║
║                                                                              ║
╚══════════════════════════════════════════════════════════════════════════════╝
Perform operation? [Y|n]: Y
Decompressing…           [                                       ]
Blocked executable in the ESP, ensure grub and shim are up to date:
/run/media/root/B462-25D0/EFI/boot/bootx64.efi Authenticode checksum [f5e892dd6ec4c2defa4a495c09219b621379b64da3d1b2e34adf4b5f1102bd39]
is present in dbx

Then I found:

In particular:

In other words, the /boot/ partition is shared among all the OSes installed on your machine. When installing a new OS, you will typically get a new directory added to /boot/efi/EFI/ for that new OS. Cleaning up older directories for OSes you don’t use any longer is up to you. Keeping all the OSes you do use up to date is up to you. If your firmware update is blocked, delete any sub-directories of OSes you no longer use, and get updates for the OSes that need it.

New install where /boot and /boot/EFI were reformatted so strange. Did check:

> sudo tree /boot/efi/
/boot/efi/
└── EFI
    ├── boot
    │   ├── bootx64.efi
    │   ├── fallback.efi
    │   └── MokManager.efi
    └── opensuse
        ├── boot.csv
        ├── grub.cfg
        ├── grub.efi
        ├── grubx64.efi
        ├── MokManager.efi
        └── shim.efi

And all files have the timestamp of “Jun 13 23:09”, the time when I did the reinstall.

The error is complaining about bootx64.efi so looks to me I should remove the /boot/efi/EFI/boot directory. But why did the install create that and is that the right conclusion?

NB: I am aware that this likely is not a too important update, it looks to me it is the revocation list so leaving it like it is is for sure an option.

It shows you the path to the EFI binary that will be blacklisted by this update. What else do you expect?

Thanks, did not read that that way reading it the first time but that was only the first step.

Question is how it comes that with a relative new fresh install I do run into this problem having this insecure version of EFI/boot/bootx64.efi. Are others running into this problem?

You could start with checking what is mounted on /run/media/root/B462-25D0. Which is apparently FAT judging by UUID and so is not related to your fresh installation in any way.

It looks to me fwupdmgr is mounting things at /run/media/root and this is just my /boot/efi partition that was freshly installed:

> lsblk -o +UUID
NAME          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS UUID
nvme1n1       259:6    0   1.9T  0 disk              
├─nvme1n1p1   259:7    0     1G  0 part  /boot/efi   C2F2-CC15
├─nvme1n1p2   259:8    0     1G  0 part  /boot       4b1c6b4c-5a07-4999-a57c-7408dc41d759
├─nvme1n1p3   259:9    0   100G  0 part  /           f7bacc2f-c6f0-486f-a938-265d373f06d70
├─nvme1n1p4   259:10   0   150G  0 part  /data       518a7edf-bfeb-4007-b134-6d519211dcd5
└─nvme1n1p5   259:11   0   1.5T  0 part              55924092-a152-4bb6-9735-3aaf5cae7ce5
  └─cr-auto-1 254:0    0   1.5T  0 crypt /home       194a3739-c5aa-45bc-8550-17ec8e081597

May be. Now find out what these things are.

I accidentally jumped into the TW section and noticed this post.

I showed the same experience here (link below) … but I had no problem with updating my UEFI dbx update.

(I’ve moved from using TW to Leap 15.6)

UEFI dbx update on my ASUS desktop

I did list what is my /boot/efi above and I am 99% sure fwupdmgr is reporting the problem for:

> ls -l /boot/efi/EFI/boot/bootx64.efi 
-rwxr-xr-x 1 root root 934024 Jun 13 23:09 /boot/efi/EFI/boot/bootx64.efi

“sudo fwupdmgr get-history” gives some additional details:

Update Error: Blocked executable in the ESP, ensure grub and shim are up to date: /run/media/root/B462-25D0/EFI/boot/bootx64.efi Authenticode checksum [f5e892dd…<snip>…f4b5f1102bd39] is present in dbx.

But I see no easy way (yet) to calculate this Authenticode checksum myself for /boot/efi/EFI/boot/bootx64.efi, with it would be possible to know 100% sure fwupdmgr is referring /boot/efi/EFI/boot/bootx64.efi

@aggie: That is the post that make me look at this.

1 Like

That’s not how you troubleshoot problems. You troubleshoot problems by analyzing facts and comparing these facts with your hypothesis. In this case facts are filesystem UUID and authenticode. Neither of which match /boot/efi/EFI/boot/bootx64.efi.

bor@uefi:~> ll /boot/efi/EFI/boot/bootx64.efi
-rwxr-xr-x 1 root root 934024 Jun 21 11:20 /boot/efi/EFI/boot/bootx64.efi
bor@uefi:~> sha256sum /boot/efi/EFI/boot/bootx64.efi
5acea78ea3b73d67039e6feb1e0465e7291b999066f3fbe923f58c58e78d1ea7  /boot/efi/EFI/boot/bootx64.efi
bor@uefi:~> pesign -h -i /boot/efi/EFI/boot/bootx64.efi
8f2dec2046713748a977819950390a46565e635fb1d959b166775037c69d2060 /boot/efi/EFI/boot/bootx64.efi
bor@uefi:~> 

The last line shows the authenticode of the current Tumbleweed shim.

That for sharing the checksum for /boot/efi/EFI/boot/bootx64.efi and yes, these match mine.

So yes, I made an error, I should have seen that the UUID that fwupdmgr was showing (B462-25D0) is not matching the UUID of my /boot/efi, C2F2-CC15

Did some digging and found this B462-25D0 is on a backup disk I do not have always mounted at least not when doing the lsblk. So, thanks, problem solved!

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.