Secure Boot dbx update?

Disabling TPM or SecureBoot is definitely a workaround.

Why that happened after dbx update? :thinking:
New entries filled some memory?
Something got blocked? You could compare hashes from dbxtool -l with find /boot/ -type f -exec sha256sum {} \; (for example using conditional formatting of duplicates in LibreOffice Calc).

If you don’t have your data on disk and in TPM, you could try restoring BIOS to defaults, purging TPM memory and formatting disk, to get rid of old windows leftovers.
Do you have any BIOS updates available?

I guess disabling TPM is better than disabling SB…? How can I perform those steps ? I really want to get rid of the old windows leftovers. How can I check my BIOS updates ?

I’ ll try that.

In BIOS, if manufacturer facilitates such settings.

On your manufacturer drivers’ page for your laptop model (unfortunately ASUS doesn’t provide BIOS updates through fwupd yet).

1 Like

I see…I guess I ll leave it like this for now…but thanks for the help.

To remove the windows boot manager from grub you need to delete the /boot/efi/EFI/Microsoft directory on your running system then update grub with grub2-mkconfig -o /boot/grub2/grub.cfg . This removes the windows boot loader and once it is removed then grub will no longer put it into the menu. Both steps are required to completely remove windows from grub.

1 Like

okay, thanks a lot. One last question. Does grub2-mkconfig -o /boot/grub2/grub.cfg applies to both UEFI and BIOS or for every type of computer etc. Or it depends from computer to computer ?

This is the official fedora documentation on using grub. Yes it does apply to all systems, both uefi and bios, and has since fedora 34 was released in April 2021.

I do not know first hand about ostree based systems, but it does apply to all the standard rpm based systems.

1 Like

okay, thanks again :slight_smile:

If you click on the update there’s an explanation of what the problem is. The file /boot/efi/EFI/BOOT/BOOTX64.EFI is on the forbidden signature list contained in this update. The updater refuses to install the update under these conditions so it’s best to leave things alone until a package update addresses the issue.

2 Likes

I clicked on the update but did not notice that. But I have already installed so…I hope it’s not too bad.

I guess it’s possible to perform the update by disabling SB (Since by disabling SB I manage to boot my system)

EFI/BOOT/BOOTX64.EFI is a copy of EFI/fedora/shim.efi

[root@newbox ~]# . /tmp/11
Files /boot/efi/EFI/BOOT/BOOTX64.EFI and /boot/efi/EFI/fedora/shim.efi are identical
Files /boot/efi/EFI/BOOT/BOOTX64.EFI and /boot/efi/EFI/fedora/shimx64.efi are identical
[root@newbox ~]# 

So if that file is forbidden then shim.efi would be forbidden as well. Actually, old versions of shim.efi are forbidden due to the boot-hole issue. And I would assume that MS-windows would install a BOOTX64.EFI as a copy of the windows boot manager.

The output from attempted dbx update:
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 [0ce02100f67c7ef85f4eed368f02bf7092380a3c23ca91fd7f19430d94b00c19] is present in dbx

This is the case just for your computer. Here’s how to check what provides this file:

$ dnf -C provides /boot/efi/EFI/BOOT/BOOTX64.EFI
shim-x64-15.4-5.x86_64 : First-stage UEFI bootloader
Repozytorium       : fedora
Dopasowano z:
Nazwa pliku : /boot/efi/EFI/BOOT/BOOTX64.EFI

shim-x64-15.6-2.x86_64 : First-stage UEFI bootloader
Repozytorium       : @System
Dopasowano z:
Nazwa pliku : /boot/efi/EFI/BOOT/BOOTX64.EFI

shim-x64-15.6-2.x86_64 : First-stage UEFI bootloader
Repozytorium       : updates
Dopasowano z:
Nazwa pliku : /boot/efi/EFI/BOOT/BOOTX64.EFI

This shows you which version you’re using and some information about the file [like modification/creation time, to figure out how long has it (probably) been there]:

dnf list installed shim-x64
sudo stat /boot/efi/EFI/BOOT/BOOTX64.EFI

You’ll probably have to upgrade to non-EOL Fedora version (35 or 36) or update your system:

sudo dnf dsync
sudo dnf reinstall shim-x64

If you read my post, it indicates the reason the update installation was refused. Which package provides the offending file is immaterial and my situation is unlikely to be unique.

My advice stands that, as fwupd has determined the update is not safe, it should not be forcefully applied as it could lead to undesired consequences.

As for your advice to use a non-EOL version of fedora, and how to update the packages, you are making a big assumption. I am running Silverblue 36 and your suggestions are not applicable.

I uderstood your posts. I’m running regular F36 and updated without any issues (and I’m not the only one) i.e. installing current F36 package providing this file should overwrite it and allow you to safely upgrade dbx database. Hence my assumption that you are either on EOL system, should upgrade your system or reinstall shim-x64 (to overwrite offending file, it might have been swapped by other system or someone else). Since you’re using Silverblue, update it accordingly.

That’s exactly why fwupdmgr, before UEFI dbx update, checks whether installing it could block some file on current computer and render it unbootable. In that case the update won’t get installed and user will see why, like you did:

In your case the file can be overwritten by update or re-installation of shim-x64, in other cases that might be file provided by grub2 (so update/reinstall grub2*). Sometimes a file not related to Fedora could turn out to be blacklisted - then it needs to be updated in corresponding system or removed (if it’s just a leftover from old installation).
Commands I provided before shows, step by step, how to determine which case it is.

Hi @ozeszty
This thread has got remarkably busy which i thought it would:)
Do i take it i just have to wait for the update to come through to Fedora 36?

