update-bootloader failed due to full NVRAM

Recently while doing a regular dup I noticed this error pop up at the end of the upgrade:

Could not prepare Boot variable: No space left on device

Through various searches I managed to figure out that the issue was caused by lack of space in the NVRAM due to the presence of dump-* files in /sys/firmware/efi/efivars. After removing them I was successful in manually running the command again but I don’t know how critical those files are. I tried viewing them but I found nothing but gibberish, and there’s barely any resources that I could find that say anything about the purpose of NVRAM. Can I get some pointers as to why these dumps appeared and how I can prevent this error from happening on future boots?

I cannot help with the dump files. I’m not sure what those are about.

However: Use Yast bootloader.

There should be a box: “Update NVRAM Entry”

Uncheck that box.

That way, future updates to bootloader won’t attempt to write to NVRAM, and that should avoid the error you saw. They will still update what is stored in your EFI partition.

These are compressed content of kernel message buffer at the time of kernel crash. They are preserved to facilitate troubleshooting so you can get errors, stack trace etc from the time crash happened.

Now I was rather surprised that it is enabled by default (it is not in Leap) but so it is. Normally those dumps should be copied to hard disk and deleted from NVRAM on boot, this is done by systemd-pstore.service, but this service is not installed by default (it is part of systemd-experimental package). For this reason I think auto-enabling of EFI pstore backend is not intentional.

how I can prevent this error from happening on future boots?

To prevent appearance of dump “files” you need to fix the reason(s) for kernel crash(es) that created them. For this you need to examine those dumps. You can of course “fix” those dumps by either blacklisting efi-pstore module or using pstore_disable=1 parameter for efi_pstore module but that is just shooting the messenger.

So how can I examine those dumps? Should I install the systemd-experimental package?
From what I can tell these should be related to some deadlocks I’ve been experiencing periodically with the EXT4 driver, although I’m not quite sure what may be happening there.

So I tried installing the package and starting the service, I got the dumps and now looking through them there seems to be multiple different crash reasons.
Anyway, thanks a lot for the pointers, I’ll start a new thread if I need more help dissecting those dumps.