Bug 2209582

Summary:	Custom / advanced custom storage summary never appears, cannot proceed with installation
Product:	[Fedora] Fedora	Reporter:	Adam Williamson <awilliam>
Component:	mutter	Assignee:	Florian Müllner <fmuellner>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	amigadave, anaconda-maint-list, fmuellner, gnome-sig, jadahl, jkonecny, otaylor, philip.wyett, vponcova, vslavik, walters, w
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	openqa
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-07-23 22:44:31 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2143444

Description Adam Williamson 2023-05-24 06:04:36 UTC

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.

Comment 1 Adam Williamson 2023-05-24 06:05:51 UTC

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.

Comment 2 Adam Williamson 2023-05-24 06:11:35 UTC

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 ).

Comment 3 Adam Williamson 2023-05-24 06:13:15 UTC

I guess gtk3 (which went from 3.24.37-1.fc39 to 3.24.38-1.fc39) might also possibly be a suspect.

Comment 4 Jiri Konecny 2023-05-24 11:45:44 UTC

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.

Comment 5 Adam Williamson 2023-05-24 15:52:51 UTC

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.

Comment 6 Adam Williamson 2023-05-24 19:32:54 UTC

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.

Comment 7 Adam Williamson 2023-05-24 19:37:06 UTC

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.

Comment 8 Adam Williamson 2023-05-24 20:41:42 UTC

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.

Comment 9 Adam Williamson 2023-07-23 22:44:31 UTC

This is indeed fixed.