Created attachment 963451 [details]
/tmp/program.log

Created attachment 963452 [details]
/tmp/storage.log

What results do you get for:
# parted /dev/sda u s p
# blkid
I'd like to try to reproduce this in a VM; inferring this from storage.log is confusing. I'm seeing sda1, sda5, sda6, are NTFS which is an unusual layout.

It may be useful to see the full journal at the time the hang happens:
# journalctl -b -l -o short-monotonic > /tmp/journalh.log  ##I'm adding h just because I'm too lazy to find out if the installer already writes out a journal.log or .txt file or if it only does that at the end of the install. Please attach it as a file rather than pasting the whole thing.

It's probably too much information, but it might be worth a sysrq-t before you run journalctl. This will show all tasks, dumped to kernel messages buffer which journald will then pick up. Maybe someone else has a better idea about how to get more info what's hung up.

While you're at it, if you could test with RC4 instead, it's 6 days newer.

And instead of sysrq-t, how about a plain old 'ps aux' output saved as a file and attached. Maybe it'll show a dead process we can then get more information on.

(In reply to Chris Murphy from comment #4)
> While you're at it, if you could test with RC4 instead, it's 6 days newer.
Sorry, I meant RC2. Anyway, more importantly I'd like to see the info from parted so I can reproduce the layout and see if something about that is the trigger.

Created attachment 963944 [details]
Output of parted and blkid

I tried again with RC2 and had the same result. I also tried after removing sda3 and sda6 (the FAT32 "hidden" EFI partition, which I'm not sure what it is used for, and the "hidden" recovery partition).

Weird, two partitions named EFI system partition. The Windows install media is not Microsoft original, I'm guessing it's media that comes with the computer and its a one shot restore (no options) that configures it this way? What do you get for

# sgdisk -i3 /dev/sda

I'm curious what the "partition GUID code" (same as UEFI spec 'PartitionTypeGUID'), and attribute flags are set to.

This is the OEM partitioning layout for the Lenovo Z40 that I recently purchased. It is re-created this way whenever I restore the disk using the USB recovery media created from the initial installation. Lenovo is also very stingy about recovery media (they refuse to send me a disk unless I purchase a full retail copy; at least Dell would include one for a nominal $10 fee), so I'm reliant on the USB recovery media I created to test with.

I can run the sgdisk command later today, to verify, but I can tell you that I remember that the GUID was definitely different between those two partitions labeled "EFI System Partition", so only one was really an EFI partition. Plus, I also got the same behavior in anaconda after deleting the second one. So, despite that strange appearance of two EFI partitions, I don't think it was the root cause of the issue.

Even without exactly reproducing the partitiontypeGUIDS for partitions 3 and 4 (even without installing Windows as I don't have this Windows restore media), I've reproduced this bug in a VBox UEFI VM. It doesn't appear to be the dosfsck hang problem either.

Here is ps aux: http://ur1.ca/iyzj0
top reports anaconda alone is using 100%CPU
The GUI is unresponsive. I'm not sure how to get more information; the program.log ends at 24m34s past the hour, it's now 33m00s past the hour so nothing is in the log since the moment the hang started.

This is a really unremarkable layout, probably more common for OEM Windows installs to look like this than Microsoft produced install media (which only creates three partition installations).

Proposed as a Blocker for 21-final by Fedora user chrismurphy using the blocker tracking app because:

 "The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora."

I don't even have Windows installed, I'm just emulating the layout the original reporter gets when doing a clean restore of Windows to his system. The installer is hanging seemingly due to a particular partition layout.

Created attachment 964355 [details]
screenshot of hang

Created attachment 964356 [details]
anaconda.log

Created attachment 964357 [details]
program.log

Created attachment 964358 [details]
storage.log

Created attachment 964359 [details]
storage.state

Created attachment 964360 [details]
journal

journalctl -b -l -o short-monotonic

I think this is a python-blivet bug, that's where the storage.log ends, executing action creating partition 7, which actually needs to go in between partitions 5 and 6 since that's where the free space is (completely legal in the UEFI spec to have non-contiguously numbered partitions). When I delete partition 6, the bug isn't reproducible.

"The installer is hanging seemingly due to a particular partition layout."

Well then what we're dealing with doesn't seem to be a problem in Windows dual boot. It's a problem with a particular partition layout.

The criterion would be "The installer must be able to create and install to any workable partition layout using any file system and/or container format combination offered in a default installer configuration." - https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Disk_layouts - which is extremely subject to fudge, especially for bugs discovered very late in the release. I suspect the general opinion is going to be -1 blocker at this point.

Bug does not occur with this combination:
anaconda-21.48.21-1.fc21.x86_64
python-blivet-0.61.13-1.fc21.noarch
pyparted-3.9.5-2.fc21.x86_64

This is quite likely a dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1170153 .

Yeah, it really is.

*** This bug has been marked as a duplicate of bug 1170153 ***

(In reply to Chris Murphy from comment #19)
> I think this is a python-blivet bug, that's where the storage.log ends,
> executing action creating partition 7, which actually needs to go in between
> partitions 5 and 6 since that's where the free space is (completely legal in
> the UEFI spec to have non-contiguously numbered partitions). When I delete
> partition 6, the bug isn't reproducible.

I can also confirm that deleting the last partition on the disk works. However, I found this to be the case *only* if there were no other unallocated areas between the other partitions. In other words, deleting partition 6 works, but deleting both partitions 3 and 6, and trying to install after partition 5, does not work.

Christopher: it should be resolved in RC5. Please grab it and check, if you have the time. thanks!

(In reply to Adam Williamson (Red Hat) from comment #25)
> Christopher: it should be resolved in RC5. Please grab it and check, if you
> have the time. thanks!

RC5 works just fine.