Help regarding low efi space

New openSUSE user here, still learning my way around Tumbleweed.

After a recent upgrade I got a notification that my EFI partition is running out of space. I am using the default partitioning scheme from the openSUSE installer (btrfs with FDE). The EFI partition is around 600 MB and it had filled up to about 540 MB.

I tried running sudo zypper purge-kernels, but it reported

sudo zypper purge-kernels
[sudo] password for root:
Reading installed packages…

Preparing to purge obsolete kernels…
Configuration: latest,latest-1,running
Running kernel release: 6.18.7-1-default
Running kernel arch: x86_64

Resolving package dependencies…
Nothing to do.

My

/etc/zypp/zypp.conf

contains the line

multiversion.kernels = latest,latest-1,running

So my understanding is that I should have at most three kernels installed (or even two if the running kernel is one of the latest two).

However, in /boot/efi/opensuse-tumbleweed I can see four kernel directories

ls
6.18.3-1-default 6.18.5-1-default 6.18.6-1-default 6.18.7-1-default

I found a discussion in bugzilla mentioning that kernels will not be deleted if they are referenced by old snapshots, since that would make those snapshots unbootable. Based on that, I deleted older snapshots and rebooted. After doing this, EFI usage dropped to around 380 MB, so it looks like some obsolete files were removed.

What still confuses me is that even after deleting all old snapshots, /boot/efi/opensuse-tumbleweed still shows the same four kernel directories. I am fairly sure these kernels are no longer referenced by any snapshots, as I only have snapshots for today’s upgrade.

Is this situation normal or expected? Should these older kernel entries in the EFI partition eventually be cleaned up automatically, or is some manual cleanup required? I am a bit lost at this point, so any help or clarification would be appreciated.

Any help or guidance on what to do next is much appreciated.

Welcome to openSUSE Forums!

Show bootctl status. I assume from your reference to boot/efi/opensuse-tumbleweed, that you’re using “systemd-boot” bootloader?

The zypper purge-kernels command manages RPMs only, (not files copied to the EFI system). The sdbootutil command is probably your friend here (assuming “systemd-boot” or “grub2-bls” is in use).

2 Likes

running bootctl status gives

System:
Firmware: n/a (n/a)
Firmware Arch: x64
Secure Boot: disabled (unknown)
TPM2 Support: yes
Measured UKI: no
Boot into FW: supported

Current Boot Loader:
Product: GRUB2 2.12
Features: ✗ Boot counting
✗ Menu timeout control
✗ One-shot menu timeout control
✗ Default entry control
✗ One-shot entry control
✗ Support for XBOOTLDR partition
✗ Support for passing random seed to OS
✗ Load drop-in drivers
✗ Support Type #1 sort-key field
✗ Support @saved pseudo-entry
✗ Support Type #1 devicetree field
✗ Enroll SecureBoot keys
✗ Retain SHIM protocols
✗ Menu can be disabled
✗ Multi-Profile UKIs are supported
✓ Boot loader set partition information
Partition: /dev/disk/by-partuuid/7803c0f3-77d0-436a-871c-56cb28df2c54
Current Entry: system-opensuse-tumbleweed-6.18.7-1-default-1.conf
Default Entry: system-opensuse-tumbleweed-6.18.7-1-default-1.conf

Random Seed:
System Token: not set
Exists: no

Available Boot Loaders on ESP:
ESP: /boot/efi (/dev/disk/by-partuuid/7803c0f3-77d0-436a-871c-56cb28df2c54)
File: (can’t access /boot/efi: Permission denied)

