Hello, Tobias. On Fri, 10 Jan 2025 16:53:27 +0000 Tobias Geerinckx-Rice <m...@tobias.gr> wrote: > On 9 January 2025 21:45:03 UTC, Felix Lechner via <help-guix@gnu.org> wrote: > >EFI dump files exhaust space on the ESP. > > [PSA: the ESP is a FAT file system that stores .efi executables (usually, > boot loaders, but there's a Doom port too). It's not involved at all in boot > variable or dump storage. 'df' is not invited to this party.] > > Guix Systems running out of UEFI variable storage happens disturbingly often. > > It must be because we unconditionally 'update' ours on every reconfiguration, > despite this being unnecessary, and the (notoriously bad) firmware > implementations don't handle this properly. > > Nor will the cheap flash be rated for this many writes. > > …at least that's the only thing I can think of. This doesn't happen with > such frequency on other distributions. I wonder if we can reliably test > whether our variable is correctly set without parsing efibootmgr output or > rewriting it in Scheme.
Should I open an issue with guix? What information would you need from me? I think that I can reliably reproduce the problem with guix system failing to create the boot variable. It appears to happen when /sys/firmware/efi/efivars/ is filled up with a certain amount of dump-type0-* files. This happens relatively quickly on this machine after some number of reboots. If it has any potential to help to investigate the issue, I could re-enable the backend and run some tests. I understand and accept that experimenting with this may render this machine unbootable, potentially with UEFI becoming unavailable and unrecoverable. Roman
