Do we know why the test now needs more space than it used to, out of curiosity?

I've not done a thorough investigation but we used to be able to build Silverblue & Kinoite images in this CI and those ostree images are significantly much larger than the one we're currently building.

Thus I strongly suspect that the size of the root disk as been reduced on the Zuul labels/images and it's not our CI builds getting that much bigger.

I don't know where the Zuul labels/images are configured so I can not check that assumption.

I've found https://softwarefactory-project.io/cgit/config/tree/nodepool/virt_images/cloud-fedora-rawhide.yaml but I'm not sure if that's the right place.

From further investigation (https://fedora.softwarefactory-project.io/zuul/build/b96b0dce2a5a456e8602849527d33faf/console#1/0/2/vm), it looks like the disk is "still" 100GB in size, but the main btrfs partition is not grown (likely from the 4GB default) to use the full disk size on first boot.

Maybe a package dependency got removed and that removed the tool that was doing this on first boot.

Oh, hah, I know what that is: https://github.com/canonical/cloud-init/issues/5614

I did not realize that @ngompa sent btrfs-progs 6.10 to F39 and F40. I will backport the cloud-init fix to those branches as well, then.

https://bodhi.fedoraproject.org/updates/FEDORA-2024-d44bd4abd9 will fix this for F40 when it goes stable. I caught the F39 btrfs update before it went stable, so I'll edit a cloud-init build into that update and F39 should not break.

Good catch. Thanks! We'll have to ask the SoftwareFactory folks to rebuild the image once this lands in stable.

it'd help if people can karma it, of course.

I've re-enabled the CI with https://pagure.io/workstation-ostree-config/pull-request/563 and it passed so I think we can consider this one fixed. Thanks!