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
================================================================================
Reinstalling:
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
Reinstalled:
kernel-core-5.17.7-300.fc36.x86_64
Complete!
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.
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.
(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.
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.
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
fi
if ! dnf remove "${old_kernels[@]}"; then
echo "Failed to remove old kernels"
exit 1
fi
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
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.