Defragging my old Dell's UEFI NVRAM
11 comments
·February 23, 2025pbrowne011
tripflag
There's also the fact that an NVRAM variable is never overwritten inplace; the new value is written elsewhere, and the pointer is updated to use the address of the new value. This is probably mainly for wear-leveling, but I guess it could also introduce fragmentation?
Just an observation from when I was debugging a board that selfdestructed when booting a particular efi-file so I had to dig into the flash contents to figure out why, but I think this particular code was straight from tianocore.
MindSpunk
Probably for atomicity. It’s likely only a pointer sized block can be updated atomically so in order to safely update the value that may be larger you write it somewhere else and atomically update the pointer. That way you can only observe the old or new value, and not some intermediate result if power was lost part way through writing the new value. The same techniques are used in journaling file systems.
pbrowne011
True, I was trying to find the variable storage requirements in the UEFI specification but couldn't (is it Section 3? 8?), so I resorted to linking to the struct definition in the EFI shell package that the author used.
redundantly
I imagine it's not fragmentation in the strictest sense. It's more than likely it's just the result of a bug. Perhaps garbage collection wasn't being triggered and space wasn't getting freed up. It could be that the author caused the problem themselves by how they were managing their nvram.
userbinator
I believe it was in the mid-2000s that BIOSes started storing configuration data in the same SPI flash they occupied, and UEFI just continued that trend and expanded on it. That removing the CMOS battery no longer clears it automatically is both a good and bad thing, and another problem it's created is that flash has a limited number of write cycles - and every time the system is booted, and possibly even while running, writes occur.
dcmatt
Short sweet and to the point. Why isn't this a button in the bios, naturally hidden behind a few levels of menus? "Defrag your NVRAM" Other than power failures what would other failure modes be? I guess if the NVRAM has bad cells? Guess it's easier to just reset the whole BIOS whenever there's a problem?
muppetman
So refreshing to read. Most people these days would make a 10+ minute video to promote this.
ggm
whats the risk of bricking, if the machine dies during this? I guess thats somewhat unquantifyable, but I think the warning is apt: if you had a powerloss in the middle, you are almost definitionally writing to places which matter a LOT across boot.
on the plus side, you can probably get a copy of the state before wiping it, at least as a logical structure. but what kind of fallback boot path you are on, is very specific to what the machine likes to do.
pzmarzly
A safer alternative could be to reset BIOS settings to factory defaults - that should reset NVRAM as well.
jisnsm
I had an ASUS Z97-K motherboard that used to do the same thing after I had been playing with the boot entries for a while. I never went as far as figuring out what the issue was. I theorised that it was a case of the motherboard not performing garbage collection of the deleted entries; it didn’t occur to me that it could have been a fragmentation issue. I always fixed it by resetting the BIOS…
Very interesting. I wonder if this a result of some "swiss cheese" effect due to constraints around UEFI and NVRAM themselves, when updating EFI variables.
NVRAM must maintain atomicity of memory transactions for power failures. Its whole purpose is to store data when you turn your computer off. As a result, when deleteing an EFI variable, you can't manage the individual bytes - you have to delete a whole entry (which can be rather large - based on the EFI specification and the code used for edk2, e.g. https://github.com/tianocore/edk2/blob/83a86f465ccb1a792f5c5...). Deleting these entries might become a problem when you start running against memory constraints and what slots in memory are actually available; hence a possible fragmentation issue.
Additionally, I appreciated how short and specific this blog post was. I enjoy this style of post of someone encountering a problem and solving it.