Noratek BLOG

Fix fwupd UEFI dbx update failing with "Not enough efivarfs space" on a Framework 16 (AMD)

Published 27 June 2026

date
env
linux Fedora 44 (kernel 7.0.13), fwupd 2.1.5 — Framework Laptop 16 (AMD Ryzen 7040 / Ryzen AI 300 series). Applies to any UEFI machine, but the BIOS-menu wording below is Framework/Insyde-specific. macos N/A
tags

You run a routine firmware refresh and one device — the UEFI dbx — refuses to update:

Device 362301da643102b9f38477387e2193e57abaa590 [UEFI dbx] does not currently
allow updates: Not enough efivarfs space, requested 30,7 kB and got 20,0 kB

The dbx is the UEFI Secure Boot revocation list (the forbidden signatures database) — a list of known-bad bootloader hashes that Microsoft and the UEFI Forum periodically grow. Keeping it current is a real security update: it blocks already-revoked, vulnerable boot binaries (BootHole-class bugs) from loading. So this is worth fixing, not ignoring.

This guide explains why the update is refused (it is not a bug in fwupd and not something you fix by deleting files), how to confirm the cause on your own machine, and the one fix that reliably works on Framework AMD laptops.

Notation: commands prefixed with sudo need root because EFI variables live in firmware-backed NVRAM exposed at /sys/firmware/efi/efivars/. The diagnostic steps (1–3) are read-only and safe. The fix (step 5) happens in the BIOS, not on disk.

⚠️ The one hard rule, up front: never rm files in /sys/firmware/efi/efivars/. Deleting PK, KEK, db, dbxDefault, Amd*, or Setup can break Secure Boot or brick the board. Nothing in this guide deletes efivars, and you should not either.

1. Confirm the error and your fwupd state

Reproduce it deliberately so you have the exact numbers in front of you:

Terminal window
sudo fwupdmgr refresh --force
fwupdmgr get-updates

You will see the UEFI dbx device listed with the refusal. Note the two numbers in the message — requested (size of the new dbx) versus got (free space the firmware is willing to hand out):

... Not enough efivarfs space, requested 30,7 kB and got 20,0 kB

In this example the new dbx needs 30.7 kB but the firmware only offers 20.0 kB. That ~10 kB shortfall is the whole problem.

The decimal comma (30,7) is just locale formatting — that is 30.7 kB, not 30 kB and 7 bytes.

2. Look at what is actually in NVRAM

The variable store is small (typically ~128 kB total on these boards) and is shared by every EFI variable — Secure Boot keys, boot entries, vendor settings. List the biggest consumers:

