0
Blog

efibootmgr: Could not prepare Boot variable: No space left on device.

A real fix for the "efibootmgr: Could not prepare Boot variable: No space left on device" error that hits when you try to install Linux. Why it happens, and four ways I got past it.

7 min readShravan Bhati
LinuxefibootmgrUEFITroubleshootingBootloader
efibootmgr: Could not prepare Boot variable: No space left on device.

I ran into this error the first time I tried to install a new Linux distro on my laptop. The installer ran through almost every step and then died at the bootloader stage with this line:

shell.sh
bash
efibootmgr: Could not prepare Boot variable: No space left on device

I had no idea what went wrong. I read through forum posts, scrolled Reddit threads, and tried every answer I could find. Most of them pointed in different directions. After a few hours of digging, I figured out what was actually happening. This post is everything I wish someone had handed me before I started.

If you are stuck on the same error, try the fixes below in order. One of them will work for you.

What this error actually means

When you see efibootmgr: Could not prepare Boot variable: No space left on device, the installer is trying to write a bootloader entry to your UEFI NVRAM and failing. It is not the same as your disk being full. The NVRAM is a small storage area on the motherboard where UEFI stores boot entries, and it has a hard limit on how many entries it can hold.

In practice, you usually hit this for one of three reasons:

  • The EFI partition is too small, and there is no room left for a new bootloader file.
  • Your installation media is corrupted and efibootmgr is misreporting the failure.
  • There is a conflict with an existing bootloader, often a leftover Windows Boot Manager or a duplicate entry from an older distro.

If you are new to Linux, open your UEFI or BIOS settings and turn off both Fast Boot and Secure Boot before you do anything else. Both can silently block the installer from writing the bootloader. It is a small step, but it saves a lot of pain later.

Fast Boot skips the POST screen and can lock the EFI variables. Secure Boot only allows signed bootloaders, and some Linux installers do not sign theirs by default. Disable both before installing.

Set up a recovery environment

If the installer crashed, your machine probably will not boot normally into the OS you were trying to install. That is fine. You need a live environment with a terminal, and most distros ship one in Try Mode.

Boot from your USB stick, pick "Try" instead of "Install", and you get a temporary desktop with a working terminal. If your distro does not have a Try Mode option, download an Ubuntu ISO and boot into that instead. You only need it for a few commands.

A tool that makes this whole process easier is Ventoy. You flash Ventoy to a USB drive once, then you can drop any number of ISO files onto that drive and boot whichever one you want. No more re-flashing the stick for every distro.

Fix 1: Update your firmware (the fast path)

The first thing that worked for me was updating my laptop's UEFI firmware. A firmware update clears out the old, broken NVRAM entries automatically, and the installer had no problem writing the new bootloader afterwards.

Here is what to do:

  1. Find your laptop or motherboard model. It is usually printed on a sticker on the bottom of the device, or visible in the BIOS.
  2. Go to the manufacturer's support site and download the latest BIOS or UEFI update for your model.
  3. Follow their instructions to run the updater. Most laptops ship a Windows-only updater, so you may need to boot into Windows once to apply it. Some newer machines let you update straight from the BIOS menu.

This fix is not permanent. If you install another distro later, the same problem can come back. When it does, move on to Fix 2.

Fix 2: Clean out old boot entries with efibootmgr

Once you are in Try Mode, open a terminal and run:

shell.sh
bash
efibootmgr

You will see a list of every boot entry stored in NVRAM. The output looks something like this:

efibootmgr
bash
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0000,0001,0002,0003
Boot0000* Windows Boot Manager
Boot0001* ubuntu
Boot0002* UEFI: KingstonDataTraveler
Boot0003* UEFI OS
Boot0004* UEFI: Vendor CoProductCode 2.00, Partition 2

Each BootXXXX is one entry. The * next to the name means it is active. The two things to look for are duplicates (more than one entry pointing at the same OS) and entries from an OS you no longer have installed.

To delete a single entry, pass its number with -b and use -B to remove it:

