Tao, it seems to be an important bug, even though I haven't reproduced it. Can you please mark it as a blocker next time? Also, please attach all the logs.

Ondrej Hudlicky just confirmed to me that he sees the same problem using 3GB virtio disk, KVM on RHEL6, tested both architectures. He tested all ways to how to partition a disk - manual and automatic.

Discussed at 2012-09-05 blocker review meeting. We agreed we needed more details of the conditions needed to reproduce this bug. akshayvyas and ondrej both say they've seen it; discussion hinted this may be related to 1) small disk sizes, 2) dynamic allocation of virtual disks, or possibly both combined. Tao, Ondrej, please provide more specific details about the configuration of your VMs, and logs from the installer if possible. thanks!

There are two ideas what could be wrong:
1. too small disk - please try with a larger one
2. virt disk that uses dynamic allocation - please try to use a statically allocated one

I created a very small disk and I received this error: bug 854856

I created a dynamically allocated disk and everything worked fine.

-1 Blocker +1 NTH

Can't really vote definitively on this one till we have more data from twu, but I'm leaning -1 blocker as no-one else seems to be hitting this yet.

Created attachment 611341 [details]
anaconda log

Created attachment 611342 [details]
program log

Created attachment 611343 [details]
error checking

Tao: we also need storage.log - that's the most important one, in fact.

Discussed again at 2012-09-10 QA meeting acting as a blocker review meeting. Unfortunately storage.log is missing so we still cannot properly evaluate the bug yet.

Created attachment 612000 [details]
storage log

According to anaconda.log you haven't created a / or boot partition:

03:59:36,569 ERR anaconda: You have not defined a root partition (/), which is required for installation of Fedora to continue.
03:59:36,572 ERR anaconda: You have not created a bootable partition.


I think this error would show up if you enter the spoke and click on the info bar at the bottom. When you create the partitions you should hit continue, not back. This may be a bit confusing and could possibly use some work to make it clearer, but I don't think it is blocker worthy.

Discussed at 2012-09-12 blocker review meeting. Rejected as a blocker: there's no actual failure here, really, twu just got confused by the custom partitioning interface. (Which is pretty confusing, in some ways.) If he went into the partition spoke again and jumped through the right hoops, it would proceed fine.

We can turn this report into a bug about the confusion in the partitioning spoke, or we can just close it and open a new one for that, whatever the team prefers.

I see this in 18 Beta TC6 when doing a minimal install from either the i386 or x86_64 DVD. It only happens when using an already initialized disk (reusing an existing test VM). If I blow away the VM and create a new one with an uninitialized disk, it works. I will attach storage.log from a failed Fedora-18-Beta-TC6-x86_64-DVD.iso minimal install (disk already initialized and contains a successful minimal install from before).

Created attachment 630838 [details]
/tmp/storage.log from a failed Fedora-18-Beta-TC6-x86_64-DVD.iso minimal install (disk already initialized)

Should add that I was using a dynamically allocated 30 GB disk, VirtualBox 4.2.2 guests.

I learned from kparal on IRC the extremely confusing procedure that one is now expected to use to reinstall over an existing system. In earlier versions one was told explicitly that there was an existing install and offered the choice of overwriting it.

<robatino> kparal: what was your procedure for reclaiming all partitions? i tried to do it manually but it doesn't allow me. in F17 it happened automatically
<kparal> robatino: partitioning dialog -> Continue -> Reclaim -> mark all as Delete -> Reclaim -> Continue

<robatino> kparal: thanks, it wasn't obvious how to change "preserve" to "delete" (or why the error was happening in the first place. in earlier versions it told you explicitly there was an existing install and offered to overwrite it)
<kparal> robatino: I know, the dialog to reclaim space is really bad. I just don't have the nerves to report usability problems to anaconda over and over again
<kparal> robatino: if you feel like it, please report a bug about that dialog, it's really hard to realize how to change Preserve to Delete
<robatino> i'll just make a note of it in the bug report i reported the initial failure in

they know that dialog isn't optimal but there are technical obstacles to improving it (working with glade is apparently not super easy).

I'm running into the same problem with Anaconda locking up when attempting to reclaim a disk that has an existing linux partition.

I am limited to a VNC installation because I can not get any GUI-based F18-beta installation media to boot on a new UEFI system (lots of open bugs on that).  I have been told to install by VNC.

When running a VNC installation, everything works fine until I get to the menu selection for configuring the installation destination.  Anaconda properly recognizes my existing drive as a WD800JD 80 GB SATA drive that already has a linux installation on it and an insignificant amount of unallocated space.  I click on the "continue" button to go to partitioning options, and all of the partitions are displayed properly.  I can click on each partition, and change their status from "preserve" to "reclaim."  When accepting these changes the system hangs.  It issues the error message: "Error checking storage configuration. Click for details."  Unfortunately the VNC terminal is frozen and nothing can be done about it.

FYI I am using the current Fedora-18-Beta-x86_64-netinst.iso burned to a CD-ROM. The date on the ISO file is 20-Nov-2012.

just a clarification -- in case my previous comment was unclear, it's the system that's running anaconda that hangs, not the system running the VNC clinet.  the VNC client works fine. if I close the client and reopen a new VNC connection, the new VNC connection is made with the hung-up version of anaconda.

Workaround: Because Anaconda would hang whenever it encountered my hard disk that was already populated with an existing linux system, I used the GPartEd 14.0-1 Boot CD to manually delete the existing partitions from the hard disk before running the Fedora Install.  

On repeating the attempt for the Fedora netinstall, Anaconda correctly recognized that the disk was blank and had sufficient space to perform the installation.  When proceeding to the "continue" selection, however, Anaconda subsequently reported that the disk was full and that there was no space left on the device.  It seems that anaconda was having second thoughts about recognizing that the drive partitions had been deleted by GPartEd.  I had to re-boot the netinstall CD several times before Anaconda finally recognized that the disk was indeed empty and allowed me to manually partition the disk.  Anaconda seems to have trouble recognizing that the partitions had been deleted.  It appears that anaconda is using two different criteria to determine if there is space on the disk; the results provided by the first criterion and the second criterion are inconsistent.

We have multiple other bug reports tracking the issue where free space calculations aren't quite right (due to including/excluding swap from the figures).  In general, this bug report is really starting to ramble, including such things as the problem with the widgets on the reclaim dialog.  I'm going to close this bug report, but if you are seeing a problem with the Beta or later tree, please do open a new report with a single issue and we'll work on that.  Thanks.