This is fallout from the EFI system partition size change - https://bugzilla.redhat.com/show_bug.cgi?id=2208181 - in a sense, but I think the problem is actually more generic than that, and you could hit it with the old EFI system partition size definition if you were really careful/unlucky.

Since that Change came in, an openQA test is consistently failing:
https://openqa.fedoraproject.org/tests/1973152

That test boots the Everything netinst image (which defaults to the "Fedora custom OS" package set, i.e. minimal), then changes the package set to Workstation, then runs through the Installation Destination (partitioning) spoke selecting automatic partitioning, then enables the root account and creates a user account.

Somewhere during that process, the install gets blocked because anaconda decides there isn't enough space available. The test uses a 13GB disk image. I can resolve the issue for openQA by just using a bigger disk image, of course, but it feels to me like there's a bug here.

It seems like the error isn't visible on the hub when we leave the Software Selection or Installation Destination spokes, and there's no warning or error shown on the Installation Destination spoke at any time when we're on it. But after we leave the Root Account spoke, *then* the error shows up.

From the logs it seems like anaconda sets the EFI system partition size to 2GiB - the largest possible size from the 600MiB to 2GiB range that it can be. It doesn't seem to consider reducing its size to solve the space deficit at any point.

To me, it seems like there's a couple of issues here: the lack of an error/warning when we are on the Installation Destination spoke (unless, somehow, enabling the root account makes the expected install size over 600MiB bigger or the projected available space over 600MiB smaller?), and the apparent failure of anaconda to consider reducing the size of the ESP to 'solve' the space shortage.

Reproducible: Always