Red Hat Bugzilla – Bug 864128
f18b tc anaconda gets stuck after deleting a preexisting partition in the 'unknown tree' after coming from a previous mistake or error
Last modified: 2012-11-22 22:27:12 EST
Created attachment 623542 [details]
anaconda stuck final screen
Description of problem:
I got anaconda stuck (not frozen). See below for explanation.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1- Enter storage: installation destination.
2- Select one disk (in this case, the first one, the 9.5gb), press continue.
3- 'Installation options' offers to reclaim space, 'i don't need help [...]'
and press 'reclaim space'
4- Select tree 'Fedora Linux 18 for x86_64' and delete the big 5.48gb (Ex /) partition.
5- Press the add partition button '+'
6- Select mount-point '/' and size, well let's be safe and select 5.3gb
(less than free space). And then add mount point.
7- Press Finish, anaconda will say 'Error checking storage configuration,
enter storage: 'Installation destination' again.
8- Double-click the yellow error banner. It will read: "not enough
free space on disks for automatic partitioning", hit 'cancel'
(damn this QUIT button... i hit it some times by mistake) then
leave as is, with the very same disk selected and hit continue.
*9 Select 'I don't need help [...]' again.
*10 delete a partition in the 'unknown tree' (ex / boot in this case)
ANACONDA GETS STUCK, it is not frozen, ans the mouse cursor changes
whenever one hoovers the 'removed but still showing' partition. For
example Alt+tab works, but no other object is clickable.
Created attachment 623543 [details]
Created attachment 623544 [details]
program log stuck anaconda
Created attachment 623545 [details]
storage log stuck anaconda
Created attachment 623546 [details]
X.log stuck anaconda
Created attachment 623547 [details]
syslog file, stuck anaconda
Created attachment 623879 [details]
I see something similar using anaconda-18.14 (self-built netinst.iso booted from physical DVD on bare hardware).
In custom partitioning, eventually there is no response after a button click, except possibly the down+up animation to confirm the click. I wait 60 seconds, and nothing happens. The pointer does track the mouse, the keyboard appears dead except that <Ctrl><Alt>F2 does go to the shell on VT2, where the keyboard works.
It seems like the installer has become "deaf" to Button1 clicks, or is waiting forever for something to be drawn. /usr/bin/top shows an almost-idle machine; nothing is using much CPU time at all.
Once the deafness happened when going Back after creating boot+root+swap partitions on a drive with GPT but no partitions ('+', select mount point and size, customize with label, ...) then deleting each partition using the '-' button, then going Back. But the next time I could repeat that cycle (create some partitions, delete them [all without Applying], and go Back without losing contact, and repeating that cycle a couple times, but eventually I get no further response.
nVidia 6500 (will attach Xlog.)
Created attachment 623880 [details]
Created attachment 623894 [details]
Created attachment 623895 [details]
Reartes - I am definitely not seeing that following the same steps with 18.14.
John - I wonder if there's a modal dialog popped up underneath the anaconda window that is listening for events, but because it's underneath you can't see it. alt-tab should still work to show you what windows are present, even if you can't switch windows. If you do so, do you see multiple options?
This appears to be fixed in the latest TC. Please test.
Discussed at 2012-10-11 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-11/f18beta-blocker-review-3.1.2012-10-11-16.04.log.txt . Agreed that, so far, this seems to require extensive fiddling in the 'custom partitioning' screen to reproduce, which makes it not a Beta blocker under either the current or proposed revised partitioning criteria for Beta (which really just cover straightforward 'empty out the disk, create some partitions, continue'). Accordingly it's rejected as a Beta blocker. It can be re-proposed if a more simple and direct reproducer is found.
We've got a set of threading-related patches going into the next build. Please test again with a tree containing anaconda-18.17-1 and let us know if it works better for you. Thanks.
Beta TC5 will have anaconda 18.17, so you can use that for testing when it comes.
Created attachment 630486 [details]
snapshot F18b TC5
It still happens, when anaconda becomes stuck, press ESC key. The partition is then removed from the list. Some dialog that should be modal is behaving in an inmodal way :-)
So Chris comment #10 was right.
In this case, ESC does not return the UI to an usable state. The UI works
partially and very erratic. ESC makes it working for a short time, because anaconda seems to stockpile windows in the background, see screenshot.
Anaconda can be partially 'repaired' by pressing ESC after being 'stuck'.
Only a reboot will truly recover it.
It seems the issue is triggered when you JUST 'touch' the partitions in manual partitioning, then returning to the main hub and trying to modify the partitions.
When you return to manual partitioning anaconda can get stuck very easily
in both STORAGE: INSTALLATION DESTINATION and in MANUAL PARTITIONING.
Nearly everything causes it to get stuck.
I think the issue is general enough to have duplicates. Every anaconda 'stuck' in any STORAGE screen must be checked against previous paragraphs.
Ah, the key here appears to be the reclaim dialog. We discovered this in bug 868903, and it looks like it's causing a problem here too. I've mailed out a patch and should be pushing it shortly. Related, when you press the escape button we are just not deleting that dialog correctly.
Can you test with updates=http://clumens.fedorapeople.org/escape.img? This image will not do anything to the freezing, but ought to at least properly destroy the deletion confirmation dialog. Thanks.
This bug looks to have been fixed for many anaconda builds now but missed being closed. If you find you are still experiencing it with Fedora 18 Beta (RC1) or later, please re-open the bug.
(per comment #17 and history it is believed to be finally fixed since 18.20)