Couldn't Create Moklist: Volume Full - grub doesn't start at all

Question

So, I've been dual booting Kubuntu and Windows 10. I've been mainly trying to use only linux, but still logged into Windows 10 once in a while to use my paid for daw or davinci resolve, etc. BUT !!!

The last time I logged into Windows 10 and then restarted my computer I got an error message instead of the grub boot loader (I didn't change anything in my bios settings). The error I get is "Couldn't Create Moklist: Volume Full , Something serious has gone wrong, import_mok_state():failed".

Not only can I not log into the Kubuntu installed on my laptop, but I can't log in using a Kubuntu Live USB or a RedHat Live USB. I tried the Kubuntu Live USB on my wifes laptop and it booted up just fine.

Now, I can boot up a Live USB of Slax linux. And, I can change the bios to boot to the Windows 10 partition, but... unfortunately, that's about it.

So... hoping someone might be able to help out this somewhat linux newbie.

P.S. - I even restored everything with an image I made just a couple days ago, but that didn't work either.

START UPDATE 1......................................................

I can look at the efi folder using Slax.

efi/ubuntu the files are:

• BOOTX64.CSV
• grub.cfg
• grubx64.efi
• mmx64.efi
• shimx64.efi

efi/boot the files are:

• BOOTX64.EFI
• fbx64.efi
• mmx64.efi

efi/microsoft there are two folders:

• Boot folder

• • there are a bunch of folders and files.
• • too many to list.

• Recovery folder

• • BCD
• • BCD.LOG
• • BCD.LOG1
• • BCD.LOG2

My have has the very same laptop I have, so even though I didn't change any bios setting we compared mine to hers (she uses kubuntu only and it's working fine) and they are the same. Well, short of my computer have an nvme drive I upgraded to a while back.

I did system self test under nvme and it passed.

END UPDATE 1........................................................ START UPDATE 2......................................................

On my wife's kubuntu at the moment. After trying everything I could find to try via the web, I decided to use Slax Linux to delete the partitions on my two hard drives, including creating new GPT partition tables. I'm presently doing a fresh install of Windows 10 on the nvme hard drive and it's going thru long process of windows updates.

Once that is down I'll try making a new USB Live and see how that goes.

This really gets me. All was fine. Before this all started, the last time I was logged into Windows 10 it had an update. It just said update ready to install - I installed it - very short update. Could that last windows 10 update have cause this ???

END UPDATE 2........................................................ START UPDATE 3......................................................

Well, even after doing what was stated in UPATE 2 I still can't use any linux other than SLAX linux.

Hopefully someone knows what I need to do to fix this issue.

END UPDATE 3........................................................ START UPDATE 4......................................................

Here a few pictures of my bios. Maybe they might help someone direct in the right direction: https://flic.kr/s/aHBqjzKinq

Also, I deleted all the keys and and now I can get a Mint Linux live usb to boot, but still can't get a Kubuntu live usb to boot (has same MOK issues).

END UPDATE 4......................................................... START UPDATE 5....................................................... !!! I'VE GOT IT WORKING !!!

And, I'm putting up this edit using Kubuntu :)

Fixing the issue.

So, let's first recap...

I had my dual boot Windows 10 & Kubuntu setup working just fine.

I was mainly logging into Windows 10 to use my paid for music DAW's (digital audio workstation's) that I paid for and to use Davinci Resolve (my favorite video editor).

The last time I booted into Windows 10, before all this happened, there was an update (windows 10 update that is) - it just said update ready. So, I installed it and it installed very quickly. When I was done in Windows 10 I rebooted to get back into Kubuntu, but... there was no booting up in it. I kept getting an error pretty close to:

Could not create MokList: Volume Full
Something serious has gone wrong.
import_mok_state() failed.

Not only could I not boot into Kubuntu via hard disk, I also couldn't boot up on a live usb of Kubuntu, RedHat, EndeavorOS, POP OS, Xubuntu, Mint Linux etc. I did find that SLAX would boot up...

After deleting all the keys under secure boot I was able to boot up on a Mint Linux Live USB. So, I tried installing it and got the same error I've been getting, which I thought was weird.

So, after looking around for a couple days I finally found the solution that worked for me and figured I'd share it here.

The solution was efibootmgr and removing old/unused boot entries. I can't explain and have no clue how my Kubuntu could go from working just fine to not working after a very small Windows 10 update (maybe it was just a coincidence), but that's what happened, or at least certainly seems to be what happened, as far as I can tell. Anyways...