Hi, this thread turned out unrelated to your issue.
It should be split in two, but I don’t have such permissions.

1 Like

My issue looks fixed after an update this morning :slight_smile:
Thanks to everybody for help and fixing it

@osopolar Lucky you.

I also applied the fwupd update from GNOME software but I still cannot install the Secure Boot dbx Configuration Update.

sudo fwupdmgr refresh ; sudo fwupdmgr get-updates gives me this output:

WARNING: UEFI ESP partition not detected or configured
See PluginFlag:esp not found · fwupd/fwupd Wiki · GitHub for more information.
Firmware metadata last refresh: 23 minutes ago. Use --force to refresh again.
WARNING: UEFI ESP partition not detected or configured
See PluginFlag:esp not found · fwupd/fwupd Wiki · GitHub for more information.
Devices with no available firmware updates:
• System Firmware
• WD Blue SN570 1TB


Devices that were not updated correctly:

• UEFI dbx (77 → 217)

I also ran sudo /usr/bin/fwupdtool esp-list --verbose and got this:

18:30:01:0709 FuDebug Verbose debugging enabled (on console 1)
18:30:01:0713 FuVolume device /org/freedesktop/UDisks2/block_devices/nvme0n1p2, type: 0x83, internal: 1, fs: ext4
18:30:01:0714 FuVolume device /org/freedesktop/UDisks2/block_devices/nvme0n1p3, type: 0x83, internal: 1, fs: btrfs
18:30:01:0715 FuVolume device /org/freedesktop/UDisks2/block_devices/nvme0n1p1, type: 0x0c, internal: 1, fs: vfat
18:30:01:0715 FuContext no volumes of type c12a7328-f81f-11d2-ba4b-00a0c93ec93b
18:30:01:0718 FuVolume device /org/freedesktop/UDisks2/block_devices/nvme0n1p2, type: 0x83, internal: 1, fs: ext4
18:30:01:0719 FuVolume device /org/freedesktop/UDisks2/block_devices/nvme0n1p3, type: 0x83, internal: 1, fs: btrfs
18:30:01:0720 FuVolume device /org/freedesktop/UDisks2/block_devices/nvme0n1p1, type: 0x0c, internal: 1, fs: vfat
18:30:01:0720 FuContext no volumes of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
No ESP or BDP found

I think it is pretty evident that I am a noob so I would appreciate any advice from more experienced users.

It seems you are booting in legacy (MBR) mode and thus have no efi partition and possibly only legacy BIOS instead of UEFI bios.

That seems weird since the output posted shows nvme0n1p1 as vfat.

On my system I see this

# /usr/bin/fwupdtool esp-list --verbose
18:56:44:0021 FuDebug              Verbose debugging enabled (on console 1)
18:56:44:0035 FuVolume             device /org/freedesktop/UDisks2/block_devices/sda3, type: e6d6d379-f507-44c2-a23c-238f2a3df928, internal: 1, fs: LVM2_member
18:56:44:0038 FuVolume             device /org/freedesktop/UDisks2/block_devices/sdc1, type: 0fc63daf-8483-4772-8e79-3d69d8477de4, internal: 1, fs: ext4
18:56:44:0039 FuVolume             device /org/freedesktop/UDisks2/block_devices/sda2, type: 0fc63daf-8483-4772-8e79-3d69d8477de4, internal: 1, fs: ext4
18:56:44:0043 FuVolume             device /org/freedesktop/UDisks2/block_devices/sda1, type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b, internal: 1, fs: vfat
18:56:44:0054 FuVolume             device /org/freedesktop/UDisks2/block_devices/sda3, type: e6d6d379-f507-44c2-a23c-238f2a3df928, internal: 1, fs: LVM2_member
18:56:44:0057 FuVolume             device /org/freedesktop/UDisks2/block_devices/sdc1, type: 0fc63daf-8483-4772-8e79-3d69d8477de4, internal: 1, fs: ext4
18:56:44:0059 FuVolume             device /org/freedesktop/UDisks2/block_devices/sda2, type: 0fc63daf-8483-4772-8e79-3d69d8477de4, internal: 1, fs: ext4
18:56:44:0061 FuVolume             device /org/freedesktop/UDisks2/block_devices/sda1, type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b, internal: 1, fs: vfat
18:56:44:0063 FuContext            no volumes of type ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
Selected volume: /org/freedesktop/UDisks2/block_devices/sda1
/boot/efi/EFI/BOOT/BOOTX64.EFI
/boot/efi/EFI/BOOT/fbx64.efi
/boot/efi/EFI/BOOT/BOOTIA32.EFI
/boot/efi/EFI/BOOT/fbia32.efi
/boot/efi/EFI/fedora/BOOTX64.CSV
/boot/efi/EFI/fedora/mmx64.efi
/boot/efi/EFI/fedora/shim.efi
/boot/efi/EFI/fedora/shimx64.efi
/boot/efi/EFI/fedora/BOOTIA32.CSV
/boot/efi/EFI/fedora/mmia32.efi
/boot/efi/EFI/fedora/shimia32.efi
/boot/efi/EFI/fedora/grub.cfg
/boot/efi/EFI/fedora/gcdx64.efi
/boot/efi/EFI/fedora/grubx64.efi
/boot/efi/EFI/fedora/gcdia32.efi
/boot/efi/EFI/fedora/grubia32.efi
/boot/efi/System/Library/CoreServices/SystemVersion.plist
/boot/efi/mach_kernel

Your issue seems different than the OP and this thread is already marked as solved, so please create a new thread about your issue.