Problem
Some systems might encounter an error saying that more space on the /boot filesystem is needed when they try to perform a system update. Here’s an example error from the DNF package manager:
Transaction failed: Rpm transaction failed.
– installing package kernel-core-6.17.5-300.fc43.x86_64 needs 40MB more space on the /boot filesystem
And a similar error is printed by GNOME Software:
Error running transaction: installing package kernel-core-6.17.5-300.fc43.x86_64 needs 40MB more space on the /boot filesystem
The likelihood of encountering the problem depends on the size of your /boot partition and your hardware configuration.
Cause
The /boot partition stores not just the Linux kernel, but also initramfs files containing the early boot environment, which include firmware for your current hardware. Firmware files have been growing rapidly over the years. The most notable example is NVIDIA: since earlier this year, NVIDIA GPU firmware files alone total nearly 100MiB. The /boot partition needs to store 3 permanent kernel + initramfs pairs, 1 rescue pair (a general hardware support) and one “update in progress” pair. Fedora 23 and older defaulted to 500 MiB /boot size, Fedora 24 - 42 defaulted to 1 GiB, Fedora 43 and later defaults to 2 GiB.
500 MiB /boot partitions especially can often no longer keep up. If you have an NVIDIA card installed, in some cases, even 1 GiB partition might already not be enough.
To make matters worse, versions of dracut - the tool which builds the initramfs files - prior to dracut-107-8.fc43 created larger than expected initramfs files (which has been fixed in the Fedora 43 final release).
Related Issues
Bugzilla report: #2394213
Note on Atomic systems
Atomic systems (Fedora Silverblue, Fedora Kinoite, Fedora IoT, Fedora CoreOS…) do not behave exactly as described above. By default, Atomic installs keep two “deployments” of the system available - the current one, and the last known good one so you can roll back to it if necessary. This includes the kernel and initramfs. They do not have rescue kernels. On Atomic systems you can see what kernels and initramfs files are present in /boot/ostree. Usually there will be just two. So Atomic systems should be less prone to this problem.
Manually “pinning” additional deployments will use more space in /boot, so if you pin too many deployments you may run into this issue.
Workarounds
To work around this problem (on non-Atomic installs), you can remove the ‘rescue’ kernel and initramfs, and/or reduce the number of kernels Fedora will keep installed concurrently to two instead of three.
Please note that while one of these workarounds might be good enough for a while, the files will continue to grow and you might need to do a full new Fedora install (including new partitioning) in the future, to get a bigger /boot partition.
You can try to manually increase /boot’s size, but that will likely require shuffling multiple partitions, needs advanced partitioning knowledge, is risky, and is out of scope of this guide.
Removing the rescue kernel
To remove the rescue kernel, run:
sudo rm -i /boot/initramfs*rescue* /boot/vmlinuz*rescue*
sudo dnf remove dracut-config-rescue
In the event you need to ‘rescue’ the system in future, you can use the rescue environment from a Fedora installer image (network install image or Server DVD image).
Reducing the number of installed kernels
To reduce the number of kernels Fedora will keep installed concurrently to two instead of the default three, create a file /etc/dnf/libdnf5.conf.d/00-kernellimit.conf with this content:
[main]
installonly_limit=2
If three kernels are currently installed, you might then need to remove one of them manually, to free up required disk space. See all the kernels that you current have installed:
$ rpm -q kernel | sort
kernel-6.17.3-301.fc43.x86_64
kernel-6.17.4-300.fc43.x86_64
kernel-6.17.5-300.fc43.x86_64
In this example, you can see three kernels installed, with different version numbers. You’re mostly probably running the latest one (but you can check with uname -r). Pick the oldest one, and remove it and all its subpackages with:
$ sudo dnf remove kernel*-<version>*
so from the example above that would be:
$ sudo dnf remove kernel*-6.17.3-301*
Removing:
kernel x86_64 6.17.3-301.fc43 ...
kernel-core x86_64 6.17.3-301.fc43 ...
kernel-modules x86_64 6.17.3-301.fc43 ...
kernel-modules-core x86_64 6.17.3-301.fc43 ...
kernel-modules-extra x86_64 6.17.3-301.fc43 ...
...
Now, the next time a kernel update is available, the updater should remove whichever of the two installed kernels is not booted, then install the newly-available one.