Terminal window
printf '%-28s %8s\n' VAR BYTES
for f in /sys/firmware/efi/efivars/*; do
  printf '%-28s %8s\n' "$(basename "$f")" "$(stat -c %s "$f")"
done | sort -k2 -nr | head -20

Representative output from the affected Framework 16:

VAR                             BYTES
dbx-d719b2cb-...                   20720
dbxDefault-8be4df61-...            20672
dbDefault-8be4df61-...              8964
db-d719b2cb-...                     8964
WIFI_MANAGER_IFR_NVDATA-...         4659
KEKDefault-8be4df61-...             4399
KEK-8be4df61-...                    4399
AmdSetupPHX-...                     1652
AmdSetup-...                        1652
...
PK-8be4df61-...                     1373
MokListRT-...                       1167

Two things to read out of this:

  • The store is dominated by legitimate Secure Boot key databases — dbx, dbxDefault, db/dbDefault, KEK/KEKDefault, PK/PKDefault. There is no junk to clean.
  • The current dbx is already ~20.7 kB. The new one is ~30.7 kB. To swap a 20.7 kB variable for a 30.7 kB one, the firmware needs the new value to fit in free space before it reclaims the old — and it only has ~20 kB free. Hence the refusal.

A note on MokListRT — that variable is your enrolled Machine Owner Key (used by shim to trust DKMS / out-of-tree signed kernel modules like VirtualBox, NVIDIA, or v4l2loopback). It is managed by shim in a separate variable from the Secure Boot key databases, which is why the fix in step 5 does not wipe it.

3. Rule out the things that don’t work

Before touching the BIOS, it is worth understanding why the “obvious” fixes fail — this is exactly where people waste an afternoon (and the community threads below confirm it).

Boot entries free almost nothing. Check them:

Terminal window
efibootmgr -v

Each Boot#### entry is tiny — on the order of 100–300 bytes. Removing a stale duplicate or an unused PXE/network entry frees hundreds of bytes against a 10 kB shortfall. It cannot close the gap. (If you do have a genuinely stale duplicate — e.g. an old Fedora entry pointing at \EFI\fedora\shim.efi while the live one uses shimx64.efi — you can remove it with sudo efibootmgr -b <NNNN> -B, but do it for tidiness, not to fix this.)

These also do not help (reported across multiple bug trackers):

  • sudo mount -o remount,rw /sys/firmware/efi/efivars — the filesystem is already writable; remounting changes nothing.
  • fwupdmgr update --no-reboot-check and similar flags — the refusal comes from the firmware’s free-space report, not from fwupd’s checks.
  • Deleting miscellaneous efivars — negligible space, and dangerous (see the hard rule above).

The real cause is fragmentation, not raw capacity. The store has enough total bytes, but the free space is broken into pieces too small for a single 30.7 kB variable. Only the firmware can repack it.

4. (Optional) Try the offline / reboot update path first

Sometimes the write succeeds when it runs in early boot, before the OS starts churning EFI variables. Two low-effort ways to trigger that:

Terminal window
# Schedule the update to apply on the next reboot:
sudo fwupdmgr update
sudo systemctl reboot

or apply it through GNOME Software (it performs firmware updates via an offline reboot with no user logged in). Several users report this alone clears the dbx update.

If it still fails with the same message — which is the common outcome when the store is as packed as in step 2 — move to step 5, the fix that reliably works.

5. The fix: erase and restore Secure Boot keys in the BIOS

Resetting the Secure Boot key databases to factory defaults makes the firmware re-initialize and repack (defragment) the variable store. That reclaims the fragmented free space, after which the larger dbx fits. This is the step confirmed to work on the same hardware (Framework 16 AMD 7040) in the Framework community thread linked in Sources — one user went from 93 % full (~11 kB free) to 40 % full (~86 kB free) with this exact procedure.

Before you start:

  • Plug in the charger.
  • Know your firmware/BIOS password if you set one (you need it to enter Secure Boot admin settings).
  • Your MOK survives this (it is separate — see step 2), so DKMS/signed modules keep working. Secure Boot itself stays enabled; you are only resetting its key databases to the Framework/UEFI defaults.

Procedure (exact menu path on Framework 16 AMD / Insyde firmware — two reboots):

  1. Reboot and press F2 at the Framework splash to enter UEFI Setup.
  2. Go to Administer Secure Boot.
  3. Choose Erase all Secure Boot Settings (this clears the key databases — it drops Secure Boot into “Setup Mode”).
  4. Press F10 to Save, then reboot and press F2 again to re-enter Setup.
  5. Go back to Administer Secure Boot and choose Restore Secure Boot to Factory Settings. This re-enrolls the standard PK/KEK/db/dbx and repacks the store.
  6. Press F10 to Save and reboot. (Confirm Secure Boot = Enabled and that your boot order still lists Fedora first.)

This is the exact sequence confirmed working on a Framework 16 AMD: the pending dbx update applied on the first try afterward.

Then retry the update from Linux:

Terminal window
sudo fwupdmgr refresh --force
sudo fwupdmgr update          # the UEFI dbx should now apply

Verify the new free headroom is back (re-run the step 2 one-liner, or):

Terminal window
df -h /sys/firmware/efi/efivars
fwupdmgr get-devices | grep -A3 'UEFI dbx'

The dbx version should now show the updated revision and get-updates should no longer list it.

6. Post-fix sanity checks

  • Secure Boot still on?
    Terminal window
    mokutil --sb-state          # → "SecureBoot enabled"
  • Signed third-party modules still load? (only if you use DKMS/NVIDIA/VirtualBox)
    Terminal window
    mokutil --list-enrolled     # your MOK should still be listed
    If your MOK is somehow gone, re-enroll it the normal way (sudo mokutil --import <key>.der, reboot, confirm in the MOK manager) — but on a keys-only reset this is rarely needed.
  • Boots cleanly into Fedora without dropping to the firmware’s boot menu — confirms the boot order survived.

Troubleshooting

  • Still “Not enough efivarfs space” after the keys reset — re-run the step 2 listing; if df -h shows the store is now mostly free but the write still fails, do a full cold power-off (sudo shutdown -h now, wait ~10 s, power on), since some firmwares only garbage-collect freed NVRAM on a cold boot, not a warm reboot. Then retry.
  • Cold reboot alone “fixed” the free-space number but not the update — a cold boot can recover some space via garbage collection, but if the store is genuinely fragmented it won’t be enough; the keys reset in step 5 is what actually repacks it.
  • Can’t find “Erase/Restore Secure Boot keys” — on Insyde-based Framework firmware these live under Security → Secure Boot; you may need to set Secure Boot to Custom mode to expose the key-management actions, then Restore Factory Keys.
  • You enrolled custom Secure Boot keys yourself (not the default Framework set) — restoring factory keys will replace them; re-enroll your custom PK/KEK/db afterward.
  • fwupdmgr shows nothing to update afterward — that’s success: the dbx was applied. Confirm with fwupdmgr get-history or check the dbx version in get-devices.

Why this happens (one-paragraph background)

UEFI variables are stored in a fixed, small NVRAM region on the SPI flash. Authenticated variables like dbx can only be written whole, and the firmware must fit the new value into contiguous-enough free space before reclaiming the old one. As Microsoft grows the revocation list, each dbx revision gets bigger; on boards that ship a nearly-full, fragmented store (common on Framework AMD 7040 units), a point comes where the new dbx no longer fits — even though the old one did. Deleting boot entries or other variables frees too little to matter; only a firmware-side reset-to-defaults, which rewrites the whole store cleanly, restores enough contiguous space. This is a recognized, triaged issue upstream (see Sources).

Quick reference

Terminal window
# 1. Reproduce + read the numbers (requested vs got)
sudo fwupdmgr refresh --force && fwupdmgr get-updates


# 2. See what fills NVRAM (read-only)
for f in /sys/firmware/efi/efivars/*; do \
  printf '%-28s %8s\n' "$(basename "$f")" "$(stat -c %s "$f")"; done \
  | sort -k2 -nr | head -20
df -h /sys/firmware/efi/efivars


# 3. Don't bother: deleting boot entries frees only bytes
efibootmgr -v


# 4. Try offline path first (sometimes enough)
sudo fwupdmgr update && sudo systemctl reboot


# 5. THE FIX — in BIOS (F2): Administer Secure Boot →
#    Erase all Secure Boot Settings → F10 save → reboot → F2 →
#    Administer Secure Boot → Restore Secure Boot to Factory Settings → F10 save → reboot
#    (repacks/defragments NVRAM; your MOK survives)


# 6. Retry + verify
sudo fwupdmgr refresh --force && sudo fwupdmgr update
mokutil --sb-state

Sources