F36 kernel won't install due to running out of space in /boot/efi

After upgrading to F36, I noticed that my system was still running the F35 kernel. I found that the F36 kernel wasn’t completely installed, so I tried reinstalling it. It fails to install because it runs out of space in /boot/efi.

$ sudo dnf reinstall kernel-core-5.17.7-300.fc36.x86_64
[sudo] password for root: 
Last metadata expiration check: 1:01:40 ago on Tue 17 May 2022 08:39:59 PM EDT.
Dependencies resolved.
 Package            Architecture  Version                  Repository      Size
 kernel-core        x86_64        5.17.7-300.fc36          updates         46 M

Transaction Summary

Total download size: 46 M
Installed size: 89 M
Is this ok [y/N]: y
Downloading Packages:
kernel-core-5.17.7-300.fc36.x86_64.rpm          9.1 MB/s |  46 MB     00:05    
Total                                           7.7 MB/s |  46 MB     00:05     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                        1/1 
  Reinstalling     : kernel-core-5.17.7-300.fc36.x86_64                     1/2 
  Running scriptlet: kernel-core-5.17.7-300.fc36.x86_64                     1/2 
  Running scriptlet: kernel-core-5.17.7-300.fc36.x86_64                     2/2 
  Cleanup          : kernel-core-5.17.7-300.fc36.x86_64                     2/2 
  Running scriptlet: kernel-core-5.17.7-300.fc36.x86_64                     2/2 
install: error copying '/lib/modules/5.17.7-300.fc36.x86_64/vmlinuz' to '/boot/efi/c575ef9efdd3466c9dc9418c23831247/5.17.7-300.fc36.x86_64/linux': No space left on device
Could not copy '/lib/modules/5.17.7-300.fc36.x86_64/vmlinuz' to '/boot/efi/c575ef9efdd3466c9dc9418c23831247/5.17.7-300.fc36.x86_64/linux'.
kdump: kernel 5.17.7-300.fc36.x86_64 doesn't exist
warning: %posttrans(kernel-core-5.17.7-300.fc36.x86_64) scriptlet failed, exit status 1

Error in POSTTRANS scriptlet in rpm package kernel-core
  Verifying        : kernel-core-5.17.7-300.fc36.x86_64                     1/2 
  Verifying        : kernel-core-5.17.7-300.fc36.x86_64                     2/2 



My /boot/efi partition is about 200MB, and the bulk of the space used is here:

# ls -l /boot/efi/c575ef9efdd3466c9dc9418c23831247/5.17.7-300.fc36.x86_64/
total 60584
-rwx------. 1 root root 52605040 May 17 21:42 initrd
-rwx------. 1 root root  9428992 May 17 21:43 linux

# ls -l /boot/efi/c575ef9efdd3466c9dc9418c23831247/0-rescue/
total 118140
-rwx------. 1 root root 109167471 May 17 21:43 initrd
-rwx------. 1 root root  11800752 May 17 21:42 linux

Any ideas what went wrong here and how to fix it? It seems like these initrds are way too big.

1 Like

On my system (which has the kernels/initramfses in /boot, not /boot/efi) the space consumed by any given kernel package (kernel, initramfs, symbol files, etc.) is nearly 50MB, and the default configuration keeps three of them around at once. 200MB is going be pretty tight for that.

I believe I have the same problem.

  • Is it possible to move /boot/efi to /boot? I have enough space in /boot to hold one new kernel. Do I need to change grub?
  • Is it possible to resize /boot/efi. In my system, /boot/efi is in sda1 and /boot in sda2

If you want to keep only two, set


in /etc/dnf/dnf.conf

EDIT because I can’t publish a new response:

(Keeping only two kernels might be dangerous if both fail, but given that you already have booted to one to install the next, and that one is not removed, I think one can reasonably take the odds.)

How do you setup your fedora, so the kernel instaled in efi partition not in /boot partition? I used fedora since 34 and installed too fedora in VM but never face those problem. linux kernel for booting always installed in /boot partition not in EFI windows partition.

In my case, it was the default installation setup. I believe it was fedora 27.

EDIT because I can’t publish a new response:
In my system, /boot/efi holds a directory for the rescue disk vmlinuz and initrd taking up about 120Mb. The kernel installation process attempts to put an additional vmlinuz and initrd in a directory for the new kernel, and fails because there is not enough space. If a third kernel would be installed, more space will be needed.

1 Like

hold on for a second. kernel and initramfs are not stored in /boot/efi, they are in /boot.

df -h /boot/efi/

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       250M  6.1M  244M   3% /boot/efi

sudo ls -laR /boot/efi

total 24
drwx------. 3 root root 16384 Jan  1  1970 .
dr-xr-xr-x. 6 root root  4096 May 12 23:44 ..
drwx------. 4 root root  4096 Jan 20 02:44 EFI

total 28
drwx------. 4 root root  4096 Jan 20 02:44 .
drwx------. 3 root root 16384 Jan  1  1970 ..
drwx------. 2 root root  4096 Jan 20 02:44 BOOT
drwx------. 2 root root  4096 May 12 23:43 fedora

