Created attachment 1988973 [details]
journal

Created attachment 1988975 [details]
stuck-anaconda.log

Created attachment 1988988 [details]
storage.log

Created attachment 1989014 [details]
screencast

Created attachment 1989868 [details]
bare metal storage.log

Created attachment 1989869 [details]
bare metal anaconda.log

Created attachment 1989870 [details]
journal from bare metal

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

> is 

is also

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

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

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.

Created attachment 1990548 [details]
screencast

Created attachment 1990549 [details]
screencast with pointer shown

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.

*** Bug 2239756 has been marked as a duplicate of this bug. ***

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

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

Created attachment 1990784 [details]
screencast

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

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.

Carlos, Michael - does this look like a mutter issue similar to the above ones I linked? Thanks!

I don't know.

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.

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

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

It's almost certainly mutter, not gnome-shell. It really seems like one of those surface issues I mentioned.

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.

Can anyone say when this started? Do older F39 images show the same issue?

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.

per #c26, adding FinalFreezeException to the blocks list so this actually counts as an accepted FE.

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.

FEDORA-2023-fd2feee3b7 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-fd2feee3b7

We have +6/-3 for blocker status in https://pagure.io/fedora-qa/blocker-review/issue/1342 , so this is upgraded to a blocker.

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.

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.

Thanks, Lili. I used the same steps and it also works just fine for me, no more stuck mouse input.

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.

It works for me.

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.