+1

Wrong category was set, just fixed it.

For full discussion, see https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/AUPPRDOIEH6QJWMHLFPE5RWQ6EEG2AFN/#WNWRB3FUQN5MCGAOSWKHR5ORW3OD74OW (this is the first message in the giant thread that mentioned moving to a btrfs subvolume)

Per the discussion in Discourse, @davdunc promised to provide some use cases that this Change Proposal would support. Are those ready yet? This CP might have been submitted for voting prematurely - discussion in Discourse has not really finished either.

The change looks reasonable to me, and I don't really understand some of the criticism raised on the discussion thread. The Change explicitly says that Cloud doesn't "rely on" grubenv (for hidden menu / boot count stuff)? If this "does not rely on" really means "does not use" then I would be +1 here ...

It is currently not used there, yes.

Thanks for confirming, then this looks like a nice change: +1 from me.

We're still waiting for @davdunc's use case story. Once we know the goals, we can discuss the possible solutions.

-1. To shortly summarize what I wrote in the discussion thread, using a complicated file system in the phase of the boot before verification goes against the direction where the ecosystem is moving. It'd just add to the pile of technical debt that we'll have to deal with to support SecureBoot and CoCo and measured boot and other similar cases.

I'm going to guess that he still hasn't gotten the permission he was looking for to share. But at least I can share the cases we discussed in person: cloud-agnostic horizontally scaled architectures that leverage "whole system replication" to update software + data (like AI models) on one system and then replicate it everywhere in-place.

In major clouds that provide replication features at the hypervisor level, this seems somewhat superfluous, but in multicloud cases, this is a very powerful capability. Additionally, the majority of Fedora Cloud usage isn't in the major cloud providers, but the variety of VPS and "small cloud" providers and private cloud systems out there, and most of them offer no features for replication.

Furthermore, space contention has been a problem and increasingly so with enlarging initramfs images. So this allows us to avoid that problem and make it cheap to do whole-system replication. Keeping the contents of the ESP small also means it's less necessary to worry about doing replication in a way that requires incremental transfer.

It'd just add to the pile of technical debt that we'll have to deal with to support SecureBoot and CoCo and measured boot and other similar cases.

We literally have an alternate set of images for those cases, and clearly there has been very little interest in expanding on those, so I don't think that's a fair reason to block it.

(Also I will point out that putting stuff on the ESP doesn't fix space contention, it just shifts the problem, since the ESP is a hard partition.)

+1

+1

This was APPROVED (+5, 0, -3) at today's FESCo meeting.

Reference: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QLPMFUG5VSBZW6L5WORW2PVZFB57JJOS/