Created attachment 642019 [details]
storage.log

Created attachment 642020 [details]
storage.state

Created attachment 642021 [details]
syslog

Created attachment 642023 [details]
X.log

Do you remember if you went into the reclaim dialog at all?  That's the one with the preserve/resize/delete options.

No, I believe I stayed away from Reclaim.  In fact, I don't recall seeing any preserve/resize/delete options during any of my installs of F18-pre so far (which may be something like 7 or 8 of them.)  Anyway, I've downloaded an official beta-TC8 so that I can try that.

I have reproduced the problem using official beta-TC8 full install .iso on UEFI USB2.0 flash memory device written by livecd-iso-to-disk.

Configure network.
Get into Custom partitioning (Standard partition [not btrfs, not LVM], "I will review").  Re-use existing EFI System Partition from Windows (102MB fat32) as /boot/efi.  Create new 500MiB /boot (label LinuxBoot), 15GiB / (root; label f18e64), 4GiB swap. Do not click Finish.  Instead, click buttons in upper left corners to go Back two screens to main hub; then go forward to Custom partitioning again.  Apparently nothing has been remembered, so start to re-enter.  Re-use existing EFI System Partition from Windows (102MB fat32) as /boot/efi.  Click '+" button near lower left (row of "+", "-", screwdriver/wrench) to start the creation of /boot.  BANG!  Focus is lost; there is no further response to clicks or typing.  Pointer tracks mouse; console switching works; running /usr/bin/top from shell on VT2 reveals that machine is idle.

In the time that it took to enter comment 7 above using a different system [say, 10 minutes] the install froze completely: console switching no longer works, etc.  Hardware reset was required, so I could not gather files from /tmp.

Starting over, again upon second entry to custom partitioning (where all entries of first time have disappeared), I re-use the 102MB fat32 partition from Unknown [existing Windows installation] as ESP, then expand the "New Fedora 18-Beta-TC8 Installation", then click the "+" button, and this time it does not lose focus.  So the key seems to be clicking "+" while "Unknown" [existing Windows installation] is expanded and "New Fedora ..." is collapsed.

Starting over (3rd attempt. again re-enter Custom partitioning with first batch of entries disppeared), I verify that focus is lost when "+" is clicked while "Unknown" is expanded and "New Fedora ..." is collapsed.

Going to VT2 and running "strace -p <pid>" on the anaconda process which "ps ax | grep anac" shows has the most CPU time (12 seconds), I see the process spinning in a tight two-step loop: {recvfrom==>EAGAIN, poll==>timeout}  Of course this may be caused by the graphics display being not visible.  Switching to VT6 momentarily and trying some mouse movement and clicks [sill no visible response], then switching back to VT2, I glimpse some strace output that is _not_ the two-step recvfrom+poll, but it scrolls off before I can type <ctrl>S.  But the system hasn't frozen [yet?], so I'll attach some log files.

Created attachment 644405 [details]
/tmp/anaconda.log

Using official Beta-TC18 full install from USB2.0 via livecd-iso-to-disk.

Created attachment 644406 [details]
storage.log

Created attachment 644407 [details]
storage.state

Created attachment 644408 [details]
syslog

Created attachment 644409 [details]
X.log

There's a couple things going on here:

(1) There is very much a resize-related hang, which unfortunately you do not appear to be hitting.  That should be fixed post-beta.

(2) There also appears to be something happening where dep solving does some long-lived task in the main thread which causes the UI to hang for a minute or two.  This could make it look like various unrelated things you do cause the UI to hang, since it's just going to happen whenever the software thread gets around to it.  Have you waited around a little bit to see if the UI ever comes back to life, or is it just hung up permanently?  If the latter, does hitting escape bring the UI back?

I have been seeing something similar in a VM:
Bug 880912 - installer may hang in Manual Partitioning

The installer will write a composite log file with a traceback, if you send it SIGUSR2:
# pkill -USR2 -o anaconda

The logs are /tmp/anaconda-tb-*

