openSUSE Tumbleweed installation error: Could not prepare boot variable: No space left on deviceTech support (self.openSUSE)

I’m trying to install openSUSE Tumbleweed. The installer is giving me the following error:

Error:
Cannot install bootloader:
Command `[["usr/bin/sdbootutil", "install"]]`
Error output: Could not prepare boot variable: No space left on device

My machine is an ASUS Vivobook Z1704ZA, and I’m dual-booting alongside Windows 11. I tried researching the problem myself but didn’t find much. Any leads would be greatly appreciated.

It’s self explained,

No space left on device

What’s your disk capacity?

It might just relate to the size of the EFI partition rather than to the full size of the disk.
Seeing what the disk layout looks like (from the installer Partitioning screen or otherwise) might help.

Yours is a common problem since the bootloader default changed some months ago. The installer has proposed using the existing ESP partition that Windows installation created. This is invariably too small for use with the default bootloader selection. For multibooting, either Grub should be selected as bootloader overriding the default, or a much larger ESP needs to be included in the partition scheme. Choosing Grub means the existing ESP may be successfully used. Choosing the latter means there will be no automatic boot menu, instead requiring that you use your computer’s BBS hotkey for each non-default OS boot you wish to make.

1 Like

My full disk capacity is 1 TB. Windows has been resized to 300 GB, so there’s around 600 GB left for openSUSE.

Here’s a screenshot of Disk Management:

The larger unallocated portion is where openSUSE used to be, but I cleared it since I couldn’t get it to boot. I’m not sure if it’s safe to delete the two primary partitions (I’m afraid of losing access to Windows right now, since I don’t have a backup PC or anything).

If I’m understanding mrmazda correctly, setting Grub as the default bootloader should solve my problem. I’m guessing that option would fall under “Suggested Partitioning” in the installer?

The EFI SystemPartition at 260 MB was likely the problem, sdboot requires much more but GRUB-EFI should work just fine.
The choice has nothing to do with partitioning; go ahead with your choices, when at the “Installation Settings” screen click on “Booting” and on the drop-down menu “Boot Loader” choose “GRUB2 for EFI”.

BTW, no need to delete other partitions on disk, you have ample room for a successful install.

1 Like

Ok, I just tried GRUB2 for EFI and got the following error:

Error
Execution of command "[["/usr/sbin/grub2-install", "--target=x86_64-efi", "--force", "--skip-fs-probe"]]" failed.
Exit code: 1
Error output: Installing for x86_64-efi platform.
Could not delete variable: No space left on device
/usr/sbin/grub2-install: error: efibootmgr failed to register the boot entry: Block device required.

It looks like space it still an issue - I have three entries (from failed installations) aside from windows bootloader and the usb in my startup - ubuntu, fedora, and opensuse, could that be causing the issue? I tried removing the entries with both BIOS and bcdedit, but they just reappeared on startup.

Are you using a Ventoy USB?

No, it’s a normal USB burned with Rufus.

Does the ESP still contain kernels & initrds from failed installation attempts, or kernels & initrds from Fedora?

…Maybe. Assigning the B: letter to the EFI partition and running ls B: in powershell has the following output:

    Directory: B:\

Mode        LastWriteTime        Length Name
da----   2/29/2026   10:49 PM           EFI
da----   12/9/2025   7:23 PM            System
d-----   2/10/2026   1:50 PM            loader
d-----   2/9/2026    4:47 PM            opensuse-tumbleweed
d-----   1/5/2023    7:43 PM    3351048 DroidSansFallback.atf
-a----   3/20/2024   2:39 AM   20054016 X1704ZAAS.312
-a----   2/9/2026    6:25 PM         34 mach_kernel
-a----   12/27/2025  8:34 AM       1321 solus-enroll-me.cer

Then ls:B\EFI:

    Directory: B:\EFI

