Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 2239128

Summary: pop-up screen is stuck when try to format a partition
Product: [Fedora] Fedora Reporter: lnie <lnie>
Component: mutterAssignee: Florian Müllner <fmuellner>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 39CC: adscvr, amoloney, awilliam, cgarnach, fmuellner, gmarr, gnome-sig, jadahl, kparal, lruzicka, mcatanza, mkolman, nielsenb, otaylor, philip.wyett, robatino, vtrefny, walters
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard: AcceptedBlocker
Fixed In Version: mutter-45.0-7.fc39 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-10-09 22:26:46 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: 2143446    
Attachments:
Description Flags
journal
none
stuck-anaconda.log
none
storage.log
none
screencast
none
bare metal storage.log
none
bare metal anaconda.log
none
journal from bare metal
none
screencast
none
screencast with pointer shown
none
screencast none

Description lnie 2023-09-15 11:41:50 UTC
I've seen this format pop-up page get stuck problem many times,a reliable reproducer is Boot the installer on a VM containing only standard partitions(created using blivet-gui),click into blivet-gui,try to format any device,you will find the pop-up screen gets stuck  

Reproducible: 100%

Comment 1 lnie 2023-09-15 11:58:08 UTC
Created attachment 1988973 [details]
journal

Comment 2 lnie 2023-09-15 11:59:13 UTC
Created attachment 1988975 [details]
stuck-anaconda.log

Comment 3 lnie 2023-09-15 11:59:58 UTC
Created attachment 1988988 [details]
storage.log

Comment 4 lnie 2023-09-15 12:04:33 UTC
Created attachment 1989014 [details]
screencast

Comment 5 lnie 2023-09-21 15:18:46 UTC
Created attachment 1989868 [details]
bare metal storage.log

Comment 6 lnie 2023-09-21 15:19:45 UTC
Created attachment 1989869 [details]
bare metal anaconda.log

Comment 7 lnie 2023-09-21 15:20:46 UTC
Created attachment 1989870 [details]
journal from bare metal

Comment 8 lnie 2023-09-21 15:24:50 UTC
This bug is 100% reproducible on bare metal,propose as a blocker to get more attention,besides it violates:https://fedoraproject.org/wiki/Fedora_39_Beta_Release_Criteria#Custom_partitioning

Comment 9 lnie 2023-09-21 15:25:58 UTC
> is 

is also

Comment 10 Kamil Páral 2023-09-25 13:19:17 UTC
(In reply to lnie from comment #4)
> Created attachment 1989014 [details]
> screencast

It would be helpful if we could see the cursor (you can enable it in the gnome-shell dialog when starting the screencast).

But I can confirm this issue, I've also seen it in the past. It seemed to me to be a race condition, happened only sometimes. If I remember correctly, the workaround was to use Esc to cancel the current dialog, and then invoke it again.

Comment 11 Geoffrey Marr 2023-09-25 23:38:44 UTC
Discussed during the 2023-09-25 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as ,per @kparal, it seems this might be a timing issue and it would be good for other folks to test and see if they're affected and if so, how often (and maybe get some feedback from the devs). We will punt for at least a week.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2023-09-25/f39-blocker-review.2023-09-25-16.02.txt

Comment 12 lnie 2023-09-26 02:50:52 UTC
Please note,you may see format(or mount point) pop-up get stuck in different reproducers, but if you try exactly the one I mentioned in the description,you will find it is 100% reproducible,so I don't think we should considered this as a race condition.Kamil's workaround does work in VM,but somehow,doesn't work well in bare metal,as you can see from the screencast I'm gonna to attach,the pop-up gets stuck again and again,so users wouldn't have a chance to reformat the device they like.

Comment 13 lnie 2023-09-26 02:51:35 UTC
Created attachment 1990548 [details]
screencast

Comment 14 lnie 2023-09-26 02:57:06 UTC
Created attachment 1990549 [details]
screencast with pointer shown

Comment 15 Lukas Ruzicka 2023-09-26 09:33:41 UTC
I have tried to reproduce this in a VM as I do not have any bare metal machines that I could destroy and reinstall. On the VM, I was able to see the following behaviour:

a) The pop-up window never gets stuck when trying to format the most right partition in the Blivet-GUI overview. For example, when I have vda1 and vda2, this never happens when interacting with vda2, but it can be triggered when interacting with vda1. However, when I add a vda3, I can trigger the behaviour on both vda1 and vda2 but not on vda3. See note 1.
b) With the above, I was seeing the behaviour in approximately 25 - 33% of interactions, otherwise it worked just fine.
c) This happens on VM with 2046 MB ram, as well as with 4096 ram, so I tend to believe that the problem does not depend on the size of available memory.
d) I was always able to use the Esc key to cancel the operation and start over, but Lily is reporting that you cannot do it on bare metal. I cannot test this.


Note 1: When I see I cannot trigger the behaviour, I mean that I have tried 10 times without triggering that.