(The installer seems to dump two. If anaconda-tb-all.log is larger, I attach it.)

For testing, I have been waiting for the Software Selection spoke to finish "Checking software dependencies..." before clicking on Installation Destination. The log file attached to Bug 880912 seems to show that dependency checking was completed well before the hang.

Created attachment 653756 [details]
anaconda-tb-all.log

Still same problem with anaconda-18.29.2.  I waited at the main hub until Software Selection removed its warning triangle, then began custom partitioning.  After triggering the apparent loss of focus for keyboard and mouse [re-use existing EFI System Partition as /boot/efi; create new /boot, new root, new swap;  go Back two screens to main hub; go Forward two screens to partitioning, re-enter /boot/efi, expand "New Fedora 18-Beta installation", click on '+' to add new partition; focus is now lost] then I waited a measured 5 minutes (300 seconds) but still clicking/typing on the graphics screen was ignored.

/usr/bin/top showed 99.8% idle.  "ps ax | grep anac" showed everything in state Ss, Ssl+, Ss+, Sl+, or S+.  Then I did "pkill -USR1 -o anaconda" and gathered the log files.

Created attachment 653763 [details]
anaconda-tb-XXXXX

Created attachment 653765 [details]
anaconda.log

Created attachment 653766 [details]
storage.log

Created attachment 653767 [details]
storage.state

Created attachment 653768 [details]
syslog

Created attachment 653770 [details]
X.log

