When I try to see if there are firmware updates, I get these errors:
Windows Production PCA:
│ │ Device ID: ad7e00ec37f005ae10492bdb7f73aef0d2e20488
│ │ Current version: 2011
│ │ Vendor: Microsoft (UEFI:Microsoft)
│ │ Update Error: Not enough efivarfs space, requested 16.4 kB and got 10.7 kB
df -h:
Filesystem Size Used Avail Use% Mounted on
efivarfs 148K 138K 5,5K 97% /sys/firmware/efi/efivars
There are more, they all have to do with uefi and certificates. How is it possible that efivars is so full that updates won’t work anymore?
I did a clean install when installing Kinoite 44, so there are no left-overs from a previous install.
What can I do to make this work?
I am not sure where that info is obtained, but that file system is a virtual file system that resides in RAM.
If it comes from the physical bios info then as noted above that would be the first place to look for unnecessary settings, such as having many mok keys installed.
You can see the installed keys with the command mokutil --list-enrolled which will show in detail each key enrolled. Some users have enrolled multiple different keys and filled up the space reserved in bios, but I don’t know how that relates to the data in /sys/firmware/efi/efivars
A clean install does not clean out any data stored in the UEFI storage. The data from previous installs can be boot entries as shown by efibootmgr, or can be mok entries as shown using mokutil --list-enrolled. Some computers were born with too little space for the UEFI data, and with the growing size of the dbx data, it may have run out of space. In that case, it may be necessary to run with secure boot disabled and ignore updates for dbx data.
Thanks guys, I think I have it solved now. I started looking on the internet and found a Linux Mint forum question, which was solved, about the same issue. In there (Mint) they advised as well to look in the BIOS.
In there I saw I did not use Secure Boot (which I knew cause I never use it) but I also found an item where I could reset a database with keys to factory standard. Which I did. After boot my external monitor did not get a signal and stayed black, so again into the BIOS where I now saw that Secure Boot was enabled. Since I don’t have an Nvidia key, the driver was probably not working, leaving the monitor black. I switched off Secure Boot, booted and now it is as it should be:
df -h
Filesystem Size Used Avail Use% Mounted on
efivarfs 148K 27K 117K 19% /sys/firmware/efi/efivars
Now I hope I don’t find any other issues on the way, but I don’t think so.
Thanks for help in steering me into the right direction.
If you ever want to use secure boot, simply follow the instructions in the file /usr/share/doc/akmods/README.secureboot or the (parroted) instructions at rpmfusion.
I believe the system builds the content of /sys/firmware/efi/efivars from the content of the uefi bios storage space.
I seem to recall that some users found that they had an excessive number of keys stored in bios and that contributed to issues of this type.
To see what and how many keys you have in bios run mokutil --list-enrolled --short which should give probably no more that 4 or 5 lines of return. If more then please post the result here so we can see exactly what you have and assist in cleaning out the unnecessary ones.
Mine shows
The fedoraca key is the default for the fedora kernel
The second with my host name is the local signing key for locally compiled kernel modules with akmods.
The third (grub) is self explanatory. Apparently grub installed it.
I am not sure about the last, but it has not caused any harm. It also is related to akmods, but I am not sure of the reason it is there.