total 1004
drwx------. 2 root root   4096 Jan 20 02:44 .
drwx------. 4 root root   4096 Jan 20 02:44 ..
-rwx------. 1 root root 928592 May  5  2021 BOOTX64.EFI
-rwx------. 1 root root  87152 May  5  2021 fbx64.efi

total 5228
drwx------. 2 root root    4096 May 12 23:43 .
drwx------. 4 root root    4096 Jan 20 02:44 ..
-rwx------. 1 root root     110 May  5  2021 BOOTX64.CSV
-rwx------. 1 root root     144 Aug 17  2021 grub.cfg
-rwx------. 1 root root    7347 Aug 17  2021 grub.cfg.rpmsave
-rwx------. 1 root root 2614536 May  9 18:33 grubx64.efi
-rwx------. 1 root root  850032 May  5  2021 mmx64.efi
-rwx------. 1 root root  928592 May  5  2021 shim.efi
-rwx------. 1 root root  928592 May  5  2021 shimx64.efi

This is dangerous and will not free any space on /boot/efi.

Have look at the content, and see what’s taking up all that space.

(Btw, I have the same issue on a dual-boot machine (Windows)- but I haven’t looked into it yet)

To be clear - my kernels and initramfs are normally stored in /boot and not /boot/efi. This writing to /boot/efi seems to be something that’s happening during kernel package installation (scriptlets).

There is a new way of booting in development for EFI systems: systemd-boot.
The kernel and initrd are located on the EFI partition and can be loaded without any driver, because the EFI BIOS can read VFAT. A config file specifies kernel arguments like root. Once loaded, the kernel can take care of ext4 and btrfs and so on…
Somehow and sometimes, the installation switches to the new method without notice. Delete /boot/efi/bignumber, which is the machine-id, and reinstall the kernel. Then the problem is solved, for the moment.

1 Like

If you have old kernels taking up space on the drive, then you can delete them with the following script (from DNF System Upgrade):

#!/usr/bin/env bash

old_kernels=($(dnf repoquery --installonly --latest-limit=-1 -q))
if [ "${#old_kernels[@]}" -eq 0 ]; then
    echo "No old kernels found"
    exit 0

if ! dnf remove "${old_kernels[@]}"; then
    echo "Failed to remove old kernels"
    exit 1

echo "Removed old kernels"
exit 0

The DNF System Upgrade also has other tips for cleaning the old F35 installation after an upgrade.

Also note that the script dnf used to remove old kernels had a bug and it used to leave artifacts in /lib/modules. You can remove the old artifacts manually from /lib/modules once the kernels have been removed using dnf. Also see Issue 2016630, Removing old kernel-core leaves modules.builtin.alias.bin under /lib/modules.

For completeness, here is my /boot after a DNF System Upgrade to F36. I had 4 of them complete without trouble (and I always follow the official docs). After the reboot into the new kernel I remove all of the old kernels.

$ sudo ls -Al /boot
total 135180
-rw-r--r--  1 root root   244012 May 12 11:30 config-5.17.7-300.fc36.x86_64
drwx------  4 root root    16384 Dec 31  1969 efi
-rw-r--r--  1 root root   151452 Jan 27 06:54 elf-memtest86+-5.31
drwxr-xr-x. 2 root root     4096 May 10 22:59 extlinux
drwx------. 4 root root     4096 May  9 12:37 grub2
-rw-------. 1 root root 71061064 Apr 19  2019 initramfs-0-rescue-7caccc78a36f4e6cacc7961848f0650c.img
-rw-------  1 root root 37922612 May 17 16:24 initramfs-5.17.7-300.fc36.x86_64.img
drwxr-xr-x. 3 root root     4096 Oct 24  2018 loader
drwx------. 2 root root    16384 Apr 19  2019 lost+found
-rw-r--r--  1 root root   149856 Jan 27 06:54 memtest86+-5.31
lrwxrwxrwx  1 root root       46 May 17 16:22 symvers-5.17.7-300.fc36.x86_64.gz -> /lib/modules/5.17.7-300.fc36.x86_64/symvers.gz
-rw-------  1 root root  6235492 May 12 11:30 System.map-5.17.7-300.fc36.x86_64
-rwxr-xr-x. 1 root root 10795112 Jun  5  2020 vmlinuz-0-rescue-7caccc78a36f4e6cacc7961848f0650c
-rwxr-xr-x  1 root root 11800752 May 12 11:30 vmlinuz-5.17.7-300.fc36.x86_64
-rw-r--r--  1 root root      167 May 12 11:26 .vmlinuz-5.17.7-300.fc36.x86_64.hmac

Thanks @hmmsjan - that resolved the issue. Do you know if there is a bug report for this?

The problem is mentioned a few times at fedoraforum.org, I did not have it myself. As far I know there is no bug report. I also do not know why it pops up now and what program or rpm script created the directory in /boot/efi.


1 Like

thanks for explaining, providing solution and sharing the link to the bug report @hmmsjan @grumpey

What stupid bug…

Work-around (fixed it for me) is described in comment 14 of the bug report 2071034 – kernel-install misdetects /boot/efi over /boot as install location on systems upgraded from F34

1 Like