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
Created attachment 629257 [details] anaconda.log
Created attachment 629258 [details] ifcfg.log
Created attachment 629259 [details] packaging.log
Created attachment 629260 [details] program.log
Created attachment 629261 [details] storage.log
Created attachment 629262 [details] syslog
Created attachment 629263 [details] X.log
Created attachment 629282 [details] bug demonstration video Wow, this one seems 100% reproducible. Attaching video.
This could be a blocker material.
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.
This is still happening in anaconda 18.19, exactly the same reproducer.
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.
It's still broken in anaconda 18.28, exactly the same reproducer.
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.
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.
*** Bug 873306 has been marked as a duplicate of this bug. ***
Right. 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.
*** Bug 875991 has been marked as a duplicate of this bug. ***
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.
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.
+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).
*** Bug 881126 has been marked as a duplicate of this bug. ***
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
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
(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?
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.
I guess this bug never got attached to an update, but it's been fixes since the version up above.
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.
There's also bug 875291 and bug 882374.
Still, if this one is fixed, it's fixed. VERIFIED makes no sense, 18.36 has gone stable already.
(That's because I verified it with 18.37.2, see comment 28)
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...
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?
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).
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?
(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.