Last-minute /boot boost for Fedora 43

By Joe Brockmeier
October 9, 2025

Sudden increases in the size of Fedora's initramfs files have prompted the project to fast-track a proposal to increase the default size of the /boot partition for new installs of Fedora 43 and later. The project has also walked back a few changes that have contributed to larger initramfs files, but the ever-increasing size of firmware means that the need for more room is unavoidable. The Fedora Engineering Steering Council (FESCo) has approved a last-minute change just before the final freeze for Fedora 43 to increase the default size of the /boot partition from 1GB to 2GB; this will leave plenty of space for kernels and initramfs images if a user is installing from scratch, but it is of no help for users upgrading from Fedora 42.

Dracut changes

The current default for Fedora, at least for Fedora Workstation on x86_64 and most other editions and spins, is to have a separate 1GB /boot partition. A system will have up to three kernels and initramfs images installed by default, plus a rescue kernel and initramfs that is generated during the system installation.

In early September, Chris Murphy started a discussion on Fedora's developer mailing list about a recent change that he had noticed in the size of the initramfs files; the images had ballooned from 35MB to 59MB. Adam Williamson said that he had recently noticed test failures caused by a warning that /boot was nearly full, but he solved them by doubling the space allocated for the /boot partition. Fabio Valentini said that he had also encountered a big increase in initramfs sizes, though he had not figured out the cause.

Murphy noted that the smaller images had been created with dracut version 105, while the larger had been created using version 107. He filed a bug on September 9; the problem stemmed from a change in dracut to include additional drivers and modules in the initramfs. This change was made so that a rescue image would be portable between systems. For example, if a user needed to move their NVMe drive to a new system due to hardware failure; this would help ensure that it would have the necessary drivers to boot on that hardware.

The bug was accepted as a blocker for the Fedora 43 release, and Pavel Valena began working on reverting the change.

Firmware increases

On September 21, Murphy started a separate discussion about increasing the size of Fedora's boot partition. This time he was concerned about the increase in size of the initramfs for Fedora's rescue image. He said he was unsure when the image sizes of the rescue image had increased, but he shared that the size of the initramfs with NVIDIA and AMD firmware was more than 256MB. Removing the NVIDIA firmware helped shrink the image to a more manageable 130MB.

Murphy noted that Fedora last increased the size of /boot from 512MB to 1GB in 2016. Since firmware is getting bigger "at a faster rate than most other things", he wondered if Fedora should increase the volume size.

Luya Tshimbalanga suggested that Fedora should consider making /boot a Btrfs subvolume rather than a dedicated LVM partition. Unlike LVM partitions, Btrfs subvolumes share the storage pool of the entire Btrfs filesystem; therefore, if a Btrfs filesystem has, say, 2TB of space, a /boot subvolume would also have up to that amount available. (Subvolumes can have capacity limits, but not by default.)

Neal Gompa replied that he would like to see that happen, but it is not currently supported by GRUB. SUSE has created a patch for GRUB that allows configuring /boot as a Btrfs subvolume; the patch has not been accepted upstream yet, though. The most recent version of the patch was sent by Michael Chang to the grub-devel list on October 2. There is a bug tracking progress of this feature for Fedora, but it seems clear that it will not be ready in time for Fedora 43; it would no doubt require more testing than simply bumping up the size of /boot.

Rather than making /boot bigger, Zbigniew Jędrzejewski-Szmek asked if it might make sense to get rid of the rescue images instead:

I have been using Fedora for ... a few years now, and I have never used one of those either. If somebody is using the Rescue images, please speak up.

Otherwise, I think we should get a proposal filed for F44 and get rid of them.

Vitaly Zaitsev liked the idea, and said that users could make use of a Fedora live image to repair their system if needed. Marius Schwarz said that was technically true, "but in reality only experts can do this". He argued that the Linux community was continuing to expand, and that there were many users who wanted to use Linux without having to know everything about it. "We have to accept this, or we will never be 'the next coming pc desktop os'." Ultimately, the idea to dump Fedora's rescue image did not gain traction.

On October 1, Murphy pointed out that a fix had been applied to dracut that would reduce the size of the regular initramfs files by about 50%, but the rescue initramfs was still a problem. The NVIDIA firmware alone, he said, was consuming more than 99MB. He proposed that Fedora should set the /boot partition size with the goal that a user could upgrade for five years without having to resize the partition.

I don't have a completely logical process for imagining what the size should be, because I don't know the current let alone the future growth rate of firmware that might need to be in the initramfs. If a lofty goal is that a given partition layout should be possible to upgrade for 5 years without reprovisioning, then maybe 50% free space today is sufficient room to grow over 5 years? That might still be tight but then maybe we'll find a better solution to the firmware problem than stuffing it all in the initramfs?

Schwarz noted that the NVIDIA firmware contained two major releases, splitting the firmware package into two versions could reduce the size significantly. Williamson said that Fedora probably didn't need one of the versions at all; David Airlie replied that he had sent a patch to allow picking only the most recent firmware.

Emergency change

Even with some of the ideas to reduce initramfs size, it was clear that the 1GB constraint was going to continue to be a problem. Despite the fact that it was late in the cycle for such a change, Murphy submitted an emergency system-wide change ticket for FESCo to consider increasing the partition size to 2GB. Simon de Vlieger wondered if the change applied to all Fedora versions or just the x86_64 desktop versions of Fedora. Gompa clarified that it was universal, "because the firmware problem isn't x86-specific. It's way more visible on x86, but it's not an x86-only problem."

Kevin Fenzi said that he was generally in favor of moving to a 2GB partition but did not like doing it at the last minute. He still voted in favor of the change, with the hope it would not cause problems that FESCo had not thought of. Fabio Alessandro Locati also expressed concern but voted in favor as well. Gompa announced that the change had reached seven +1 votes and was approved on October 6.

Upgrades

With the change approved, users installing Fedora 43 should have ample space for upgrades for years to come. However, it does little to help users who have installed Fedora previously who hope to upgrade to 43 when it is released. The documentation of the change simply suggests that users of older releases "may be advised to consider reinstalling instead of upgrading".

Users who are reluctant to reinstall may wish to reduce the number of kernels kept on the system, remove the rescue kernel and initramfs image, or both. To retain two kernels rather than three, users can set installonly_limit=2 in /etc/dnf/dnf.conf. The rescue kernel is generated automatically during installation and is not installed as a package. It would need to be removed manually, and then set "dracut_rescue_image="no"" in /usr/lib/dracut/dracut.conf.d/02-rescue.conf.

Fedora's final freeze for the 43 release started on October 7; according to the tracking bug for the change, updates have been submitted to ensure that the the Anaconda installer and Fedora's image-builder set the partition size correctly. Interested users may wish to help test some of the nightly composes to see if the late change introduces any unexpected problems.

---