In Fedora-Rawhide-20230523.n.1, all custom and "advanced custom" (blivet-gui) partitioning tests failed. It seems that, once the test does whatever partitioning it wants to do and clicks Done, the storage summary that should appear next never does; the UI is just stuck showing the partitioning screen (shaded a bit) and it's not possible to proceed with installation. See e.g. https://openqa.fedoraproject.org/tests/1951016#step/disk_custom_blivet_standard_partition_ext4/33 Reproducible: Always Steps to Reproduce: 1. Download https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20230523.n.1/compose/Server/x86_64/iso/Fedora-Server-dvd-x86_64-Rawhide-20230523.n.1.iso and boot it 2. Proceed to "custom" or "advanced custom" partitioning 3. Complete a sensible partitioning setup and click Done Actual Results: UI is stuck showing the partitioning screen, faded a bit Expected Results: UI should show a storage summary and allow you to proceed with install In 20230523.n.1, anaconda changed from 39.15-1 to 39.16-1. python-blivet changed from 3.7.1-2 to 3.7.1-3. Not sure which is the cause (or if it might somehow be something else), filing against anaconda for now.
Proposing as a Beta blocker as a violation of the custom partitioning criterion - https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Custom_partitioning . None of those requirements are met if you cannot actually complete a custom install at all.
Hmm, possibly related(?), nm-connection-editor doesn't seem to appear when clicking Configure... on the NETWORK spoke either. But yelp *does* load when clicking Help (unlike with https://bugzilla.redhat.com/show_bug.cgi?id=2203455 ).
I guess gtk3 (which went from 3.24.37-1.fc39 to 3.24.38-1.fc39) might also possibly be a suspect.
Might be related to the bug 2170716. I tested to add property to glade file as described in bug 2170716 and it seems to resolve the issue so this is most probably a duplicate. Switching to mutter for further triage.
Well, I agree the symptom is very similar, but it can't really be a *duplicate* of that bug, as nothing related to the exact cause of and fix for that bug changed in the affected compose AFAICS. The problem there was that after mutter added a dep on gtk4, we needed to stop stripping some stuff from libtiff and gtk4 out of the installer environment in the lorax scripts; we have not changed that in lorax (we are still keeping those bits in the installer environment), and neither gtk4 nor mutter changed in the affected compose. So while the symptom does indeed look the same, it can't be the exact same cause, I don't think.
So, huh. Some findings. 1. I can reproduce this locally with images from the last two official composes (0523.n.1 and 0524.n.0), but *not* with images built by openQA tests of recent updates (in the last couple of hours). This unfortunately blows a hole in my plan to test whether gtk3 is/was really the cause or not, which relied on being able to reproduce the problem with openQA-built images. I'm not sure if this means the problem has somehow magically been fixed since the 0524.n.0 compose ran, or if there's some sneaky difference between how openQA is building images and how the official compose is doing it (I try to make openQA's process as similar as possible to the 'real' composes). 2. This definitely doesn't have the exact same cause as 2170716 - I checked, and an affected image *does* contain the files from libtiff and gtk4's /usr/bin/* files. They are not somehow getting stripped again.
There *has* been a new mutter build between when 0524.n.0 ran and now; 0524.n.0 images have mutter-44.0-2.fc39.x86_64 , the openQA-built images I tested have mutter-44.1-2.fc39.x86_64 . So that might have fixed it.
OK, yeah, confirmed: mutter-44.1-2.fc39 fixes this. I did a scratch build of mutter-44.0-2.fc39 with the epoch bumped to 1, had openQA build an installer image with that mutter in it and the rest of current Rawhide, and it has the bug. So this should go away in the next compose. Woot.
This is indeed fixed.