Update caused new error message (secure boot)

Ask Fedora
,
1

Recently updated Fedora 39 system. Made me restart and after updating I get a new error message during boot:

Could not create MokListRT: Invalid Parameter
Could not create MokListXRT: Invalid Parameter
Importing MOK states has failed: import_mok_state() failed: Invalid Parameter
Continuing boot since secure mode is disabled

I can still boot and never use secure mode since I dont own a tpm module.

2

You said you just updated then this started?

Fedora installs the mokutil package by default, and I suspect that error is related to the fact that secure boot is disabled. The tpm module is included in newer laptops and desktops that are intended to run windows 11 since that is one major requirement for win11. For fedora tpm is (AFAIK) not required

According to my system mokutil has not been updated since F39 was released and I don’t understand why there would be a change giving those errors. Maybe something else has happened with the update.

You might try using sudo dnf distro-sync --refresh on the command line to ensure everything is up to date, then reboot.

3

Where do you see these errors?

4

mokutil-2:0.6.0-7.fc39.x86_64 is already installed
distro-sync --refresh did not fix it.

I see the errors when I boot, before GRUB. Sometimes I see grub, sometimes I just see the error messages and I dont see the GRUB menu.

5

Can you check:
sudo dnf history info last

Thanks

6 
Packages Altered:
    Upgrade  ansible-srpm-macros-1-12.fc39.noarch    @updates
    Upgrade  bind-libs-32:9.18.24-1.fc39.x86_64      @updates
    Upgrade  bind-license-32:9.18.24-1.fc39.noarch   @updates
    Upgrade  bind-utils-32:9.18.24-1.fc39.x86_64     @updates
    Upgrade  cups-browsed-1:2.0.0-4.fc39.x86_64      @updates
    Upgrade  dnsmasq-2.90-1.fc39.x86_64              @updates
    Upgrade  ibus-1.5.29-1.fc39.x86_64               @updates
    Upgrade  ibus-gtk3-1.5.29-1.fc39.x86_64          @updates
    Upgrade  ibus-gtk4-1.5.29-1.fc39.x86_64          @updates
    Upgrade  ibus-libs-1.5.29-1.fc39.x86_64          @updates
    Upgrade  ibus-setup-1.5.29-1.fc39.noarch         @updates
    Upgrade  python3-unbound-1.19.1-2.fc39.x86_64    @updates
    Upgrade  qt5-qtbase-5.15.12-5.fc39.x86_64        @updates
    Upgrade  qt5-qtbase-common-5.15.12-5.fc39.noarch @updates
    Upgrade  qt5-qtbase-gui-5.15.12-5.fc39.x86_64    @updates
    Upgrade  skopeo-1:1.14.2-1.fc39.x86_64           @updates
    Upgrade  unbound-anchor-1.19.1-2.fc39.x86_64     @updates
    Upgrade  unbound-libs-1.19.1-2.fc39.x86_64       @updates
    Upgrade  vim-data-2:9.1.113-1.fc39.noarch        @updates
    Upgrade  vim-minimal-2:9.1.113-1.fc39.x86_64     @updates
    Upgraded ansible-srpm-macros-1-11.fc39.noarch    @@System
    Upgraded bind-libs-32:9.18.21-2.fc39.x86_64      @@System
    Upgraded bind-license-32:9.18.21-2.fc39.noarch   @@System
    Upgraded bind-utils-32:9.18.21-2.fc39.x86_64     @@System
    Upgraded cups-browsed-1:2.0.0-1.fc39.x86_64      @@System
    Upgraded dnsmasq-2.89-7.fc39.x86_64              @@System
    Upgraded ibus-1.5.29~rc2-6.fc39.x86_64           @@System
    Upgraded ibus-gtk3-1.5.29~rc2-6.fc39.x86_64      @@System
    Upgraded ibus-gtk4-1.5.29~rc2-6.fc39.x86_64      @@System
    Upgraded ibus-libs-1.5.29~rc2-6.fc39.x86_64      @@System
    Upgraded ibus-setup-1.5.29~rc2-6.fc39.noarch     @@System
    Upgraded python3-unbound-1.19.0-7.fc39.x86_64    @@System
    Upgraded qt5-qtbase-5.15.12-1.fc39.x86_64        @@System
    Upgraded qt5-qtbase-common-5.15.12-1.fc39.noarch @@System
    Upgraded qt5-qtbase-gui-5.15.12-1.fc39.x86_64    @@System
    Upgraded skopeo-1:1.14.0-1.fc39.x86_64           @@System
    Upgraded unbound-anchor-1.19.0-7.fc39.x86_64     @@System
    Upgraded unbound-libs-1.19.0-7.fc39.x86_64       @@System
    Upgraded vim-data-2:9.1.076-2.fc39.noarch        @@System
    Upgraded vim-minimal-2:9.1.076-2.fc39.x86_64     @@System
7

That message comes from shim and indicates trouble reading the installed mok certificates.

It is possible that the non-volatile memory of the UEFI firmware is failing, or perhaps it has run out out of space, for example by a recent dbx update or too many entries in the boot list.

8

If this is the case then following the motherboards procedure to reset uefi nvram might fix things.
I have uefi memory issues happen a long time ago and used the reset procedure to fix it.

9

Good point, Barry. Ill try resetting the motherboard’s nvram. I cleared cmos a few times but that doesnt clearn nvram boot entries. Ive been hopping between a bunch of different linux kernels and my boot list has become very long.

10

Those entries can be managed with the efibootmgr command on fedora, which would not require a full nvram reset.