Comment 16 Vojtech Trefny 2023-09-26 10:58:17 UTC
*** Bug 2239756 has been marked as a duplicate of this bug. ***

Comment 17 Vojtech Trefny 2023-09-26 13:52:57 UTC
(In reply to Lukas Ruzicka from comment #15)
> b) With the above, I was seeing the behaviour in approximately 25 - 33% of
> interactions, otherwise it worked just fine.

I see similar random occurrence.

> d) I was always able to use the Esc key to cancel the operation and start
> over, but Lily is reporting that you cannot do it on bare metal. I cannot
> test this.

Not only Esc, the dialog is fully controllable with keyboard (so Tab to navigate and Enter to confirm), it's just mouse input that is ignored (and I still have no idea why).

Comment 18 lnie 2023-09-27 09:07:01 UTC

> a) The pop-up window never gets stuck when trying to format the most right partition in the Blivet-GUI overview. For example, when I have vda1 and vda2, this never happens when interacting with vda2, but it can  
> be triggered when interacting with vda1. However, when I add a vda3, I can trigger the behaviour on both vda1 and vda2 but not on vda3. See note 1.

As you can see from the screencast I'm gonna to attach,some times  formatting vda1 and vda2 are just fine,it gets stuck while formatting vda3.
I can't tell the last partition are more easily getting stuck or not,I've tried the first or second on most of my try.

I guess we need another reliable person to input here.The most reliable Kamil,would you please do us the favor?Thanks.

> b) With the above, I was seeing the behaviour in approximately 25 - 33% of interactions, otherwise it worked just fine.
> Note 1: When I see I cannot trigger the behaviour, I mean that I have tried 10 times without triggering that.

I guess the 10 times are triggered on the exactly the same VM,ie,you haven't reinstalled the system during that 10 times?
My fault,I should put more it clearly:this bug happens 100% only on the first attempt to reinstall the machine,you may or may not see this bug after you get the stuck and then reboot the system.

>c) This happens on VM with 2046 MB ram, as well as with 4096 ram, so I tend to believe that the problem does not depend on the size of available memory.

Mine is 8096 

>d) I was always able to use the Esc key to cancel the operation and start over, but Lily is reporting that you cannot do it on bare metal. I cannot test this.

I reboot the bare metal machine three times,without reinstalling, I see this bug all three times, the Esc work around works once after I tried  7 or 8 times ,and not works after I tried more than 10 times on the other two times.Calling some one who have a usable bare metal, Kamil?^^

> Not only Esc, the dialog is fully controllable with keyboard (so Tab to navigate and Enter to confirm), it's just mouse input that is ignored (and I still have no idea why).

I can confirmed this on VM,but I'm not able to check bare metal,as I'm on my 10 days long vacation,only bring one laptop,no USB stick.   


FYI,I've seen this bug more than 20 times,and as you can see from the comment14 screencast,the stuck is from a different reproducer  than the 100% reproducer I mentioned in description.

Comment 19 lnie 2023-09-27 09:08:17 UTC
Created attachment 1990784 [details]
screencast

