Bug 867770 - anaconda GUI becomes unresponsive
Summary: anaconda GUI becomes unresponsive
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 18
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Chris Lumens
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
: 873306 875991 881126 (view as bug list)
Depends On:
Blocks: F18Blocker, F18FinalBlocker
TreeView+ depends on / blocked
Reported: 2012-10-18 09:24 UTC by Kamil Páral
Modified: 2012-12-18 13:15 UTC (History)
13 users (show)

Fixed In Version: anaconda-18.31-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-12-13 21:37:04 UTC

Attachments (Terms of Use)
anaconda.log (4.49 KB, text/plain)
2012-10-18 09:25 UTC, Kamil Páral
no flags Details
ifcfg.log (641 bytes, text/plain)
2012-10-18 09:25 UTC, Kamil Páral
no flags Details
packaging.log (2.38 KB, text/plain)
2012-10-18 09:25 UTC, Kamil Páral
no flags Details
program.log (45.76 KB, text/plain)
2012-10-18 09:25 UTC, Kamil Páral
no flags Details
storage.log (144.21 KB, text/plain)
2012-10-18 09:25 UTC, Kamil Páral
no flags Details
syslog (67.40 KB, text/plain)
2012-10-18 09:25 UTC, Kamil Páral
no flags Details
X.log (56.18 KB, text/plain)
2012-10-18 09:25 UTC, Kamil Páral
no flags Details
bug demonstration video (1.34 MB, video/ogg)
2012-10-18 09:40 UTC, Kamil Páral
no flags Details
unresponsive screen (MANUAL PARTITIONING) (100.95 KB, image/png)
2012-12-18 03:49 UTC, Reartes Guillermo
no flags Details

System ID Priority Status Summary Last Updated
Red Hat Bugzilla 868903 None None None Never
Red Hat Bugzilla 875291 None None None Never
Red Hat Bugzilla 882374 None None None Never

Internal Links: 868903 875291 882374

Description Kamil Páral 2012-10-18 09:24:27 UTC
Description of problem:
I have seen this problem many times, but it's hard to reproduce. Sometimes Anaconda GUI becomes unresponsive, you can't click any button, nothing works. But Anaconda does not crash nor it is stuck in a loop. It is just unresponsive.

The last time I saw this, I did this workflow:

