Your PC's firmware has a hidden storage limit, and it stop your computer from booting

Published Aug 9, 2026, 12:00 PM EDT Korbin is a Linux system administrator who spends most of his time in a terminal figuring out how things actually work. Over the last decade he's written hundreds of articles about Linux configuration, troubleshooting weird problems, and using open-source tools in the real world. He also works a lot with Windows systems and networking, especially in mixed environments where things don't always behave the way the documentation says they should. Writing things down is how he makes sense of it all and hopefully saves someone else a few hours. Every PC has a handful of settings that survive a power cycle — things like boot order, secure boot state, fan speed, and other settings that go beyond the typical configuration you do inside the operating system. On modern UEFI machines, those settings reside in flash memory that's soldered to the motherboard. That flash region behaves much like a normal storage device and can even run out of space. It's small to begin with, sometimes just 64KB, since it only holds the data required for the computer to boot, along with security and other miscellaneous settings. Like ordinary storage, it gets written to, deleted from, and fragmented over time. When it runs out of usable space, the computer cannot save a new boot entry or update firmware settings. Worst-case scenario, the PC may refuse to boot at all. I hadn't given this much thought until I read an article by a user who actually ran into the issue. While setting up new GRUB entries, they received an error indicating there was no space left on the device. The solution was to boot to an EFI shell and defragment the flash memory. What's actually holding your firmware settings The smallest drive in your PC is soldered to the motherboard The proper name for the storage device is UEFI NVRAM (non-volatile RAM), and it's usually located on the same SPI chip as the firmware image. It stores EFI variables, which are the individual settings for the machine, such as the boot timeout or which drive is tried first during startup. Linux exposes the storage device at /sys/firmware/efi/efivars through a filesystem called efivarfs. On any kernel from the last few years, you can run df -h to see the capacity of the NVRAM and how much space is currently being used. There are various things that want a piece of that small space. Boot entries and the boot order live there, along with Secure Boot's key databases. One of those databases, dbx, is a revocation list of vulnerable bootloaders. It's grown a lot in size over the years. If you remember the BootHole vulnerability from 2020, the fix involved adding a batch of new entries to that list, which meant more data written to NVRAM. Some vendors also write error logs and crash records straight into NVRAM. When the system starts complaining about a lack of space in NVRAM, it's usually because removing an EFI variable doesn't free up the space it used right away. The firmware marks that entry as invalid, but the room the entry was consuming only comes back when the firmware runs its own garbage collection task, which typically gets triggered at boot and usually only when the available free space drops below a certain threshold. Older or budget firmware sometimes handles that poorly, or skips it entirely, putting the system at higher risk of running out of space in NVRAM. Cleaning up a drive you can't see Stale boot entries and dead space are the two potential problems Credit: You should worry about cleaning up dead space only if you're currently running into problems with NVRAM capacity. Fiddling with EFI variables for no reason is far more likely to do harm than good. Running efibootmgr -v on Linux lists every boot entry your firmware is aware of, and if you've removed any drives from your system, you might see some orphaned entries still there. They can be deleted one at a time with efibootmgr -b [entry number] -B. Again, I wouldn't advise doing this unless you're getting an error about available space while trying to update the bootloader or something. The fix for dead space is the fragmentation commands in the aforementioned blog. The dmpstore command saves every variable to a file, wipes NVRAM, then writes them all back so the firmware lays them down contiguously. The user I mentioned earlier went from 60K used to 14K after a reboot, with every setting surviving intact. This mostly happens on ancient hardware But some modern laptops are running into it now For the most part, this is a non-issue. Newer boards come with more storage space, firmware garbage collection has improved significantly, and users who have never touched their boot entries could easily go decades without running into this problem. Nobody should be worrying about preemptively defragmenting their NVRAM. This still crops up occasionally on modern machines, though, like in this GitHub issue for Framework laptops. Running fwupdmgr to update laptop firmware produced the "Not enough efivarfs space" error for numerous users, and the fix was to let the system clear the space by resetting to factory defaults in the UEFI menu. That's essentially just forcing a defragmentation, so the previously dead space gets marked as usable again. Those few kilobytes hold a lot of power It's a strange feeling to run out of storage on a component you never think about, and stranger still that it can keep a perfectly healthy PC from booting. Knowing that this is possible in the first place is half the battle. The other half is knowing how to free up the space your machine needs, which boils down to manual defragmentation or resetting to defaults in UEFI.