Low Disk Space on /EFI warning...too many kernel images?

I’m using systemd-boot and have both Current and LTS kernels installed. On the update both kernels updated and I got this warning message on reboot. Looking at my /EFI partition, I see this…

It appears I’ve got some old kernel images lying around. I think there’s supposed to be a hook that’s supposed to manage that. I think it’s in /usr/lib/kernel/install.d/ ? Possibly 91-sbctl.install ?

Tried reinstalling the latest kernel, not seeing any error messages / warnings that I might have missed last time. So, two questions?

Can I just manually delete the old kernels to recover space?

Am I correct to assume this should be happening automtically?

Yes. However, I would try to use sudo kernel-install remove instead. I would be curious if that fails or not.

Yes. However, if you do things like restore snapshots that can cause duplication if you don’t cleanup.

Other than that though, it should be automated.

The hook that removes them is 90-kernel-remove.hook

Haven’t restored any snapshots. Running sudo kernel-install -v remove 6.3.2-arch1-1 didn’t seem to do anything. I should point out that only the latest Current and LTS kernels have initrd and initrd-fallback in them. Every other folder just has the kernel alone.

Verbose output is below:

[jkmooney@jkmooney-ms7c96 ~]$ sudo kernel-install -v remove 6.3.2-arch1-1
Reading /usr/lib/kernel/install.conf…
machine-id fe5e8cb756614f3697f5565c39d19b06 acquired from /etc/machine-id
Entry-token candidates: fe5e8cb756614f3697f5565c39d19b06 endeavouros Default
/efi/fe5e8cb756614f3697f5565c39d19b06 exists, using BOOT_ROOT=/efi, ENTRY_TOKEN=fe5e8cb756614f3697f5565c39d19b06
/efi/loader/entries.srel with 'type1' found, using layout=bls
Using ENTRY_DIR_ABS=/efi/fe5e8cb756614f3697f5565c39d19b06/6.3.2-arch1-1
Plugin files:
+/usr/lib/kernel/install.d/50-depmod.install remove 6.3.2-arch1-1 /efi/fe5e8cb756614f3697f5565c39d19b06/6.3.2-arch1-1
Removing /lib/modules/6.3.2-arch1-1/modules.dep and associated files
+/etc/kernel/install.d/50-dracut.install remove 6.3.2-arch1-1 /efi/fe5e8cb756614f3697f5565c39d19b06/6.3.2-arch1-1
+/usr/lib/kernel/install.d/50-dracut-fallback.install remove 6.3.2-arch1-1 /efi/fe5e8cb756614f3697f5565c39d19b06/6.3.2-arch1-1
+/usr/lib/kernel/install.d/51-dracut-rescue.install remove 6.3.2-arch1-1 /efi/fe5e8cb756614f3697f5565c39d19b06/6.3.2-arch1-1
+/etc/kernel/install.d/90-loaderentry.install remove 6.3.2-arch1-1 /efi/fe5e8cb756614f3697f5565c39d19b06/6.3.2-arch1-1
Removing /efi/loader/entries/fe5e8cb756614f3697f5565c39d19b06-6.3.2-arch1-1*.conf
+/usr/lib/kernel/install.d/90-loaderentry-fallback.install remove 6.3.2-arch1-1 /efi/fe5e8cb756614f3697f5565c39d19b06/6.3.2-arch1-1
Removing /efi/loader/entries/fe5e8cb756614f3697f5565c39d19b06-6.3.2-arch1-1-fallback*.conf
+/usr/lib/kernel/install.d/90-uki-copy.install remove 6.3.2-arch1-1 /efi/fe5e8cb756614f3697f5565c39d19b06/6.3.2-arch1-1
+/usr/lib/kernel/install.d/91-sbctl.install remove 6.3.2-arch1-1 /efi/fe5e8cb756614f3697f5565c39d19b06/6.3.2-arch1-1
Removing kernel /efi/fe5e8cb756614f3697f5565c39d19b06/6.3.2-arch1-1/linux from signing database

Can you share the output of find /efi/fe5e8cb756614f3697f5565c39d19b06


Can you share the output of pacman -Qo /usr/lib/kernel/install.d/91-sbctl.install

1 Like

Interesting…running as both normal and admin yields the same result

/usr/lib/kernel/install.d/91-sbctl.install is owned by sbctl 0.11-1

1 Like

Do you need this package? If not, try removing it and running sudo kernel-install remove again.

…ok -Qo means “Query Owner”…kinda expains the result… :wink:

and -Qi indicates it’s neither required or optional for anything on my system so, I’ll remove it.

Yup, that seems to be working, thanks :slight_smile:

1 Like

…guess now I got to figure out how that might have happened, but first…reboot…

UPDATE: Reboots with no errors or warnings. Looks like I’m good but I’ll make a point to check next kernel update to see if /efi is still saving the old kernels.

kernel-install remove is what the hook calls as well. It looks like it was possibly failing to remove the kernel because it was failing to unregister the kernel from the signing database.

That last part was coming from the installation of sbctl which is not something we include by default. It is for secure boot. So uninstalling it resolved the issue.

Ahh, that explains it. I was briefly messing with secure boot while I was trying to understand it. In truth, I got lucky. If not for a known issue with MSI motherboards allowing kernels to boot regardless if secureboot is enabled or not, I might have had issues rebooting at all. I’ll chalk it up to a minor “warning shot” for not following proper protocol on my “daily driver” PC.
Again, appreciate the help.

1 Like