1. Click on Partitioning
2. Select Encrypt my system
3. Hit Continue
4. Hit Reclaim space
5. Mark all existing partitions to be deleted, hit Reclaim
6. Hit Continue (now you're back in the main hub)
7. Go to Partitioning again
8. Uncheck Encrypt my system
9. Hit Continue
10. freeze, can't click on anything

Sometimes the GUI unlocks after some time, sometimes it doesn't and it's locked forever. The mouse cursor still changes when I move it over different components (it's a hand icon when moving over the large disk icon), so it's not completely dead.

Version-Release number of selected component (if applicable):
anaconda 18.16
F18 Beta TC4 DVD 64bit

How reproducible:
very scarcely

Comment 1 Kamil Páral 2012-10-18 09:25:01 UTC
Created attachment 629257 [details]

Comment 2 Kamil Páral 2012-10-18 09:25:06 UTC
Created attachment 629258 [details]

Comment 3 Kamil Páral 2012-10-18 09:25:11 UTC
Created attachment 629259 [details]

Comment 4 Kamil Páral 2012-10-18 09:25:15 UTC
Created attachment 629260 [details]

Comment 5 Kamil Páral 2012-10-18 09:25:18 UTC
Created attachment 629261 [details]

Comment 6 Kamil Páral 2012-10-18 09:25:21 UTC
Created attachment 629262 [details]

Comment 7 Kamil Páral 2012-10-18 09:25:25 UTC
Created attachment 629263 [details]

Comment 8 Kamil Páral 2012-10-18 09:40:19 UTC
Created attachment 629282 [details]
bug demonstration video

Wow, this one seems 100% reproducible. Attaching video.

Comment 9 Kamil Páral 2012-10-18 09:42:08 UTC
This could be a blocker material.

Comment 10 Martin Sivák 2012-10-18 10:06:45 UTC
Can you retest with more current anaconda? (18.18) We did a big cleanup of GUI threads, locking and similar in 18.17 and fixed couple of small bugs related to it in 18.18.

Comment 11 Kamil Páral 2012-10-23 14:56:16 UTC
This is still happening in anaconda 18.19, exactly the same reproducer.

Comment 12 Chris Lumens 2012-10-23 15:14:35 UTC
I think this is the same as bug 868903, which I've got in post and should be pushing the fix for today.  You can either dupe it to that one, or just watch for anaconda-18.20-1 and verify the fix there.  Whichever you prefer.

Comment 13 Kamil Páral 2012-11-15 09:34:12 UTC
It's still broken in anaconda 18.28, exactly the same reproducer.

Comment 14 Kamil Páral 2012-11-15 09:35:54 UTC
I would like to know that I've hit this bug many times with many different configurations. The described reproducer is just the one that I've found to break it always.

Comment 15 Vratislav Podzimek 2012-11-15 13:03:21 UTC
Anaconda runs one of InstallOptionsXDialog from pyanaconda/ui/gui/spokes/storage.py but for some reason it doesn't get displayed and thus it seems like a hang.

Comment 16 Chris Lumens 2012-11-15 15:03:20 UTC
*** Bug 873306 has been marked as a duplicate of this bug. ***

Comment 17 Chris Lumens 2012-11-15 18:32:56 UTC

Here's some more data:

* If you don't run the reclaim dialog in a lightbox, it works fine the next time through.

* The second time through, you can hit the same problem by attempting to display the shopping cart.  I assume the problem would also appear if you could get an error in the info bar and pop up that dialog, too.

* If you pop up the reclaim dialog and hit Cancel instead of Reclaim, the problem does not occur.

* If you pop up the reclaim dialog and mess with the Action drop downs but hit Cancel instead of Reclaim, the problem does occur.

Comment 18 Chris Lumens 2012-11-19 15:31:01 UTC
*** Bug 875991 has been marked as a duplicate of this bug. ***

Comment 19 Chris Lumens 2012-11-19 21:22:14 UTC
It would appear that this may just be a problem with how dialogs are stacked up on each other.  If you hit the problem when displaying the cart dialog and you know that alt-C closes that dialog (or escape for that matter), you are dropped back into the spoke like you would expect.

Comment 20 Chris Lumens 2012-11-20 21:30:57 UTC
Reworked the resize dialog to avoid this problem, at least I hope.  I was able to reproduce this 100% by simply going to the resize dialog, fiddling with the drop downs, and then coming back to the storage spoke.  With my modifications, this is no longer the case.

Comment 21 Kamil Páral 2012-11-28 16:58:09 UTC
+1 blocker, it's very easy to trigger this and it is a showstopper, you have to reboot (if you don't know some clever tricks as Chris does).

Comment 22 Chris Lumens 2012-11-28 18:29:16 UTC
*** Bug 881126 has been marked as a duplicate of this bug. ***

Comment 23 Paul Wouters 2012-11-28 20:54:37 UTC
Similar issue, except I could only select partitions but not do anything with the selection. In the end, Xwindows was responsive but anaconda wasn't

Comment 24 Tim Flink 2012-11-30 17:50:40 UTC
It sounds to me like this is triggered if you re-enter the storage spoke after going through the resize process.

If I'm understanding correctly, then I'm +1 blocker

Comment 25 Tim Flink 2012-11-30 21:05:49 UTC
(In reply to comment #24)
> It sounds to me like this is triggered if you re-enter the storage spoke
> after going through the resize process.
> If I'm understanding correctly, then I'm +1 blocker

I just realized that there was no criteria violation cited here. While it doesn't hit any single release criteria, this could be considered a conditional violation of several criteria including:

"The installer's custom partitioning mode must be capable of the following: Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types ..."

"The installer must boot (if appropriate) and run on all primary architectures, with all system firmware types that are common on those architectures, from default live image, DVD, and boot.iso install media when written to an optical disc and when written to a USB stick with at least one of the officially supported methods"

Any thoughts on which criterion is more appropriate here?

Comment 26 Adam Williamson 2012-12-03 18:31:27 UTC
Discussed at 2012-12-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-12-03/f18final-blocker-review-1.2.2012-12-03-17.25.log.txt .

Accepted as a blocker: we decided to treat this pretty much as a crash in the installer, as that is its effect if you don't know the trick to un-stick it. Enough people have seen this that we consider it a conditional violation of "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above" (or really, any 'the installer must succeed' criterion) in the case where you do any of the things to trigger this bug.

Comment 27 Chris Lumens 2012-12-13 16:03:30 UTC
I guess this bug never got attached to an update, but it's been fixes since the version up above.

Comment 28 Kamil Páral 2012-12-13 16:50:52 UTC
I have tested with anaconda-18.37.2 and I wasn't able to reproduce this. I *think* I've seen this recently, but I have no idea how I caused it. I'll be sure to reopen this if I see it again. Setting as VERIFIED.

Comment 29 Chris Lumens 2012-12-13 16:52:23 UTC
There's also bug 875291 and bug 882374.

Comment 30 Adam Williamson 2012-12-13 21:37:04 UTC
Still, if this one is fixed, it's fixed. VERIFIED makes no sense, 18.36 has gone stable already.

Comment 31 Kamil Páral 2012-12-14 09:42:02 UTC
(That's because I verified it with 18.37.2, see comment 28)

Comment 32 Adam Williamson 2012-12-14 21:18:57 UTC
sure, but it seems silly to imagine that somehow it didn't get fixed when they tried to fix it, but then got accidentally fixed between 18.36 and 18.37.2...

Comment 33 Reartes Guillermo 2012-12-16 13:07:26 UTC
I am still experiencing these "unresponsive gui" issue with anaconda 18.37.2, at least in two places: INSTALLATION DESTINATION and MANUAL PARTITIONING.

Is the "unresponsive gui" issue fixed globally or a new bug-report is needed for the ones i am encountering?

Comment 34 Kamil Páral 2012-12-16 16:45:26 UTC
Reartes, if you still see the issue, please provide a detailed reproducer here and reopen this bug. Thank you.

Please note, however, that anaconda sometimes "lags" a bit, being unresponsive for 5-30 seconds, while e.g. fetching network metadata or mounting an NFS share. That is not this bug. This bug is about getting stuck permanently (but Esc sometimes help to bring the keyboard/mouse focus back to the application).

Comment 35 Reartes Guillermo 2012-12-18 03:49:06 UTC
Created attachment 665257 [details]
unresponsive screen (MANUAL PARTITIONING)

F18 TC3 (18.37.2)

happened in manual partitioning, when i clicked the "n Storage devices selected...".

Hit ESC once and 'Finish Partitioning' which led me to the main hub...

Should this bug-report be opened?

Comment 36 Kamil Páral 2012-12-18 13:15:59 UTC
(In reply to comment #35)
Reartes, I think this is probably a different bug. Please open a new bugzilla report against anaconda and attach /tmp/*.log. Thank you.

Note You need to log in before you can comment on or make changes to this bug.