We probably need to go to 2GB /boot and adjust both Anaconda and kiwi descriptions for this. @supakeen will need to make similar changes to Image Builder's Fedora definitions.

FWIW, this situation will be even worse for ARM, because there is even more firmware blobs that are system specific.

Because of the urgency and time before final freeze is short, I'm fast-tracking a proposal:

Proposal: Fedora Linux 43 raises the default /boot partition size to 2.0 GiB across all configurations. This includes Anaconda, kiwi-built images, and osbuild-made images that use a separate /boot volume.

For the record, I'm +1 for this.

meh-+1 for the proposal and ack for the fast-track

As for nvidia stuff ... I thought I read somewhere that having a lot of big firmware files for it was kind of a transition problem, with there currently being both GSP and non-GSP firmwares included for a lot of cards, and the non-GSP variants can be removed after that transition period is over? So that might actually help make things smaller (to some degree) again at some point?

For what it's worth, the changes necessary to implement this have been drafted and are ready to land:

• Anaconda: https://github.com/rhinstaller/anaconda/pull/6678
• kiwi-descriptions: https://pagure.io/fedora-kiwi-descriptions/pull-request/224
• osbuild: https://github.com/osbuild/images/pull/1918

These are all marked Draft/DNM until the decision is made to raise it.

meh-+1 for the proposal and ack for the fast-track

As for nvidia stuff ... I thought I read somewhere that having a lot of big firmware files for it was kind of a transition problem, with there currently being both GSP and non-GSP firmwares included for a lot of cards, and the non-GSP variants can be removed after that transition period is over? So that might actually help make things smaller (to some degree) again at some point?

Yes, taking out the old firmwares would save about 32M. See https://src.fedoraproject.org/rpms/linux-firmware/pull-request/22

This issue will resurface until GSP gets a stable API (which IIRC NVIDIA has indicated there will be one as part of NVIDIA working upstream on Nova).

@pvalena

I'm uncertain if this bump is needed or desired on ARM desktops. They are more space constrained and tend to depend on images so for now I'm keeping the scope narrow to x86_64 desktops that use anaconda for installation.

In the upstream PRs the scope is wide but in the description the scope is narrower; can we clarify if this should apply only on x86 desktops or also the rest? :)

I'm uncertain if this bump is needed or desired on ARM desktops. They are more space constrained and tend to depend on images so for now I'm keeping the scope narrow to x86_64 desktops that use anaconda for installation.

In the upstream PRs the scope is wide but in the description the scope is narrower; can we clarify if this should apply only on x86 desktops or also the rest? :)

My proposal is everywhere, because the firmware problem isn't x86-specific. It's way more visible on x86, but it's not an x86-only problem.

The motive for the change is having a big enough boot on new clean Fedora 43 installations so they can be upgraded for 5 years.

I agree with the idea of the change in general. But I'd like to see some discussion and justification for why this change qualifies for the Blocker/Exception status for the F43 release.

Has it been discussed at the Blocker&Exception review meeting?

The motive for the change is having a big enough boot on new clean Fedora 43 installations so they can be upgraded for 5 years.

I agree with the idea of the change in general. But I'd like to see some discussion and justification for why this change qualifies for the Blocker/Exception status for the F43 release.

Has it been discussed at the Blocker&Exception review meeting?

I didn't see any request for marking it a blocker in this thread, at least. For now, the urgency is to try and land it before a Blocker decision needs to be made.

I'm +1 for Neal's proposal.

There's more than one thing going on at once.

The first issue that came to my attention is a change in dracut-107 that doubled the hostonly initramfs sizes for most everyone. This landed in Fedora 42 and 43. This came up in devel@ discussion and a bug report which was nominated as a blocker bug on the basis that it might inhibit some upgrades.

The dracut changes have been reverted in Fedora 42, and probably still need to be reverted in Fedora 43. The main concern at that time was legacy 500 MiB boot volumes.

Subsequently in that same bug report, a user with nvidia hardware reported a 1 GiB boot volume at 98% full with Fedora 43 with just the 1 rescue and 3 hostonly initramfs present. So what's going on here?

