6

I'm having this issue for a few months now...I was using fedora for a long time but it broke after an update and since then I can't install or run a live environment of almost no distro...so far only Linux mint will boot into the live environment but when I install it I get the same error at bootup and the PC turns off. I've tried other distros but no luck. I'm stuck on windows for the time being.

The error(s):

Could not create MokListRT: Volume Full

Could not create MokListXRT: Volume Full

Could not create SbatLevelRT: Volume Full

Could not create MokListTrustedRT: Volume Full

Something has gone seriously wrong: import_mok_state() failed: Volume Full

I would really appreciate any help with this issue

Improve this question

5 Answers 5

Reset to default
11

The solution for me was clearing the EFI variables and then disabling secure boot.

On my Asus X556 laptop, I followed the following steps, but they'll vary for each computer:

  • Press F2 during boot to enter the BIOS
  • Press F7 to enabled Advanced Mode
  • Security > Secure Boot > Secure Boot Control: Enabled. You need to enable Secure Boot to access the key management.
  • Security > Secure Boot > Key Management: Reset to Setup Mode to clear all the variables and keys. It should show "No Key" multiple times.
  • Security > Secure Boot > Secure Boot Control: Disabled. Secure boot must be disabled because there are no valid keys.
  • Save and exit

The message "could not create moklistrt volume full" means that the CMOS memory are reserved for EFI signatures (allowed OS and forbidden OSs) is full and Linux cannot add its own signature. This happens not so rarely as Windows updates and Bios updates often add new entries. My way to solve the problem was to enter in BIOS, Security, Safe boot. manage keys and delete a few entries in the "forbidden" list only. Thise made room in the moklist for the new Linux keys

Improve this answer
1
  • 1
    This answer worked on the UEFI of an ASUS UX330C laptop. Thank you for sharing this answer. Commented Sep 29, 2024 at 11:17
2

The errors indicate the UEFI NVRAM that is used to store UEFI boot variables and other firmware settings seems to be full.

Run sudo efibootmgr -v: if it displays a large number of obsolete boot entries (i.e. referring to disks or operating systems you no longer have installed), use sudo efibootmgr -B -b <XXXX> to delete them. Replace <XXXX> with the number of the BootXXXX boot entry you wish to delete.

If there are no obsolete boot entries, see if sudo ls /sys/firmware/efi/efivars/dump-* produces any output. If it does, you may have had the efi-pstore kernel module enabled at some point, and any system crashes have caused the dmesg output at the time of the crash to be stored in the NVRAM.

If the efi-pstore module is still active and your system includes the systemd service systemd-pstore.service, then you may be able to access the dump(s) as regular files in /sys/fs/pstore/. If so, see if they contain anything important to you: move them elsewhere if you need them, or delete if you don't. If they contain information about old system crashes that are no longer relevant to your current system configuration, delete them to free up the very limited UEFI NVRAM space.

For more info on pstore and its use in storing dmesg output on system crashes, see: https://blogs.oracle.com/linux/post/pstore-linux-kernel-persistent-storage-file-system

If /sys/firmware/efi/efivars/dump-* files exist but your current Linux distribution does not include the pstore system, then you should be able to delete those files directly in the /sys/firmware/efi/efivars/ directory too; there may just be more files to delete, as a single file in pstore may be split into multiple UEFI variables because of size limitations.

Improve this answer
2
  • I followed your steps. I have not extra boot entry, sudo ls /sys/firmware/efi/efivars/dump-* does not return any file. I have a fresh install of Kubuntu (yesterday) and the problem is still here. I have 371 dbx entries and each time I delete them, they reappear after reboot. I have no dual boot. Any other option than disabling the secure boot? Commented Jul 6, 2024 at 14:41
  • 1
    @Thombou 371 dbx entries seems about right or even a bit on the low side (my system has 423 dbx entries right now), however most of those should be sha256 entries that won't take too much space. But if there is nothing obvious hogging your NVRAM space, it is possible that your system model has an exceptionally small NVRAM space for some reason (early UEFI system?). If so, you might have to disable Secure Boot. Reinstalling the OS won't clear the NVRAM space. Resetting the BIOS settings to defaults might or might not also clear the UEFI NVRAM as a side effect, depending on implementation. Commented Jul 8, 2024 at 18:20
0

On my Asus Q534U laptop, I just purged the denied key list. Had to guess how to get into BIOS...

  1. Powered up
  2. Kept hitting ESC, F1, F2, and F12 until I got either a menu or wound up in BIOS
  3. Pressed F7 to get into advanced mode
  4. Right-arrowed to "Security" and selected "Secure boot"
  5. Selected "Key Management"
  6. Selected "Forbidden Signatures"
  7. Selected "Delete Var" and answered yes to "Confirm deletion of 'dbx' from NVRAM.
  8. Saved the changes.
  9. Rebooted and was able to get my Ubuntu 24.04.1 live USB to start.

Seriously the long way around... On my Lenovo work laptop, I found that Canonical's signing key was in the forbidden list, but at least Lenovo's key management allowed me to remove ONE key from the list instead of needing me to wipe them all.

Improve this answer
3
  • The list of denied keys exists for a reason. By clearing it you allow for booting potentially compromised software. Commented Dec 2 at 12:40
  • Well, given that you're talking about a physical access issue... ANd the face that the Ubuntu 24.04.1 live USB key was on that list... Yeah, I'm pretty sure it was there to prevent booting non-MS OS's... Commented Dec 5 at 22:31
  • I am not going to discuss some conspiracy nonsense. In any case, a particular entry should be removed if needed, not the entire list cleared. Don't advise things you don't understand. Commented Dec 6 at 7:32
0

I struggled for a day on trying to resolve the MokList error while following the instructions. On the second day after some research, I did follow the instructions to a point. The point where only the forbidden keys were deleted. After that a clean boot. Would like to add, I am using a 14" Gateway which originally had Windows. Windows was wiped and Bookworm was installed.

Improve this answer
1
  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center. Commented Jul 12 at 16:32
-1

as explained in askubuntu, disabling secureboot should fix that if for some reason you still need it, you will need to install sbctl go install github.com/foxboron/sbctl/cmd/sbctl@latest $(go env GOPATH)/bin/sbctl then follow the upstream instructions to enable it, then re enable it in your bios.

Improve this answer
1
  • Thank you for your answer :) Unfortunately disabling secure boot didn't help as I've already had it disabled before this happened. I've played around in the UEFI and for some reason restoring secure boot variables to their default values made a difference I can now boot Debian installer (didn't try others yet). I'll see if the issue is still present after installation because I could boot mint live and install it but couldn't boot when it was installed Commented Apr 10, 2024 at 8:03

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.