Mode        LastWriteTime        Length Name
da----    8/22/2025   6:58 PM           Microsoft
d-----    2/10/2026   1:50 AM           Boot
d-----    12/27/2025  8:34 AM           com.solus-project
d-----    12/27/2025  9:18 AM           ubuntu
d-----    2/11/2026   8:23 PM           opensuse
d-----    2/9/2026   6:25 PM            fedora

If ls into com.solus-project, it has a kernel and initrd with non-zero filesizes (15899120 and 91603072 respectively). ubuntu, opensuse, and fedora don’t have any files labeled kernel or init, but there are a bunch of grub/shim/BOOT files with nonzero filesizes. I can’t list them in detail now because I have to head to work soon.

Some of them, yes. Assigning the B: letter to the EFI partition and running ls B: in powershell has the following output:

    Directory: B:\

Mode        LastWriteTime        Length Name
da----   2/29/2026   10:49 PM           EFI
da----   12/9/2025   7:23 PM            System
d-----   2/10/2026   1:50 PM            loader
d-----   2/9/2026    4:47 PM            opensuse-tumbleweed
d-----   1/5/2023    7:43 PM    3351048 DroidSansFallback.atf
-a----   3/20/2024   2:39 AM   20054016 X1704ZAAS.312
-a----   2/9/2026    6:25 PM         34 mach_kernel
-a----   12/27/2025  8:34 AM       1321 solus-enroll-me.cer

Then ls:B\EFI:

    Directory: B:\EFI

Mode        LastWriteTime        Length Name
da----    8/22/2025   6:58 PM           Microsoft
d-----    2/10/2026   1:50 AM           Boot
d-----    12/27/2025  8:34 AM           com.solus-project
d-----    12/27/2025  9:18 AM           ubuntu
d-----    2/11/2026   8:23 PM           opensuse
d-----    2/9/2026   6:25 PM            fedora

If ls into com.solus-project, it has a kernel and initrd with non-zero filesizes (15899120 and 91603072 respectively). ubuntu, opensuse, and fedora don’t have any files labeled kernel or init, but there are a bunch of grub/shim/BOOT files with nonzero filesizes. I can’t list them in detail now because I have to head to work soon.

I tried deleting the extra directories mentioned above and reinstalling with Grub2-EFI. It gave me the same error as two days ago:

Error
Execution of command "[["/usr/sbin/grub2-install", "--target=x86_64-efi", "--force", "--skip-fs-probe"]]" failed.
Exit code: 1
Error output: Installing for x86_64-efi platform.
Could not delete variable: No space left on device
/usr/sbin/grub2-install: error: efibootmgr failed to register the boot entry: Block device required.

How much clear space on the EFI partition does tumbleweed need to install? I had about 140 mb free.

I have a 200 MB ESP, 3 openSUSE systems installed take about 33 MB with GUB2-EFI, so the problem is elsewhere? For instance in the non-volatile RAM? Are there too much boot entries in the BIOS menu, or remnants of systems that are no longer installed?

There shouldn’t be anymore? After removing the directories via powershell, the only entries in the startup menu are the Windows boot loader, opensuse itself, and the installation usb if it’s plugged in.

This is likely an NVRAM space issue rather than disk space issue. How many boot entries do you have? Check via the BIOS menu…

BIOS lists three - Windows Boot Manager, opensuse, and another copy of Windows boot manager.

@im_in_great_pain So delete the Windows Boot manager entry that’s not needed? Is the openSUSE one needed since your doing a fresh install? Some vendor NVRAM setups don’t allow much space for these entries…

Deleting the entry within BIOS basically has no effect (it just reappears on the next boot). Mounting the EFI partition manually worked for the others, but it’s not clear to me where the extra copy would be located, or if it even exists, and worried about bricking my computer on accident

So am I right in assuming there already is a functional openSUSE install present? If so boot to that, or rescue mode in Tumbleweed and as root user run evibootmgr -v and post the output or efibootmgr -v | susepaste and post back the URL.