The Fedora installer includes an EFI System Partition of between 200MB and 600MB by default, of which the lower size is much too small for firmware updates on modern hardware and also for future bootloader features like UKI. This change will increase the minimum size of the ESP to be 500MB, which is also the same value used by Microsoft for Windows 10 and newer.
Owners, do not implement this work until the FESCo vote has explicitly ended. The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.
REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the devel list thread linked above.
+1 🥾
We should verify that ESPs that large work in various environments (especially if that means it's now a FAT32 filesystem, as not all UEFI implementations handle that well).
Otherwise, though... sure +1
+1
Hmm, I somehow missed the discussion of this on fedora-devel. I'll reply there with some questions.
Procedural -1 to delay approval here.
This is a well-defined, narrow change that fixes very specific use cases (i.e. making sure fwupd and kernel / initrd updates continue working even as the files involved will get bigger). I'm sure there are other ways in which we can improve the boot setup, but those can (and should!) be handled separately.
Metadata Update from @amoloney: - Issue tagged with: meeting
Tagging for discussion at next meeting as per comment requesting.
This will be discussed at today's meeting at 17:00 UTC.
This was discussed in today's FESCo meeting: * AGREED: APPROVED (+5, 2, 0)
Metadata Update from @zbyszek: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @zbyszek: - Issue untagged with: meeting
For FESCo awareness, this Change led to quite a bit of fallout:
Reading back the description of the change, it seems kinda inaccurate to how it really works in practice. The Change talks a lot - explicitly and implicitly - about the 500M size:
"This change will increase the minimum size of the ESP to be 500MB, which is also the same value used by Microsoft for Windows 10 and newer."
"Install Fedora and observe that /boot/efi has at least 276MB free space, even when installed alongside Windows."
"Anaconda would need to be modified, and Fedora would have a / or /home partition that's ~300MB smaller by default than it is now."
Those "276MB" and "~300MB" numbers are calculated based on an ESP size of 500M. But that's not really what the Change does in practice in most cases. In almost all cases, the ESP will be 2G. As the bugs above show, even when installing to a 6G disk, with the current implementation, we wind up creating a 2G ESP, 1G /boot, and only 3G root partition. anaconda's "grow" behaviour with guided/automatic partitioning will make the partition as large as it possibly can be, up to the max size, so in practice it almost always goes with 2G.
I don't know if we consider that a problem, but I think it needs to be more clearly understood. This Change isn't really about making the ESP "usually 500M or so". It's about making it "almost always 2G".
@rhughes ?
Could we go back to my original patch and make the ESP at minimum 500MiB and at most 600MiB? The reason I bumped the biggest IIRC was for the UKI crowd that said that 500MB was too small for them -- but it seems it's caused other problems.
That would be an option, yeah. The drawback there would indeed be that if we want to go to UKIs by default in future - which seems like a definitely possibility - we might just have to change this again, and anyone who installs between now and then may be in trouble...
None of the "problems" encountered so far are super-fatal, I just worry that we're not super clear on the effect and may be surprised when this reaches users. It's most obviously an issue when you have relatively little storage (e.g. on a VM or if using a smallish USB stick or SD card for install) - as I said, even if you're installing to as little as 5GB of space, anaconda tries to allocate a 2GB ESP. I wonder if there's any way to make anaconda's scaling smarter than just "use the max possible size if it can be squeezed onto the disk at all, no matter how tiny that makes everything else"?
Having the partition "grow" to 2 GB "almost always" does not sound like it was the intended outcome ... isn't there an option to set some fractional amount to scale size linearly? Something like "at least 500 MB plus 1% of available disk space but at most 2 GB"?
It'd be best to get input from some anaconda/blivet devs, but I think currently anaconda/blivet may not implement such an advanced algorithm. Let's tag @vtrefny - Vojtech, can you give us some info on how exactly the implementation works in this case (where we have the ESP min size set to 500M and the max size set to 2G), and if there are any ways we can tweak that behaviour? I know what I see when I run the openQA tests on it, but I haven't actually looked at the exact logic behind it. Thanks!
Log in to comment on this ticket.