Last-minute /boot boost for Fedora 43
[LWN subscriber-only content]
Welcome to LWN.net
The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net!
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.
Posted Oct 9, 2025 15:53 UTC (Thu)
by donaldh (subscriber, #151569)
[Link] (2 responses)
Posted Oct 9, 2025 15:56 UTC (Thu)
by jzb (editor, #7867)
[Link] (1 responses)
8GB... wow. I really hope that's just overkill and you're not getting anywhere near filling /boot now.
Posted Oct 9, 2025 16:15 UTC (Thu)
by donaldh (subscriber, #151569)
[Link]
Posted Oct 9, 2025 17:16 UTC (Thu)
by ballombe (subscriber, #9523)
[Link] (1 responses)
Posted Oct 10, 2025 9:03 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link]
The live image typically does not understand anything but the most recent OS version, or is confused by updates on top of the initial install, so it’s a short trip to full reinstall and complete reconfiguration or even data loss. Plus it requires a bootable media and access to ports where to plug this bootable media (which is not quick or easy for anything which is not a laptop designed to be moved).
Posted Oct 9, 2025 17:31 UTC (Thu)
by mb (subscriber, #50428)
[Link]
Posted Oct 9, 2025 18:01 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (1 responses)
Huh. Is it not possible to override this via /etc/, instead of messing with /usr and risk that your change is silently reverted when dracut gets updated?
Posted Oct 9, 2025 19:28 UTC (Thu)
by jannex (subscriber, #43525)
[Link]
Posted Oct 9, 2025 18:10 UTC (Thu)
by shalem (subscriber, #4062)
[Link]
There are some downsides to it, but I believe we have reached a point where the upsides easily outway the downsides, see my blog post from 2 years ago for a detailed listing of pros and cons: https://hansdegoede.dreamwidth.org/28291.html
Posted Oct 9, 2025 18:52 UTC (Thu)
by ebee_matteo (subscriber, #165284)
[Link] (2 responses)
I don't have a separate boot partition anymore (I use systemd-boot).
A lot of us are stuck with 512 MBs for the system EFI. I guess we need a way to move firmware out of the way or also start resizing EFI default partitions...
Posted Oct 10, 2025 7:04 UTC (Fri)
by proski (subscriber, #104)
[Link] (1 responses)
Posted Oct 10, 2025 22:12 UTC (Fri)
by ibukanov (subscriber, #3942)
[Link]
Posted Oct 9, 2025 19:20 UTC (Thu)
by vasi (subscriber, #83946)
[Link] (24 responses)
* Boot gets slower
It doesn't sound like anyone is evaluating the trade-offs here, instead it's just growing by accident. Which is fair, distro maintainers are busy! But maybe it's time to start adding specific release criteria around initramfs sizes, so nobody is surprised next time.
Also, I might be confused about what initramfs is even for these days! To my understanding, we try to put just enough drivers in initramfs to load the root filesystem. Maybe that means a bunch of different disk and filesystem drivers, maybe even network drivers for network filesystems. But why does graphics firmware belong there?
Posted Oct 10, 2025 2:20 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (14 responses)
If there's a LUKS passphrase in the way, you want to have a UI to ask for it. *I'm* fine with a TTY-alike, but that is certainly not the norm…
Posted Oct 10, 2025 4:58 UTC (Fri)
by mb (subscriber, #50428)
[Link] (12 responses)
Posted Oct 10, 2025 5:48 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (6 responses)
Posted Oct 10, 2025 6:05 UTC (Fri)
by mb (subscriber, #50428)
[Link] (3 responses)
Posted Oct 10, 2025 6:07 UTC (Fri)
by vasi (subscriber, #83946)
[Link]
Posted Oct 10, 2025 6:13 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
Posted Oct 10, 2025 6:59 UTC (Fri)
by josh (subscriber, #17465)
[Link]
Posted Oct 10, 2025 6:16 UTC (Fri)
by vasi (subscriber, #83946)
[Link]
Though this is starting to feel like we'll eventually need an extra stage of loading Linux. Eg:
Stage 1: Get to a bootloader. (Obviously there's earlier steps, but let's start here.)
Our forced-memory-resident initrd could be much smaller. Our big stage3 modules could live anywhere that Linux supports, instead of being reliant on the minimal filesystem drivers in bootloaders.
Posted Oct 10, 2025 8:24 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
I can see online that it prompts you for it via a GUI screen, but I'm not clear on whether it uses UEFI graphics, or whether it's able to load enough Windows kernel bits to run the hardware-native display driver at this point.
Put differently, are we trying to be better than Windows on the same hardware (a worthy goal, but one that can perhaps be deferred a bit), or is this a case where not using the native display driver makes us clearly worse than Windows on a given machine (where we need to be equal or clearly better to be a competitive alternative)?
Posted Oct 10, 2025 6:34 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Another reason is localization. UEFI doesn't have characters outside of ASCII. Neither does it support alternative input methods, such as on-screen keyboards.
Posted Oct 10, 2025 6:59 UTC (Fri)
by xecycle (subscriber, #140261)
[Link] (3 responses)
As for characters I think it doesn't matter if we draw characters in initramfs software; but if user decides to include special characters in their password that will be fun to support.
Posted Oct 10, 2025 11:38 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (2 responses)
File systems care, except that it mostly doesn't matter because one clicks on or copy-pastes or autocompletes these things.
Posted Oct 10, 2025 17:13 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
Yes, that does mean that attackers don't have to guess whether your password uses combining or precomposed diacritical marks (assuming arguendo that your password even has diacritical marks to begin with), but that is at most a few extra bits of entropy on top of a (hopefully) much stronger password. You should not be depending on the lack of normalization for password entropy.
You might also worry that this will somehow break in a future version of Unicode, but it is actually pretty safe. The Unicode stability policy provides that, when a string contains only code points defined in version X of Unicode (for reasonably recent X), the normalization of that string according to Unicode version X will be identical to the normalization in version Y >= X. In plain English: The normalization form is not allowed to change, provided that all of the characters in the input string are mapped in the version of Unicode that you used to normalize it.
This does, however, imply that you need to scan the input string for invalid or unmapped code points, and reject them. This is far less restrictive than most password input boxes, because it still accepts every real character that anyone could use for any serious purpose, including private use characters (so we even support the people who insist on using Klingon etc. despite Unicode having rejected it multiple decades ago). Given the relative lack of stability in third-party private use standards (i.e. different organizations have proposed different private use code points for substantially or exactly identical characters), I think we would be within our rights to reject those, but it's more debatable.
I'm sure somebody will now reply and say that a key derivation function (or password hasher) should just accept raw blobs of bytes and not care about any of this Unicode nonsense. That is correct, such a function should accept arbitrary bytes and totally ignore Unicode. The above comment is not about the KDF. It is about the UI that sits in front of the KDF. That UI has to consistently turn the same text into the same bytes, or else users will get locked out of their accounts. This is exactly the same problem as "make sure the password is always UTF-8, or some other specific fixed encoding," just at a slightly higher level of abstraction.
Posted Oct 10, 2025 19:29 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
Yes. That's the basic idea. The question is, however, whether everything in the stack bothers to do that.
I'm too unsure of the answer to that question being "yes" to risk adding diacriticals (or whatever) to my password. More's the pity, since that would add another fun layer to password cracking attempts (which in turn would allow me to get the same level of security with a shorter password).
Posted Oct 10, 2025 6:08 UTC (Fri)
by vasi (subscriber, #83946)
[Link]
Posted Oct 10, 2025 9:09 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link] (8 responses)
I do wish manufacturers stopped bloating their firmware. When it gets so fat init takes more time than the various boot prompts you have a problem.
Posted Oct 10, 2025 9:39 UTC (Fri)
by geert (subscriber, #98403)
[Link]
I guess open-sourcing would help. Cfr. how much some Linux drivers shrunk during upstreaming.
Posted Oct 10, 2025 9:48 UTC (Fri)
by WolfWings (subscriber, #56790)
[Link] (6 responses)
The 'tiny font on a 4K screen' is just because most distro's don't enable the Terminus 16x32 console font or otherwise aren't switching to it. fbcon=font:TER16x32 as a kernel command-line argument will switch to it, and honestly it should likely be the default these days unless dealing with something smaller than a 1280x800 screen where you'd drop below 80x25.
Posted Oct 10, 2025 12:56 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link] (5 responses)
Posted Oct 10, 2025 14:25 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (3 responses)
The "tiny font on a 4K screen" problem actually won't go away just because you swap the UEFI GOP driver for a proper one. The only thing it might help with is if the proper driver communicates the physical screen dimensions/DPI, which in turn might prompt the splash screen renderer to adjust its scaling factor. However, I have no idea if this is actually implemented anywhere; my bet is "no".
Posted Oct 10, 2025 15:27 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (2 responses)
If the very screen itself misreports its dimensions, you're stuck.
Posted Oct 10, 2025 15:44 UTC (Fri)
by daroc (editor, #160859)
[Link]
Posted Oct 10, 2025 17:57 UTC (Fri)
by WolfWings (subscriber, #56790)
[Link]
If it's at least 1280x800? Chuck the 16x32 font at it. Always. 8x16 fonts were from the 640x400 days, not even 640x480. And the 4x6 kernel font was added to handle early low-res 320x200 and similar micro-screens.
I don't want my letters to be 4x6 pixels just because I'm on a cheap hotel 40" 720p TV for the night and it tries to pick the font closest to 12 points tall.
If I've got the pixel budget for large, readable fonts the text console should use it as long as I get at least 80x25, or some other tunable if Linux decides a larger console is the minimum now.
Trying to match to a specific physical size is a printing/publishing issue and only tangentially a window-manager one, not a text console one. If anything I'm constantly fighting the "fixed physical size" attempts because they result in blurry webpages and other things from trying to force-rescale bitmaps by single digit percentages.
Posted Oct 10, 2025 17:53 UTC (Fri)
by WolfWings (subscriber, #56790)
[Link]
If the framebuffer console works (which on anything remotely recent that has working UEFI it will) then the font will display properly.
They literally added it to deal with the 'retina macbook' issue of a 15" 4K screen becoming common on laptops, so the console was readable again.
Just a lot of distro's decided "It's not VGA! YEET!" and it's taken a while to get them to leave it enabled like they should have from the start.
Posted Oct 10, 2025 10:55 UTC (Fri)
by gray_-_wolf (subscriber, #131074)
[Link] (2 responses)
Posted Oct 10, 2025 11:50 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
This makes way the root FS is fairly clean; also I can clone the subvolume and then run a test installation, either directly or via systemd-nspawn, without the test stuff being visible from the root *or* vice versa.
Posted Oct 10, 2025 17:06 UTC (Fri)
by ballombe (subscriber, #9523)
[Link]
Seems legit
Seems legit
Seems legit
Rescue images
Rescue images
All drivers present?
De-rescuing
De-rescuing
Time to move the GPU drivers out of the initrd and rely on EFI framebuffer in the initrd
What about EFI?
systemd-boot supports XBOOTLDR partition to avoid changing the EFI partition on every kernel update. I use XBOOTLDR on NixOS, a distro that defaults to systemd-boot. I'm not sure if Fedora would support it; I would stick with GRUB to boot Fedora.
What about EFI?
What about EFI?
Trade-offs
* Kernel upgrades get slower
* Machines with low RAM lose the ability to boot
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Stage 2: Load Linux and initrd into memory. We need just enough in initrd to access some real storage in early userland.
Stage 3: Initrd loads further modules from storage, for things like LUKS passwords. Eventually loads root fs and boots to full userland.
Out of interest, how does Windows handle it when it needs a Bitlocker recovery key?
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Not so for passwords.
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Trade-offs
It's not even implemented reliably in screens - I've had more than one screen report itself as 16cm x 9cm, even though the diagonal is very obviously a lot more than that (even a 11" laptop screen is 25cm diagonal).
Trade-offs
Trade-offs
Trade-offs
Trade-offs
Why a separate partition at all?
Why a separate partition at all?
Why a separate partition at all?