Boot Loaders Listed in EFI Variables:
Title: openSUSE Boot Manager (grub2-bls)
ID: 0x000A
Status: active, boot-order
Partition: /dev/disk/by-partuuid/7803c0f3-77d0-436a-871c-56cb28df2c54
File: └─/EFI/opensuse/shim.efi

    Title: Fedora
       ID: 0x0003
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/7803c0f3-77d0-436a-871c-56cb28df2c54
     File: └─/EFI/fedora/shimx64.efi

    Title: Fedora
       ID: 0x0005
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/c3bbe1bc-8618-4e18-bd9a-b10e2cc88779
     File: └─/EFI/fedora/shimx64.efi

    Title: Fedora
       ID: 0x0006
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/edacc107-c81d-406a-bca5-f5d9b433a478
     File: └─/EFI/fedora/shimx64.efi

    Title: ubuntu
       ID: 0x0004
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/8dfeef1a-75ab-49e9-9f31-2206d297f849
     File: └─/EFI/ubuntu/shimx64.efi

    Title: Linux Firmware Updater
       ID: 0x0001
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/7803c0f3-77d0-436a-871c-56cb28df2c54
     File: └─/EFI/fedora/fwupdx64.efi

    Title: UEFI KBG40ZNS256G NVMe KIOXIA 256GB 70EPC6YMQTLL 1
       ID: 0x0000
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/7803c0f3-77d0-436a-871c-56cb28df2c54
     File: └─/EFI/Boot/BootX64.efi

With the following

Failed to read “/boot/efi/EFI/systemd”: Permission denied
Failed to open ‘/boot/efi//loader/loader.conf’: Permission denied

When I run it with sudo I get

System:
Firmware: n/a (n/a)
Firmware Arch: x64
Secure Boot: disabled (unknown)
TPM2 Support: yes
Measured UKI: no
Boot into FW: supported

Current Boot Loader:
Product: GRUB2 2.12
Features: ✗ Boot counting
✗ Menu timeout control
✗ One-shot menu timeout control
✗ Default entry control
✗ One-shot entry control
✗ Support for XBOOTLDR partition
✗ Support for passing random seed to OS
✗ Load drop-in drivers
✗ Support Type #1 sort-key field
✗ Support @saved pseudo-entry
✗ Support Type #1 devicetree field
✗ Enroll SecureBoot keys
✗ Retain SHIM protocols
✗ Menu can be disabled
✗ Multi-Profile UKIs are supported
✓ Boot loader set partition information
Partition: /dev/disk/by-partuuid/7803c0f3-77d0-436a-871c-56cb28df2c54
Current Entry: system-opensuse-tumbleweed-6.18.7-1-default-1.conf
Default Entry: system-opensuse-tumbleweed-6.18.7-1-default-1.conf

Random Seed:
System Token: not set
Exists: yes

Available Boot Loaders on ESP:
ESP: /boot/efi (/dev/disk/by-partuuid/7803c0f3-77d0-436a-871c-56cb28df2c54)
File: ├─/EFI/BOOT/MokManager.efi
├─/EFI/BOOT/BOOTIA32.EFI
├─/EFI/BOOT/BOOTX64.EFI
├─/EFI/BOOT/fbia32.efi
├─/EFI/BOOT/fbx64.efi
└─/EFI/BOOT/fallback.efi

Boot Loaders Listed in EFI Variables:
Title: openSUSE Boot Manager (grub2-bls)
ID: 0x000A
Status: active, boot-order
Partition: /dev/disk/by-partuuid/7803c0f3-77d0-436a-871c-56cb28df2c54
File: └─/EFI/opensuse/shim.efi

    Title: Fedora
       ID: 0x0003
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/7803c0f3-77d0-436a-871c-56cb28df2c54
     File: └─/EFI/fedora/shimx64.efi

    Title: Fedora
       ID: 0x0005
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/c3bbe1bc-8618-4e18-bd9a-b10e2cc88779
     File: └─/EFI/fedora/shimx64.efi

    Title: Fedora
       ID: 0x0006
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/edacc107-c81d-406a-bca5-f5d9b433a478
     File: └─/EFI/fedora/shimx64.efi

    Title: ubuntu
       ID: 0x0004
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/8dfeef1a-75ab-49e9-9f31-2206d297f849
     File: └─/EFI/ubuntu/shimx64.efi

    Title: Linux Firmware Updater
       ID: 0x0001
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/7803c0f3-77d0-436a-871c-56cb28df2c54
     File: └─/EFI/fedora/fwupdx64.efi

    Title: UEFI KBG40ZNS256G NVMe KIOXIA 256GB 70EPC6YMQTLL 1
       ID: 0x0000
   Status: active, boot-order
Partition: /dev/disk/by-partuuid/7803c0f3-77d0-436a-871c-56cb28df2c54
     File: └─/EFI/Boot/BootX64.efi