(In reply to comment #16)
> "pkill -USR1 -o anaconda" and

Typo: I used USR2, not USR1.

It's now 15 minutes later, and focus still appears to be lost.  However, typing <ESC> brings some life!  Clicking the '+' button draws its down-then-up animation, but typing still is ignored.  Clicking on '+' again is ignored.  So it's back to catatonia.  (The pointer still tracks the mouse.)

Yeah I just discovered the escape thing too.  What this tells me is this is the same as a problem I saw elsewhere:  Something's going on with certain lightboxed dialogs that causes them to be displayed under the rest of the UI but still grab all the input.  In this case, it's the mountpoint dialog.  Working on figuring out what the minimal reproducer is right now.

This does it every time for me:

(1) Start with a VM with two disks with stuff already installed on them.
(2) Select both disks, go into custom partitioning.  I don't change the default of LVM.
(3) Delete everything.
(4) Create /boot, swap, / as a layout that doesn't have any errors.
(5) Go Back to destination selection, then Done to return to the hub.
(6) Go right back into custom partitioning, again not changing the default.
(7) Click the add button.

If I create everything in step #4 by clicking on the autopart button on the LHS instead of creating them all myself, I avoid the problem.  I assume this is because I've not popped up the lightboxed Add Mountpoint dialog a first time.

Changing from the default of LVM does not avoid the problem.  I expected as much, but I just wanted to be sure.

Also similarly to what I have seen in the past, step #7 could also be:  Click the delete button.  That hits the problem too.  Or, you can hit the configure button or the shopping cart button.  Any lightbox dialog in step #7 lands you at this bug.

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

Note that I am extremely pessimistic on the chances of being able to come up with a fix for F18.

I have an idea for a workaround, though.  If this is only happening because of certain lightboxed dialogs, perhaps I can just remove the lightbox and add window decorations.  It might not be the prettiest, but it'd be better than this.

Check out updates=http://clumens.fedorapeople.org/875291.img which is against the latest F18 anaconda git and let me know if you are still seeing problems.  Like I previously said, it's not the prettiest.

(In reply to comment #30)
> Check out updates=http://clumens.fedorapeople.org/875291.img which is
> against the latest F18 anaconda git

That's not much useful, unless we want to build the package and create a new compose manually. Can it be used together with anaconda 18.37.10?

Yes, the only difference between 18.37.10 and git head is a fix for bug 891487.  Of course, you could have just tried it as well.

Sure, but in case the issue is not fixed, I wouldn't know whether the reason is in non-matching updates.img or not.

However, it seems to be fixed. I can no longer reproduce with the updates.img.

(In reply to comment #30)
>   updates=http://clumens.fedorapeople.org/875291.img

That succeeds with anaconda-18.37.10.  Instead of the former "hang" due to loss of focus, now I see the small centered dialog box to create a new partition, and I can enter the mount point and size, activate, and go on to the next new partition.  Package installation is proceeding (on a separate test box) as I type this comment.

It's probably worth checking whether other dialogs on that spoke cause the same behavior.  I did some cursory checking and didn't hit it, but that doesn't mean I tried all possibilities.

Discussed at 2013-01-07 QA meeting acting as a blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting/2013-01-07/fedora-qa.2013-01-07-16.01.log.txt . Agreed that this is an annoying problem and fairly easy to hit, but it doesn't quite meet any of the criteria and is workaroundable (either by figuring out to hit Esc, or just rebooting and trying again) - nothing irreversible has happened when you can encounter this bug. It is accepted as NTH, though, and we would like to take the 'fix' (more of a code workaround). If people could test the fix and make sure it doesn't break anything else, that would help a lot.

anaconda-18.37.11-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.37.11-1.fc18

Confirmed that this is fixed.

This is fixed with Add partition button in anaconda-18.37.11, but I can still hit the issue with Remove partition button and Configure mountpoint button (tools icon).

Can you please describe your exact procedure?

Created attachment 674893 [details]
reproducer

I think it's a bit random, but if you play with it a bit, you'll see it. See video.

I can go through and remove the lightboxes from the other dialogs in custom storage pretty easily, if we want to incorporate that into F18.

if we have to do another build, maybe worth pulling it in. but right now we're still okay with rc2.

anaconda-18.37.11-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Reopening, Bodhi closed this automatically.

Sending out a more thorough patch for master.

I just encountered this problem with F18 GA with the "remove partition" button. I wonder if the "ESC" workaround is described anywhere (except in this bug)?

Created attachment 694010 [details]
"delete partition" dialog popping up in the wrong place

After this just happened to me with F18 GA, I used the ESC key to quit the background dialog. That unlocked the GUI so I could continue installing.

However the dialog I had quitted showed up in places afterwards where it definitely didn't belong - here in the main installation screen.

Created attachment 694011 [details]
delete partition dialog in wrong place, 2nd example

Please don't reopen this bug.  Bug 875291 fixed after F18 tracks the rest.

Ugh, by which I mean, the Fixed In Version field here shows that this was fixed post-F18.

(In reply to comment #47)
> I wonder if the "ESC" workaround is described anywhere (except in this bug)?

RTFM.  It's in the "Common bugs":
http://fedoraproject.org/wiki/Common_F18_bugs#Installer_can_become_apparently_.27stuck.27_in_custom_partitioning_mode_due_to_window_focus_problems

I apologize for having missed the Common Bugs entry and the Fixed In Version field. Having never done this so far, I suppose the only way to retest this is the daily Live image?

The daily live image probably is the most accessible, as long as it has anaconda-19.0 or later.  (The version is announced on console in VGA text just before going to graphics mode.  Also see /tmp/*.log at any time via <Ctrl><Alt><F2>.)  Other methods include building your own install .iso using pungi with updated packages (I do this), or making an anaconda Updates image then boot with "updates=http://..."

(In reply to comment #52)
> RTFM.
John, please avoid using this phrase next time, it is inconsiderate, thank you.

Martin, the easiest way to retest this would be to wait for Fedora 19 Test Compose 1 images, which should appear in a month or so. As John says, the nightly composes [1] are available as well, but they might be pretty broken in many other ways (or they might often fail to build completely).

[1] http://alt.fedoraproject.org/pub/alt/nightly-composes/

I tried with updates.img (commit cc473bc3) but it fails with ImportError for "blivet.devicelibs".

Fedora-19-Nightly-20130205.17-x86_64-Live-desktop.iso doesn't start on my system either (frame buffer problems). I'll come back to this later.