On Wed, Mar 20, 2024 at 06:12:18PM -0000, Jim Henderson wrote:
On Wed, 20 Mar 2024 20:23:29 +0300, Andrei Borzenkov wrote:
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?
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
Storage space in UEFI is not large, so several KB does make a difference.
Indeed it does.
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.
Thank you for the confirmation. I was pretty sure that was the case, but after going back and forth several times with the suggestion to "increase the size of the UEFI partition", I thought I might be missing something.
(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.
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.
What says
df -h /sys/firmware/efi/efivars/
(See above)
I had seen something on another type of system (a Lenovo laptop) about there maybe being an option in the UEFI settings to restore factory keys - and if that option exists, that might be an approach that works.
(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. Regards Joey Lee