![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
On 20.03.2024 19:41, Jim Henderson wrote:
I'm working on an issue with my System76 system not being able to apply the firmware update that updates the UEFI dbx to version 371 (the version that resolves the issue resulting from the discovery of the BlackLotus UEFI bootkit).
The issue I'm having is that efivarfs is running out of space.
I'm being advised to increase the size of my UEFI partition - which is 4 GB and has 158 MB free - for a firmware update that is 21.2 KB in size, and the output from fwupdmgr is telling me that efivarfs doesn't have enough free space (it has 20KB free).
Oh, I was not aware that it can show it. Do you have anything in dmesg? Storage space in UEFI is not large, so several KB does make a difference.
There's nothing in the messages that suggests that I need additional space in the UEFI partition on my system - the specific message I get is:
failed to write data to efivarfs: Error writing to file descriptor: No space left on device
There's no reason to be messing about with my UEFI partition at all, is there? (They had also suggested using efibootmgr to remove some entries, and that does clear out some of the Boot0* files in /sys/firmware/efi/ efivars - but not enough).
The issue is with the constraints in the nvram where this data is stored itself, and not the UEFI boot partition on my SSD, correct?
Yes.
Just want to make sure I'm completely understanding the message I'm seeing.
(As a "bonus question", messing around with just deleting stuff like the dbx files in efivarfs could potentially brick the system, right?)
I suppose, removing some variables whose existence is taken for granted by firmware may well do it. I vaguely remember having seen something like this. dbx should not be essential, but how knows. What says df -h /sys/firmware/efi/efivars/