Everyone on Fedora 43 performing new clean installs are seeing very large rescue initramfs because of amdgpu and nvidia gpu firmware sizes significantly increasing in the last six months. But only the users with nvidia firmware are also seeing very large hostonly initramfs.

And none of that violates any release criteria.

Nvidia firmware is currently at ~ 100 MB, and will be replicated 4 times on the boot volume for systems with nvidia gpus. That's in addition to the still ~2x initramfs size due to dracut-107 changes that have not yet been reverted in Fedora 43.

It's true most users probably don't need a 2 GiB boot. But it's also true that all reasons for initramfs size increases are pernicious problems that don't affect all the same systems to the same significance, and even with a 98% full boot volume there is no warning or hard failure.

And hence it sorta all snuck up on us.

I'm in general in favor of moving to 2G, but I really don't like dropping this at the last minute without a chance to get much feedback. ;(

If we do this for f43, we should probibly at least create a simple change and approve it late for visibility and perhaps mark it a 'fesco blocker'

So, I guess weak +1, but document and hope it doesn't cause problems we don't know about...

I think we should do this, already for F43: +1

My reasoning:
- having an extra GB of space taken out of the real storage is definitely not great, for users with cheap laptops and tiny disks this is noticeable,
- … but the failure mode of running out of space is really bad, so it's worth the cost to avoid this scenario.
- There are some other things we could do, incl. reworking how firmware is packaged and/or getting rid of the Rescue images, but this is material for F44, too late to do it in F43.

FWIW, I agree with Kevin that a rubberstamped Change proposal to increase visibility would be great.

I can write a Change document that is tagged as accepted after this is approved and implemented with some assistence from @chrismurphy.

I'm a little concerned about a change that will impact all new installation landing this late in the cycle.
For the change itself, I'm +1

+1 and the change needs to happen.

This has now reached 7 +1 votes, so it is now APPROVED.

Here is the F43 change document: https://fedoraproject.org/wiki/Changes/2GbootPartition

Thanks @ngompa !

Can we get @amoloney to process the Change document to get it added to the ChangeSet for F43?

yes, but she is out today, I'm sure she will see it tomorrow when she gets in.

I can do it.

All done, change is announced, accepted and in the Changeset page. Tracking bug etc. have been created.

Then this is completed and will be closed once announced in tomorrow's FESCo email.

Announced. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PPWGUA3QJZJJW5XAMVY2VD4ZHJBGTCCO/

Heads-up: Increasing the /boot partition size from 1 GB to 2 GB has an unintended side effect for WebUI. The Web UI “Reinstall Fedora” (also known as the “Home reuse”) option will now fail when the previous Fedora installation used the entire disk, because there’s no remaining free space to create the new, larger /boot partition. This effectively breaks the reinstall path for those full-disk setups.

https://github.com/rhinstaller/anaconda/pull/6678#issuecomment-3381496496

Welp...

Alternative idea:

Revert the change, keep it 1 GiB, but then set installonly_limit=2 in /etc/dnf/dnf.conf. For that matter, this could be done for Fedora 42 users who don't have an installonly_limit set, further reducing the risk of those users hitting the problem unless they intervene before hitting it.

An expected partial revert for dracut sloppy mode changes making the non-rescue initramfs bigger, will further reduce the usage stress on boot.

There's also upstream patch and discussion on dropping the 535 firmware, for still more reduction.

Probibly if you want to move that idea forward, post it in the discussion? This issue is already closed/done.
I'm not a fan of it though. It means if you have a kernel update that causes you problems, you go back to the older working one, new update comes along, you will need to quickly determine if it's going to work for you before the next update comes along and replaces the old working kernel you had.

The Web UI “Reinstall Fedora” (also known as the “Home reuse”) option will now fail when the previous Fedora installation used the entire disk, because there’s no remaining free space to create the new, larger /boot partition.

Just to make sure we're all on the same page, it should still be possible to reinstall Fedora, even in this setup. But instead of using the simple "Reinstall Fedora" option, you'll need to go to "Mount point assignment" and assign mount points to partitions manually. I plan to document the workaround in a common issue, if we release F43 in this state. Of course, this approach requires a bit more knowledge (or finding the common issue documentation), and there's a risk that the user configures something incorrectly.