![](https://seccdn.libravatar.org/avatar/008a8db3f6a813af5f8064f2be96e100.jpg?s=120&d=mm&r=g)
On Thu, 21 Mar 2024 13:57:00 +0800, joeyli via openSUSE Factory wrote:
Nothing in dmesg. I determined the free space using:
[jhenderson@TheEarth ~]$ df -h /sys/firmware/efi/efivars/ Filesystem Size Used Avail Use% Mounted on efivarfs 128K 104K 20K 85% /sys/firmware/efi/efivars
This function be introduced to Linux kernel since v6.5-rc1
commit d86ff3333cb1d5f42d8898fb5fdb304e143c0237 Author: Anisse Astier
Date: Wed May 17 17:38:12 2023 +0200 efivarfs: expose used and total size
Good to know.
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.
As I remember that dbx is only effective when secure boot is enabled. If you do not enable secure boot, then you don't need dbx.
I suspected that might be the case, but given the nature of what's stored there, mucking about with it could be bad (and indeed, others pointed out instances where systems were bricked by deleting the wrong thing).
(https://github.com/fwupd/fwupd/issues/5603 is where that comment is)
The nvram space is a hardware limitation. Hardware manufacturer should handles the dbx update because they should check nvram space first. The UEFI dbx is still growing. Normally 32kb nvram space be reserved for dbx:
UEFI shim bootloader secure boot lifecycle improvements https://github.com/rhboot/shim/blob/sbat/SBAT.md
Some machine provides > 32kb space for dbx. But it's not in spec. The nvram and dbx space limitation is a problem. No good answer currently.
That's good to hear. -- Jim Henderson Please keep on-topic replies on the list so everyone benefits