Boot Loader Entries:
$BOOT: /boot/efi (/dev/disk/by-partuuid/7803c0f3-77d0-436a-871c-56cb28df2c54)
token: opensuse-tumbleweed

Default Boot Loader Entry:
type: Boot Loader Specification Type #1 (.conf)
title: openSUSE Tumbleweed 20260128 (1@6.18.7-1-default)
id: system-opensuse-tumbleweed-6.18.7-1-default-1.conf
source: /boot/efi//loader/entries/system-opensuse-tumbleweed-6.18.7-1-default-1.conf (on the EFI System Partition)
sort-key: opensuse-tumbleweed
version: 1@6.18.7-1-default
linux: /boot/efi//opensuse-tumbleweed/6.18.7-1-default/linux-4da5213921d8bf3a9668ca7d014b89de6eb25f7f
initrd: /boot/efi//opensuse-tumbleweed/6.18.7-1-default/initrd-6cd4ee052e5b30c138de53fe56f33980c817b313
options: splash=silent resume=/dev/system/swap mitigations=auto quiet security=selinux selinux=1 root=UUID=27f7861b-c33b-445c-9c08-0e046533ca4c rootflags=subvol=@/.snapshots/1/snapshot systemd.machine_id=5ffa977e02474ebca666d47ef871d0ec

With the following message

systemd-boot not installed in ESP

.

I also ran

sudo sdbootutil cleanup

but that did no help

What should I do now?

Welcome to the openSUSE forums.

Can you please use the Preformatted text feature (button </>) instaed of the Blockquote feature (button") for computer text.

And do not type things like “running bootctl status gives:” but include the line with the command inside your copy/paste (like you did e.g. in your first post above).

Ok I cannot edit my orignal reply so I’ll do that from now on.
Still getting used to the forum.

2 Likes

The output you shared confirms grub2-bls is in use.

The sdbootutil cleanup command only removes stale BLS entries (entries whose kernel files are missing).

If you want to reduce ESP usage further, you could adjust zypper to keep the currently running kernel, and the newest installed kernel.Remove all older kernel versions. Do this with…

sudo sed -i 's/^multiversion.kernels.*/multiversion.kernels = latest,running/' /etc/zypp/zypp.conf

then remove the older kernels…

sudo zypper purge-kernels
sudo sdbootutil mkinitrd

BTW, with GRUB2-BLS on Tumbleweed, 600 MB is tight. An ESP partition size of 1–2 GB is more suitable. This has caught some users out.

I think I’ll keep using latest and latest -1 for now.
I guess kerenl 6.18.3 and 6.18.5 come from 0 and 1 made during the initial installation (these were the boot options I had) snapshots
and 6.18.6 and 6.18.7 are the latest and latest-1 versions.
So is 4 kerenels correct for this setting?
multiversion.kernels = latest,latest-1,running

I just used the default partitioning scheme of the tumbleweed installer. Can I increase the boot size now?

Yes, that can be normal on Tumbleweed with btrfs snapshots and GRUB2-BLS.

It needs to be done offline eg booting from a live distro and resizing the partitions with a tool like GParted.

what should happen is the installer on detecting a typical win10 500MB efi partition is to present grub2-efi instead of grub2-bls as the default choice.

recommendations to offline reconfigure a efi partition before you install tw seems a little after the fact…

Different situation here, user has (had?) multiple linux installs… Start a new thread if it’s an issue…

1 Like

See also https://bugzilla.suse.com/show_bug.cgi?id=1257528

1 Like

See also bug 1257510: [multiboot] bootloader should be more readily selectable when multiple ESP entries already exist

1 Like

I think we’ll need this in Agama as well as in the (still) existing YaST installation.

I just had one Linux installation and I also checked the option for a complete disk overwrite.
Is 600mb boot expected in this case or is this a bug.

Also be aware that the automatic update to the latest 6.9.1 kernel will also change the boot configuration. In my case the graphical screen is disabled and the roll back at the boot screen fails completely wanting a root password but not accepting the one installed during installation.

This appears like a completely different issue. The loss of the graphical target may be related to removal of old SysV compatibility layer.

Apologies the kernel is 6.18.9.1.

Good idea - will do tomorrow.