Dnf error removing old kernel pkg: rm: cannot remove /efi/.../6.8.10-200.fc39.x86_64/ is a directory (no grub)

After upgrading F39->F40, I noticed my EFI partition is very full. That’s partly my fault for making it too small, but it holds enough kernels so I haven’t dealt with it.

However, I notice that more than the set max of kernels are still in there. So I tried to remove the oldest one and got this error from DNF:

Running transaction                                                                                                                                   
  Preparing        :                                                                                                                              1/1 
  Erasing          : kernel-modules-extra-6.8.10-200.fc39.x86_64                                                                                  1/4 
  Running scriptlet: kernel-modules-extra-6.8.10-200.fc39.x86_64                                                                                  1/4 
  Erasing          : kernel-modules-6.8.10-200.fc39.x86_64                                                                                        2/4 
  Running scriptlet: kernel-modules-6.8.10-200.fc39.x86_64                                                                                        2/4 
  Erasing          : kernel-modules-core-6.8.10-200.fc39.x86_64                                                                                   3/4 
  Running scriptlet: kernel-core-6.8.10-200.fc39.x86_64                                                                                           4/4 
rm: cannot remove '/efi/<hostid redacted>/6.8.10-200.fc39.x86_64/': Is a directory
/usr/lib/kernel/install.d/50-dracut.install failed with exit status 1.     
error: %preun(kernel-core-6.8.10-200.fc39.x86_64) scriptlet failed, exit status 1                                                                     
Error in PREUN scriptlet in rpm package kernel-core
error: kernel-core-6.8.10-200.fc39.x86_64: erase failed

I think this is strange, because I didn’t notice any problem on F39 when new kernels were installed; old kernels got removed as expected. Why would it break now? This error seems to suggest the script is just not attempting to do the right thing, but obviously that’s crazy, right? That path is always a directory, not a file, so why would the script try to rm it?

Can I just remove this path, manually? That’s my instinct, but I’m not sure what will happen with the preun script. Can I force uninstall the pkg and then delete the path? Do you think there is something more serious going on?

Oh, never mind. It actually did remove the directory. I ran the dnf remove command again, and it completed. Strange, though, right?

This usually is because on some older fedora versions the directory /boot/efi/<machine ID> directory may have been created and with newer systems that directory is only for use with systemd-boot. Removing that directory then running dnf reinstall kernel-core usually fixes that problem.

Hmm, interesting, but I’m not sure I follow. my machineID didn’t change. My active kernels are in the same machineID dir as that one.

Uh oh. I just did a dnf update and it happened again with a F40 kernel pkg.

If you are using grub all the kernels should be in /boot

# ls /boot
config-6.8.11-300.fc40.x86_64                            symvers-6.8.11-300.fc40.x86_64.xz
config-6.9.4-200.fc40.x86_64                             symvers-6.9.4-200.fc40.x86_64.xz
config-6.9.5-200.fc40.x86_64                             symvers-6.9.5-200.fc40.x86_64.xz
efi                                                      System.map-6.8.11-300.fc40.x86_64
grub2                                                    System.map-6.9.4-200.fc40.x86_64
initramfs-0-rescue-c50eedc1bcb245299bc96b1173897ac2.img  System.map-6.9.5-200.fc40.x86_64
initramfs-6.8.11-300.fc40.x86_64.img                     vmlinuz-0-rescue-c50eedc1bcb245299bc96b1173897ac2
initramfs-6.9.4-200.fc40.x86_64.img                      vmlinuz-6.8.11-300.fc40.x86_64
initramfs-6.9.5-200.fc40.x86_64.img                      vmlinuz-6.9.4-200.fc40.x86_64
loader                                                   vmlinuz-6.9.5-200.fc40.x86_64

and this should be similar to what you see in /boot/efi

# ls -R /boot/efi
EFI  mach_kernel  System

BOOT  fedora

BOOTIA32.EFI  BOOTX64.EFI  fbia32.efi  fbx64.efi

BOOTIA32.CSV  gcdia32.efi  grub.cfg      grubx64.efi  mmx64.efi  shimia32.efi
BOOTX64.CSV   gcdx64.efi   grubia32.efi  mmia32.efi   shim.efi   shimx64.efi




Note there is no directory with the machine ID in that area.

When using grub to boot that directory became a problem after f40 was released due to changes in booting. That directory has not been used by grub for a long time and only became a problem with recent system updates.

In fact, the /efi directory does not exist with f40 and grub. As I understand it the /efi directory only is used when using systemd-boot. Which way are you booting? Default with grub or with systemd boot?

Right, I’m using systemd-boot. Should have mentioned that.

Added boot, efibootmgr

That is extremely important information, and it makes all previous recommendation wrong.

To fix change one word in the file /usr/lib/kernel/install.d/50-dracut.install

--- 50-dracut.install.orig	2024-05-16 02:00:00.000000000 +0200
+++ 50-dracut.install	2024-05-24 08:10:24.610779279 +0200
@@ -19,7 +19,7 @@
 if [[ -d "$BOOT_DIR_ABS" ]]; then
-    INITRD="initrd"
+    IMAGE="initrd"
     # No layout information, use users --uefi/--no-uefi preference

1 Like

Couldn’t find a tag for systemd-boot or bootctl or no-grub. But, sorry, I forgot to say that.

Anything that deviates for the default configuration can be important. Otherwise people would just assume that you are using a standard Gnome Workstation as is was when first installed.

Yes, I understand that. Again, I’m sorry. I switched to EFI no-grub in 2016. So, I kinda forgot about it.

This issue with preun script never showed up before; it doesn’t make sense that this just cropped up after F40. Could something unexpected have changed during upgrade F39->F40?

It’s really cool that you know how dracut works that well. But, you’re suggesting me to change a file in /usr/ owned by a pkg. That seems very unusual. Is there anything else I should know about systemd-boot systems that might be set incorrectly? Maybe something with /etc/dracut.conf.d/ ? Can I put a modified copy of 50-dracut.install in that directory or something? What I’m getting at is, what do I need to watch out for if I change that file? Won’t that cause a checksum error on that file with rpm --verify?

It is a bug introduced with Fedora 40, and yes it has been reported to Bugzilla.

You can, as you suggested create the file /etc/kernel/install.d/50-depmod.install with the fix included. Good idea.


Awesome! Thank you. I love his forum and everyone here. Thanks much!


I’ll keep an eye out for a new dracut pkg. That way, I can remove it when the fix rolls out.

Added systemd-boot and removed boot

I just added that tag for you.