Bug 1118923

Created attachment 917457 [details]
storage.log from an affected run

Created attachment 917458 [details]
anaconda.log from an affected run

Created attachment 917459 [details]
journal output from an affected boot

Created attachment 917460 [details]
program.log from an affected run

packaging.log is empty.

dlehman thought the 'ntfsresize' process from program.log might be stuck, but 'ps' does not show it running, and re-running it manually doesn't get stuck - it very quickly responds "Minsize (in MB): 248"

dlehman further asked for 'updated logs', but nothing's changed. there's no indication the ntfsresize command failed or stuck, but for some reason, anaconda doesn't seem to have done anything after running it. there is nothing beyond that point in program.log even now, the VM has been running for nearly 8 hours at this point.

I tried this in a BIOS VM with a Window created NTFS volume, and can't reproduce with Fedora-Live-Workstation-x86_64-rawhide-20140703.iso which uses: anaconda-21.46-1, py-blivet0.60-1, ntfsprogs-2014.2.15-3

After Begin Installation, it resizes the NTFS volume, but crashes when creating ext4 on sda2, abrt filed bug 1120406.

Just to be clear: cmurf's attempt was not a true reproduction, he tried with BIOS. this may well be linked to UEFI boot somehow.

Yes, it was intentional to see if it's a UEFI specific thing. I just tried this with a UEFI VM, can't reproduce this bug here either with
Fedora-Live-Workstation-x86_64-rawhide-20140624.iso with a dnf upgrade to anaconda-21.48-1, python-blivet-0.61-1. It resizes the NTFS volume and installation succeeds.

The target drive NTFS volume is empty, however, because VirtualBox doesn't support UEFI installs of Windows; so I just created a faux target disk with three partitions: Microsoft Reserved, EFI System (FAT32), remainder as NTFS.

I can still reproduce this on the affected VM with a 2014-07-17 F21 boot.iso nightly, though I did get one successful boot (where hub got to its usual state, didn't stick at Probing storage...). I didn't proceed with that install, just rebooted to see if it would always succeed, but on a second boot, the bug happened.

storage.log does not get past "Running ... ntfsresize -m /dev/vda1", but there is definitely no running ntfsresize process according to ps. There's nothing particularly interesting in the journal.

Created attachment 918843 [details]
storage.log from a *BUGGY* 2014-07-17 f21 boot.iso run

Created attachment 918844 [details]
anaconda.log from a *BUGGY* 2014-07-17 f21 boot.iso run

Created attachment 918845 [details]
program.log from a *BUGGY* 2014-07-17 f21 boot.iso run

Created attachment 918846 [details]
journal from a *BUGGY* 2014-07-17 f21 boot.iso run

Created attachment 918849 [details]
storage.log from a *WORKING* 2014-07-17 f21 boot.iso run

Created attachment 918850 [details]
anaconda.log from a *WORKING* 2014-07-17 f21 boot.iso run

Created attachment 918851 [details]
program.log from a *WORKING* 2014-07-17 f21 boot.iso run

Created attachment 918852 [details]
journal from a *WORKING* 2014-07-17 f21 boot.iso run

I tried this with today's boot.iso also and still can't reproduce it in a vbox uefi VM; although it's a Windows 7 created GPT+NTFS disk. 

So I did a BIOS VM install of Win 8.1, and I still don't get a hang when installing on that either.

In a shall try strace ntfsresize -m /dev/vdaX before running the installer, it might reveal something is wrong before the actual program is even running and that's what's causing the hangup and why ntfsresize isn't listed. Some kind of race?

it runs fine when I run it manually after the bug occurs, and I did get that one successful run. I don't think ntfsresize per se is really the problem.

This seems to have gone away as of 'TC3' (an unofficial / unannounced / incomplete Alpha TC, generated 2014-08-24). I did three boots in a row and made it to target disk selection each time.