Comment 20 Kamil Páral 2023-09-27 12:02:47 UTC
(In reply to lnie from comment #18)
> I guess we need another reliable person to input here.The most reliable
> Kamil,would you please do us the favor?Thanks.

Sorry, I'm swamped with other bugs at the moment. But I think the most important part is that Vojtěch can reproduce it now, so we don't really need super-exact numbers at this point.

Comment 21 Adam Williamson 2023-09-29 00:28:11 UTC
ohhh, this is sounding vaguely familiar now. I've seen a couple of bugs like this before, when mutter loses track of surfaces, basically. https://gitlab.gnome.org/GNOME/mutter/-/issues/2117 was one. https://gitlab.gnome.org/GNOME/mutter/-/issues/2918 was another.

I'll ask the GNOME devs to take a look and see if this looks like the same kinda thing.

Comment 22 Adam Williamson 2023-09-29 00:29:23 UTC
Carlos, Michael - does this look like a mutter issue similar to the above ones I linked? Thanks!

Comment 23 Michael Catanzaro 2023-09-29 14:07:28 UTC
I don't know.

Comment 24 lnie 2023-09-30 14:26:18 UTC
Here is the update from my side:

> I  confirmed this on VM,but I'm not able to check bare metal,as I'm on my 10 days long vacation,only bring one laptop,no USB stick.   

I bought a usb stick and checked,the keyboard is also fully controllable on bare metal.
Bad news is that I see this hang  6 times/6 trys  on  bare metal system(I tested on the *work* laptop I bring,so no reinstallation during that 6 times),together with the 3/3 on another machine I mentioned in #comment18 (also no installation during that 3 times),I think it's safe to say that this as 100% reproducible on bare metal system,at least on  bare metal systems installed using anaconda's guided/automatic partitioning.Though,it will be more safe if some guys who has available bare metal could confirm or disprove my conclusion. 

Regarding the ESC work around ,I try to reformat the first partition three times(out of that 6 tries),that work around works,however, on another three tries,while I'm trying  to format the second part,the work around doesn't work well,just as I mentioned in #Comment18.I also checked this on a guided installed vm, the work around also worked when I tried to format the second partition. 

 > With the above, I was seeing the behaviour in approximately 25 - 33% of interactions, otherwise it worked just fine

I checked this on one vm  containing only standard partitions, the number is 6/10,ie 60%

In conclusion,I still think we should consider this as a blocker,as it's 100% on bare metal system, and users may don't know there is a work around.

Comment 25 Kamil Páral 2023-10-02 14:49:26 UTC
On a typical vda1(biosboot)+vda2(boot,ext4)+vda3(root,btrfs) Fedora disk layout, I hit this very frequently on vda2. It's a race condition, but I'd say between 20-50% for me. Tested in a VM.

I also tested Fedora 37 and 38 Workstation and couldn't replicate it. This seems to be a new problem.

And finally I tested Fedora-KDE-Live-x86_64-39-20231002.n.0.iso and I can't replicate it there either. So this is likely a gnome-shell issue.

Quite interestingly, I also fail to replicate this when I try it from an installed GNOME system, just by running blivet-gui (but the Format dialog looks a bit different there, perhaps it's related).

Comment 26 Aoife Moloney 2023-10-02 17:18:20 UTC
Discussed during the 2023-10-02 blocker review meeting: [1]

The decision to classify this bug as a FreezeException (Final) was made:

"Agreed punt blocker (delay decision) AcceptedFreezeException (Final) - This does appear bad, but we can't reach a consensus. We're going to punt for now and perhaps have more testing done in the meantime. We do grant it FE status."

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2023-10-02/f39-blocker-review.2023-10-02-16.01.log.txt

Comment 27 Adam Williamson 2023-10-03 16:28:30 UTC
It's almost certainly mutter, not gnome-shell. It really seems like one of those surface issues I mentioned.

Comment 28 Brandon Nielsen 2023-10-04 20:41:32 UTC
Anything that brings up a modal can cause mouse input to stop working. I was able to reproduce this about 75% of the time just right clicking a partition and selecting "Information". This was on a bare metal system.

No matter what I did, pressing <Esc> always brought it back. So unless I'm missing something it is "workaroundable", though incredibly annoying.

Comment 29 Adam Williamson 2023-10-04 23:21:39 UTC
Can anyone say when this started? Do older F39 images show the same issue?

Comment 30 Adam Williamson 2023-10-05 00:44:52 UTC
Answering my own question: I can reproduce with Fedora-Workstation-Live-x86_64-Rawhide-20230714.n.0.iso (mutter-44.2-2.fc39), but not with Fedora-Workstation-Live-x86_64-Rawhide-20230602.n.0.iso (mutter-44.1-2.fc39). So it seems to have broken somewhere between those two.

Comment 31 Adam Williamson 2023-10-05 06:08:43 UTC
per #c26, adding FinalFreezeException to the blocks list so this actually counts as an accepted FE.

Comment 32 Adam Williamson 2023-10-05 20:29:37 UTC
I bisected this and identified the commit that causes it - see https://gitlab.gnome.org/GNOME/mutter/-/issues/3068#note_1861258 . At a push we can just revert that commit, as I'd say this bug is worse than the bug it fixed, but it'd be ideal to come up with something that fixes both.

Comment 33 Fedora Update System 2023-10-06 22:55:08 UTC
FEDORA-2023-fd2feee3b7 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-fd2feee3b7

Comment 34 Adam Williamson 2023-10-07 00:04:48 UTC
We have +6/-3 for blocker status in https://pagure.io/fedora-qa/blocker-review/issue/1342 , so this is upgraded to a blocker.

Comment 35 Fedora Update System 2023-10-07 02:33:37 UTC
FEDORA-2023-fd2feee3b7 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-fd2feee3b7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-fd2feee3b7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 36 lnie 2023-10-07 03:28:22 UTC
Checked on bare metal and VM: booted Fedora-Workstation-Live-x86_64-39-20230922.n.0.iso to runlevel 3, updated mutter,systemctl isolate graphical.target,ran the installer,play with blivet-gui for a while,
no stuck anymore.

Comment 37 Kamil Páral 2023-10-09 10:00:40 UTC
Thanks, Lili. I used the same steps and it also works just fine for me, no more stuck mouse input.

Comment 38 Lukas Ruzicka 2023-10-09 12:06:03 UTC
I am not sure if this is the correct place to mention it, but with the new fix from #2241761, I am seeing similar problem on dialogues when performing the
editing actions like format, set mountpoint, etc. The dialogues "freeze" occasionally when mouse input stops working and only keyboard can be used to perform the actions.

Comment 39 Lukas Ruzicka 2023-10-09 12:26:22 UTC
It works for me.

Comment 40 Fedora Update System 2023-10-09 22:26:46 UTC
FEDORA-2023-fd2feee3b7 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.