F38 Secure Boot dbx Configuration Update Error

Ask Fedora
,
1

Installing the update from 77 → 371 results in the following error

with Secure Boot on :

Could not create MokListRT : Volume Full
Could not create MokListXRT : Volume Full
Could not creat SbatLevellRT : Volume Full
Could not create MokListTrustedRT : Volume Full
Something has gone seriously wrong : import_mok_state() failed : Volume Full,

and SB off TPM on:

…/…/grub-core/commands/efi/tpm.c:150:Unknown TPM error.
…/…/grub-core/commands/efi/tpm.c:150:Unknown TPM error.
…

I was able to boot again by first disabling tpm and change the secure boot from HP Keys to Custom Keys, and then boot again with TPM enabled and Secure Boot enabled with HP Keys,
By doing that the update in Gnome Software appeard again.

Info:
PC : HP 870-008np (OMEN by HP Desktop PC - 870-008np (ENERGY STAR) Product Specifications | HP® Customer Support)
BIOS Version : A0.59
Boot : EFI

2

What is the output of efibootmgr? Please post that here so we may see the results.

We have seen similar errors when the user had many many boot entries in the system and once they cleared out all but the few entries that were actually necessary the problem went away.

I suspect it is because the bios nvram has limited space and when it fills up can no longer store more data.

3

Thank you for the reply, I saw some posts that said the same thing but was not sure which of this boot sources were necessary

efibootmgr output :

BootCurrent: 0008
Timeout: 0 seconds
BootOrder: 0008,000B,0003,0002,0004,0005,0006,0007
Boot0002* USB Floppy/CD VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0500000001)0000424f
Boot0003* USB Hard Drive VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0200000001)0000424f
Boot0004* ATAPI CD-ROM Drive VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0300000001)0000424f
Boot0005* UEFI: IPv4 Realtek PCIe GBE Family Controller PciRoot(0x0)/Pci(0x1c,0x6)/Pci(0x0,0x0)/MAC(c07cd1fb80af,0)/IPv4(0.0.0.00.0.0.0,0,0)0000424f
Boot0006* UEFI: IPv6 Realtek PCIe GBE Family Controller PciRoot(0x0)/Pci(0x1c,0x6)/Pci(0x0,0x0)/MAC(c07cd1fb80af,0)/IPv6([::]:<->[::]:,0,0)0000424f
Boot0007 Fake Legacy Option VenMedia(b6fef66f-1495-4584-a836-3492d1984a8d,0600000000)0000424f
Boot0008* Fedora HD(1,GPT,321dc2a9-78fb-4527-857b-253d56d6ae66,0x800,0x12c000)/File(\EFI\FEDORA\SHIMX64.EFI)
Boot000B* Fedora HD(1,GPT,321dc2a9-78fb-4527-857b-253d56d6ae66,0x800,0x12c000)/File(\EFI\FEDORA\SHIM.EFI)

4

Looking at that I would guess that nothing related to VenMedia is necessary since fedora is on Boot0008 and Boot000B.

5

I managed to remove Boot5 and Boot6 by disabling Network Boot, but the others keep reappearing every time I disable them using efibootmgr -b <value> -B even if I disable them in the BIOS.

6

These are actually built-in entries. One of them can boot from the disk device using the default entry EFI/BOOT/BOOTX64.EFI. That is the socalled fall back entry. If you connect a bootable USB device, you will get another entry for that device, which you will use to boot from it.

Entry Boot000B is a duplicate entry which would do the same as Boot0008.

Apart from that, when the number of boot entries becomes a problem is when you have perhaps 50 to 100 entries, which is that the case here.

In general, the DBX entries are problem waiting to happen. The amount of space available for DBX entries is limited, and with the speed of Microsoft creating new entries, we will run out of space. And, yes, the DBX comes from Microsoft and is the list of EFI files signed by Microsoft and which turned out to be problematic, so these should be blacklisted.

1 Like