shell.sh
bash
sudo efibootmgr -b 0000 -B

Run efibootmgr again to confirm the entry is gone. Repeat for anything else you want to clear out. Removing a couple of stale entries is sometimes all it takes for the installer to find room for the new bootloader.

Clear everything at once

If you do not want to delete entries one by one, you can wipe them all in a single command:

shell.sh
bash
sudo efibootmgr -O

The -O flag tells efibootmgr to clear the boot order, which in most firmwares also removes the entries themselves. After running it, check the state:

shell.sh
bash
efibootmgr

If you see output like this, you are in good shape:

efibootmgr (after wipe)
bash
BootCurrent: 0001
Timeout: 1 seconds
No BootOrder is set; firmware will attempt recovery

"No BootOrder is set" means the NVRAM is empty. Boot into your installer again, and it should write the new bootloader without complaining.

Fix 3: Delete each entry by hand

Sometimes -O does not clear the entries, only the boot order. The list looks empty until you reboot, then the old entries come right back. In that case, delete them one at a time:

shell.sh
bash
sudo efibootmgr -b 0000 -B
sudo efibootmgr -b 0001 -B
sudo efibootmgr -b 0002 -B
sudo efibootmgr -b 0003 -B
sudo efibootmgr -b 0004 -B

Some firmware versions renumber the entries after each deletion, so the boot number in the next line can be lower than the one you just removed. Run efibootmgr between deletions to see what is left and adjust if needed.

Fix 4: Wipe the EFI partition itself

If you are still stuck, the EFI partition may be too small or so cluttered with old bootloaders that there is no room for a new one. The fix is to format it and let the installer recreate the files. Only do this if you do not need the existing bootloader, because you are about to delete it.

First, find the EFI partition. In the live terminal, run:

shell.sh
bash
lsblk -f

Look for a small (usually 100 to 500 MB) FAT32 partition with the boot or esp flag. It will look something like /dev/sda1 or /dev/nvme0n1p1. Note the device name, then format it:

shell.sh
bash
sudo mkfs.fat -F32 /dev/sda1

Re-run the installer. The installer will see a clean EFI partition and write a fresh bootloader to it. When you reboot, your new distro should boot straight in.

Be careful with lsblk. Make sure you are formatting the EFI partition, not your root or home partition. Picking the wrong one will erase your data.

What actually worked for me

Of the four fixes, the firmware update (Fix 1) was the cleanest experience. I updated the BIOS, the old entries disappeared on their own, and the installer ran end to end without any extra steps.

That said, the firmware path requires a working Windows install, and not everyone has one. The next best thing is Fix 2, the manual cleanup with efibootmgr. I have used it on two other machines since, and it has worked both times. I have not gone back to check whether the NVRAM fills up again after a few distro swaps, but if it does, I will just run the cleanup again.

A short checklist before you start

If you want the smallest chance of hitting this error, run through this list before you install:

  • Disable Fast Boot in UEFI.
  • Disable Secure Boot in UEFI (or set up MOK if your distro requires it).
  • Make sure the EFI partition is at least 500 MB. The default 100 MB is too small once you start dual-booting.
  • Verify the ISO you flashed with a checksum. A corrupted installer is hard to tell apart from a real error.
  • Wipe leftover boot entries from any previous install.

A clean NVRAM and a properly sized EFI partition are 90% of the answer. The other 10% is just running the right efibootmgr commands when the installer cannot.

Final thoughts

For me, the fix came down to a single thing I had been ignoring for years: the firmware. Once I updated it, every other install I have tried has gone smoothly. The error looked scary, but the actual cause was a boring one.

If you have a different fix that worked for you, drop it in the comments or send it my way. I would rather collect a few good answers in one place than have the next person waste their afternoon reading forum posts, like I did.

Get new posts, in your inbox.

No list, no spam, no resale. Pick the categories you actually read, unsubscribe with a single click.

Which posts should I email you about?

Double opt-in · one-click unsubscribe · no tracking pixels

{/}

∑

// signature2026

Shravan Bhati

Built with careThank you for visiting