FinalBlocker +1

As mentioned in the ticket, this can break updates from F41 on systems with the previous default boot partition size, so a violation of the upgrade requirements criteria.

FinalBlocker +1

I think this doesn't violate the stated criterion:
https://bugzilla.redhat.com/show_bug.cgi?id=2394213#c8

But let's wait for Adam to clarify.

FinalBlocker +1

Discussed at the 2025-09-15 (blocker / freeze exception) review meeting:

This bug is accepted as a violation of the "Upgrade requirements" criterion because increasing the initramfs space makes the system unable to upgrade if the space on the boot partition is taken by bigger images. It is considered serious enough to be addressed before the Final release.

https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2025-09-15/f43-blocker-review.2025-09-15-16.00.txt

Lukas forgot to do it above, so:
AGREED AcceptedFinalBlocker

From the meeting log:

<@nielsenb:fedora.im> This one basically boils down to, do we see upgrades of legacy installs with smaller /boot partitions as blocking?
<@conan_kudo:matrix.org> yes
<@conan_kudo:matrix.org> that is a natural consequence of making in-place upgrades a release-blocking exercise

No, our criteria are pretty clear in this regard. I think we've accepted this as a blocker incorrectly. I didn't vote in-ticket because I wanted to give Adam chance to respond in bugzilla.

It's a big problem for some part of our users, yes, but those users already hit it in F42, so blocking F43 doesn't really affect them. Sure, the blocker can serve as a hammer to fix it for them even in F42, but it doesn't feel like a clean process. Also, we can't support 500MB /boot forever, and so the required reinstall/partition change during F42->F43 is a reasonable request, also according to the maintainer. But this blocker requires such support to continue, without any justification in the release criteria.

The following votes have been closed:

• Accepted FinalBlocker (+3, 0, -0)
  • +1 by derekenz, nielsenb, ngompa

Lukas forgot to do it above, so:
AGREED AcceptedFinalBlocker

From the meeting log:

<@nielsenb:fedora.im> This one basically boils down to, do we see upgrades of legacy installs with smaller /boot partitions as blocking?
<@conan_kudo:matrix.org> yes
<@conan_kudo:matrix.org> that is a natural consequence of making in-place upgrades a release-blocking exercise

Oh no, it's me! :D

You'll notice in the log I also mention this is effectively already breaking things for people.

I went digging, I'm pretty sure this F39 change is where we embiggened things in the hopes stuff would keep fitting. By my math, that makes 4 releases. The criteria in question explicitly calls out 2 releases. So if we're being literal in our reading, this is not a blocker. But if we want to give people a bit of grace in doing full reinstalls instead of updating in place, F39 wasn't that long ago.

Really, I'm happy either way with this one. The fact things are already broken for people does somewhat soften the blocker argument, as does an exact reading of the criteria. But I do think in the future, changes that mandate a reinstall to actually take effect should include a "in place updates will no longer be supported because of this in X releases", or the criteria should be updated to say "bugs caused by changes mandating a reinstall can not be blockers". Especially since firmware keeps growing, so I'm sure another embiggening will happen eventually.

this F39 change is where we embiggened things

This was the change for making the /boot/efi partition bigger (i.e. the EFI System partition), not about /boot.

this F39 change is where we embiggened things

This was the change for making the /boot/efi partition bigger (i.e. the EFI System partition), not about /boot.

In that case, I don't see the change where we enlarged boot. I either completely missed it, or it happened before F30 which is as far back as I went.

If it's the latter, I agree this shouldn't be a blocker on the basis it breaks updates for "legacy" boot partitions.

The oldest image I have available is Fedora 27 Workstation Live, and that still created 1GB /boot by default. So if this was the only reason to accept it as a blocker, I think it was a mistake.
Poke @adamwill

Boot went from 500M to 1G in ~2016. Yes it's been a while but nevertheless the change is causing issues.

The main concern I have is future growth of sloppy initramfs, due to more firmware in sloppy initramfs, and firmware growth is significant. What if 1G boot isn't enough in 6 months? Or even in 4 years? We haven't evaluated the effect of sloppy because there hasn't been a change proposal.

Part of a change proposal would explore when today's new installations might not be upgradeable, and need reprovisioning. The sloppy initramfs has a greater unknown max size over time dilemma.

Boot went from 500M to 1G in ~2016. Yes it's been a while but nevertheless the change is causing issues.

This is actively discussed upstream and solution is sought for - for next upstream release; most probably: some partial reverts (already prepared), and a new option for more granularity WRT changing the size/configs [more info in the Bug].

The main concern I have is future growth of sloppy initramfs, due to more firmware in sloppy initramfs, and firmware growth is significant. What if 1G boot isn't enough in 6 months? Or even in 4 years? We haven't evaluated the effect of sloppy because there hasn't been a change proposal.

There was no configuration change, no new option added. Upstream simply decided to include more stuff into initrd in (hostonly mode - a default since forever in Fedora). Calling it "sloppy" was just a cosmetic change (in 2018: https://github.com/dracut-ng/dracut-ng/commit/a695250ec7db21359689e50733c6581a8d211215). No modes were added or changed since.

Part of a change proposal would explore when today's new installations might not be upgradeable, and need reprovisioning. The sloppy initramfs has a greater unknown max size over time dilemma.

Feel free to discuss this upstream; I don't think we should diverge much as a distribution from all of the others, when there's no clear breakage or benefit.

That said, I have a revert prepared, although it's different from corrent upstream-proposed changes (in latest upstream release there is also more of such changes).
I'd rather wait for upstream decision and then I can backport / evaluate that. I'd rather avoid changing the downstream patches several times (or introducing more divergence from upstream behavirour overall - which could introduce some issues on its own).

Release F43 is no longer tracked by BlockerBugs, closing this ticket.