Here's the three terminal lines that saved the day for me:

// get efibootmgr
sudo apt-get install efibootmgr
// run efibootmgr
sudo efibootmgr
// remove unused boot entries
sudo efibootmgr -b 0005 -B
Take note that 0005 could be 0004, 0006, etc

And, here are links to the video and an article that gave me the info above:

The video "Fixing EFI Booting Issues with Efibootmgr"

• https://www.youtube.com/watch?v=MN-Q5h2Iv8A

The article "How to Remove Old EFI Boot Entries in Linux"

• https://digitalrobin.net/2020/07/11/how-to-remove-old-efi-boot-entries-in-linux/

When I was watching the video and seen the unused entries the "FULL" part of the error I was getting came to mind, which led to me to finding the article.

So, ya, hopefully this helps someone. It's certainly been a learning curve for me...

Not sure if this is something I should say or not, but, ya know, I'm really beginning to dislike Microsoft more and more as time goes on. If it wasn't for my paid for DAW's and Davinci Resolve I'd probably ditch Microsoft completely (I'm working on - lol)...

END UPDATE 5.........................................................

Answer 1

First, some background: You reported an error message:

Couldn't Create Moklist: Volume Full , Something serious has gone wrong, import_mok_state():failed

This is a reference to a list of Machine Owner Keys (MOKs), which are cryptographic keys that are associated with Shim. Secure Boot requires that boot loaders be signed with a key to verify the binary's authenticity. A few public keys are stored in the computer's firmware or NVRAM; but the only keys guaranteed to be stored in this way belong to Microsoft, which has rules about what it will sign. To make a long story short, most Linux distributions use a program called Shim (shimx64.efi, normally), which is signed by Microsoft and that adds a new key for the Linux distribution that released that version of Shim. Shim can also read new keys that users can store in what's called the MOK list. Much of this data, including the MOK list, is stored in NVRAM.

The error message you report claims "volume full," but that's a confusingly-worded phrase, because the volume in question is almost certainly not a disk partition, but the NVRAM storage, which is very limited in size.

Part of the Secure Boot mechanism involves OS vendors periodically updating another NVRAM-based pool of Secure Boot keys, known as the dbx, which is a list of keys or binary hashes that have been invalidated -- they have known bugs or are known malware, and so should not be loaded. Chances are your Windows update included a dbx update, which probably pushed your NVRAM storage to the limit. One of your screen shots shows a dbx list ("Forbidden signatures") with 77 entries. There may be other things chewing up NVRAM storage, too. EFIs periodically perform "garbage collection" on NVRAM storage to try to clean up old data, but this is done sporadically and isn't guaranteed to help at all.

As with any full or almost-full resource, full NVRAM on an EFI-based computer can have weird results. I can't explain exactly why some of your Linux distributions booted OK but others didn't, but my guess is that it was caused by full or almost-full NVRAM. There are ways to test this hypothesis, but the main way I know to do this is moderately involved and may not be worth the effort.

The boot entries shown in Linux by efibootmgr are also stored in NVRAM, so deleting old/unused entries may have cleared enough space for things to start working. If you've only removed a couple of entries, though, you're probably very close to the edge and may run into problems in the future.

One way you may be able to reduce the risk of running into problems in the future is to disable Secure Boot. By itself, this will not remove the dbx or otherwise reduce the load on NVRAM, but it should at least make it unimportant if a tool can't read or modify the MOK list, since MOKs are used only by Shim (and related tools). Disabling Secure Boot reduces your system's overall security, though -- pre-boot malware will be able to execute without problems, should it get installed.

You can also delete the dbx itself, or overwrite all the keys with ones you create, but that's getting into rather hairy territory -- and removing the dbx will also reduce your system's security (although not by as much as completely disabling Secure Boot).

Answer 2

I have also encountered this problem. "Could not create MokListRT: Volume Full". Impossible to restart on the disk or on my two live USB keys.

Inspired by what I read above, what worked for my Asus :

• Go to Bios (F2 at startup)
• Advanced mode (F7)
• Security tab > Security/Secure Boot > Key Management
• From there, I've deleted all the security keys and reset them to factory settings.

Then I was able to boot on the USB key to reinstall the system. During installation, you need to set a "Secure Boot" password. Which is requested on first reboot. Note that the keyboard is Qwerty at this stage. What is enroll key from disk, enroll hash from disk and enroll Mok after Ubuntu 18.10 installation

Answer 3

Some time ago, I encountered such failure. The good news is I still can boot with Windows Bootmgr (select it in UEFI boot mgr). The problem is something created too many boot entries in my UEFI firmware, and they occupied most of the NVRAM space. So my solution is to delete all these unused boot entries using Windows bcdedit tool.

Fisrt, list all boot entries and find their identifiers:

> bcdedit.exe /enum firmware
....<repeat many times>....
固件应用程序(101fffff)
标识符                  {d75e8a44-0cb7-11ee-8c41-58ce2a1283af}
device                  partition=\Device\HarddiskVolume8
path                    \EFI\BOOT\BOOTX64.EFI
description             UEFI: ST500LM021-1KJ152, Partition 1
固件应用程序(101fffff)
标识符                  {dae32edd-109d-11ee-8c45-58ce2a1283af}
device                  partition=\Device\HarddiskVolume8
description             UEFI: ST500LM021-1KJ152, Partition 1

Then, delete each unused entry one by one:

> bcdedit.exe /delete {d75e8a44-0cb7-11ee-8c41-58ce2a1283af}
操作成功完成。
> bcdedit.exe /delete {dae32edd-109d-11ee-8c45-58ce2a1283af}
操作成功完成。
...

Finally, reboot the machine.

Answer 4

So, after looking around for a couple days I finally found the solution that worked for me and figured I'd share it here.

The solution was efibootmgr and removing old/unused boot entries. I can't explain and have no clue how my Kubuntu could go from working just fine to not working after a very small Windows 10 update (maybe it was just a coincidence), but that's what happened, or at least certainly seems to be what happened, as far as I can tell. Anyways...

Here's the three terminal lines that saved the day for me:

// get efibootmgr sudo apt-get install efibootmgr

// run efibootmgr sudo efibootmgr

// remove unused boot entries sudo efibootmgr -b 0005 -B Take note that 0005 could be 0004, 0006, etc

And, here are links to the video and an article that gave me the info above:

The video "Fixing EFI Booting Issues with Efibootmgr"

https://www.youtube.com/watch?v=MN-Q5h2Iv8A

The article "How to Remove Old EFI Boot Entries in Linux"

https://digitalrobin.net/2020/07/11/how-to-remove-old-efi-boot-entries-in-linux/

When I was watching the video and seen the unused entries the "FULL" part of the error I was getting came to mind, which led to me to finding the article.

So, ya, hopefully this helps someone. It's certainly been a learning curve for me...

Answer 5

The earlier answers are great and helped me fix this problem for a 2016 ASUS laptop. But messing with the BIOS is dangerous so it might help to share some concrete points.

• Deleting all Forbidden Signature keys is the essential step. I had 77 of them. Click on Forbidden Signatures and select Delete, this will delete all of them at once. Use F10 for Save and Exit, reboot, and it should boot up nicely again.

• Trying to boot from a Live USB Stick is useless. You MUST first fix that MokList error message.

• In my case the above fix worked consistently, and there was no need for a Windows or Linux command line tool, or to remove a specific key ID. Because boot was prevented entirely, no windows or linux tool could be used anyway. The BIOS menus where completely sufficient to fix this problem, in my case. If you find that a Windows or Linux tool does work, great, but perhaps our problems are slightly different.

• On my laptop, first I could not find the Secure Boot option. It appeared to be hidden below the window, but scrolling seemed not to work. Instead of scrolling with the Trackpad, scroll with the down-arrow key.

• In the Secure Boot section, I did not see Key Management. To see it, you need to enable Secure Boot, and also to set a User password. You can also set the Admin password instead of the User password, but a User PW is easier to remember because you type it more often :-)

• The problem can come back. In my case, after fixing the problem and seeing that booting Ubuntu from disk worked again, I decided to test my Usb Live stick, so I plugged it in at next boot, and went into the BIOS to change the boot order. Bingo, the error was back, now with something like 437 Invalid Signatures. But now I know how to fix it . . .

• The problem even comes back after just removing the Live Usb Stick in order to revert to normal boot from disk.

• Don't try to turn off (disabling) Secure Boot, as the problem will come back. Interestingly, after that, the User Bios Password prompt will still appear. But worse, you need to have Secure Boot enabled for access to the Key Management to fix the problem. What you can try is to set an empty BIOS Password. I have not tried this, because I have already spent too much time on this, and perhaps it is better to be protected by Secure Boot anyway.