Secure Boot dbx update?

And interestingly, even I delete the Boot option from the UEFI FMW settings it still appears in there after I re-open it. But it does not show up on the GRUB menu. I believe there’s some windows code left in the EFI that is messing my system.

Fresh install did not work. I am still getting the same error.

That shouldn’t be necessary.

Gnome Software won’t do it any better, it uses fwupdmgr. If update succeeded, it won’t be bugging you until new dbx is released.
dbxtool -l will list content of your UEFI dbx, version 217 has 268 entries, so you’ll know whether it’s updated.

Formatting/recreating EFI partition and reinstalling Fedora should have cleaned that up (so would removing windows files and regenerating grub config). After that, removing windows entry in UEFI setting should work.

Have you tried that in grub console?

What TPM settings do you have in BIOS?

1 Like

Sadly. I already did…I thought maybe it would change the EFI file system and the problem will be solved.

It was gone but now it has re-appeared. I don’t know what’s wrong…

No, I have not. Instead, I disabled the SB. And it worked…Now I can boot without an error.

Also dbxtool -l shows 268 lines. So it’s seems upgrade was successful, however I cannot use SB so I don’t know what was the point of this update…

The point of dbx is to block you from using an old shim and/or grub2 version which could contain the “boot-hole” bug.

After searching the error online, I find this post from a couple of months ago.

Which is the same error as I have seen (see post 7/8)

In this page

It says

Some specific systems (listed in upstream thread at Re: [PATCH] tpm: Pass unknown error as non-fatal, but debug print the er).

Mostly ASUS systems, but also reported on some Dell systems.

The affected systems are used to boot in UEFI mode and will fail to write measurements to the possible onboard TPM, causing failure to boot.

And my computer is ASUS

From the comments, it seems that most people solved the problem by disabling either TPM or Secure Boot. Maybe disabling TPM is better than disabling SB? Should I try to disable TPM instead of SB?

Also, this bug report is from Ubuntu. Can it be solved in Fedora as well, so that someone does not need to disable one of them…

So it has not much to do with the SB ?

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.
https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader/

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