装双系统时最后一步报错「No space left on device」，硬盘明明还剩几百 GB；或给笔记本刷固件时工具提示空间不足——这类故障的根因是一块几乎没人注意的存储：焊在主板上，容量可能只有 64KB。
XDA 撰稿人 Korbin Brown 梳理了这一现象。这块存储的正式名称是 UEFI NVRAM（非易失性随机存取存储器），通常和固件镜像共处同一颗 SPI 芯片，负责保存启动顺序、安全启动状态、风扇曲线这类断电后仍需保留的设置。它的行为和普通硬盘很像：会被写入、删除，也会随时间碎片化。一旦可用空间耗尽，系统就无法保存新的启动项，也无法更新固件设置，最坏的情况是电脑干脆拒绝启动。
一、先确认空间是不是真的满了
Linux 通过 efivarfs 把这块存储挂在 /sys/firmware/efi/efivars 下，近年内核直接 df -h 即可看到 NVRAM 总容量与已用量。那位实际踩坑的用户查得 64K 容量、60K 已用、可用 0K。
抢占空间的东西不少：启动项与启动顺序、安全启动密钥数据库都在里面。其中 dbx 是问题引导程序的吊销列表，2020 年 BootHole 漏洞修复就往里追加了一批条目。部分厂商还会把错误日志直接写进 NVRAM。
更麻烦的是删除机制：删掉 EFI 变量不会立刻释放空间，固件只把它标记为无效，真正回收要等开机时触发的垃圾回收——且往往要等可用空间跌破阈值才启动。老主板或低价主板固件常处理得很糟，甚至跳过这步。
二、清理无效启动项
只有在确实撞上容量报错时才需要动手，无缘无故摆弄 EFI 变量，帮倒忙的概率远大于帮忙。
- 在 Linux 下执行
efibootmgr -v，列出固件已知的全部启动项。 - 如果拆过硬盘，很可能会看到指向早已不存在设备的孤儿条目。
- 逐个删除：
efibootmgr -b 条目编号 -B。
Arch Wiki 给出的处理顺序里还有一步值得优先尝试：删掉内核崩溃转储留下的记录，即清理 /sys/firmware/efi/efivars/ 目录下以 dump- 开头的文件，然后重启再试。
三、给这块「盘」做一次整理
如果空间是被无效条目占着不放，就需要整理碎片。XDA 引用的那篇博客给出的做法是进入 EFI Shell 后依次执行三条命令：dmpstore -s efi-vars 把全部变量导出到磁盘文件，dmpstore -d 清空 NVRAM，dmpstore -l efi-vars 再把它们读回来。这样固件会把变量重新连续排布。那位用户重启后的结果是已用量从 60K 降到 14K，所有设置原样保留。
需要提醒的是，这几条命令风险不低，执行前务必先用 help dmpstore 确认本机固件的具体用法。
四、更省事的替代做法
多数机器不会发生此问题：新主板容量更大、固件垃圾回收也改善不少，没碰过启动项的用户几十年都未必遇上，无需预防性整理。
但它偶尔仍会出现在现代机器上。Framework 笔记本的 GitHub issue 里就有多名用户在运行 fwupdmgr 更新固件时收到「Not enough efivarfs space」报错，解决办法是进 UEFI 菜单恢复出厂默认值，让系统把空间清出来。这本质上等同于强制做了一次整理，之前的无效空间会被重新标记为可用。对不熟悉命令行的用户来说，这是风险最低的一招。
来源：XDA Developers
