From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 Description of problem: Bug #129528 seems to have been closed prematurely. Since I am unable to reopen that, I'm submitting a new bug. My situation is that I have a Thinkpad with FC2 installed. It also has an XP partition. The XP partition was moved up to start at cylinder 33 using PartitionMagic so that I would have room for /boot below it, and then shrunk to provide space for Linux above it. Initially, I booted successfully off of a burn of the FC3/disk1 CD, then popped it so that I could run an HTTP install. Loaded image2 successfully, clicked english/US in the obvious places, selected workstation install, got to partitioning. Chose "automatically partition" and "delete all linux partitions" and got the error reported above by Jens Peterson, plus some additional lines indicating that the failure was somewhere in the middle of trying to allocate a root partition. On the theory that this problem was somehow arising during partition delete and re-create, I booted the CD as a rescue disk and hand-deleted all of the existing linux partitions and tried again. Same problem. I tried this both with and without the "review partitions" button checked. From here down, you should assume that all of my FC2 partitions are gone. Unfortunately, this is all early enough in the GUI setup that kernel console isn't up yet, so I re-tried using the text-mode install (theory: get the partitions created and then I should be able to back out and restart the GUI install so I can see what happens later). No joy. Same bug message appears under text install when installing via HTTP. The gist is that the attempt to allocate a root partition failed under LVM. Okay. I've seen weird stuff under HTTP install before, so I tried doing the install from the local CD. Same error. Actually, that's kind of a relief since I'm counting on using HTTP install on some other machines. Okay. One last thing seems worth a try. Went back to rescue mode, left the eventual /boot partition in place but whacked the LVM (type 8e) partition. Try "keep partitions and use existing free space". Same error. Okay, so now I invoke disk druid by hand. At this point I see something really suspicious. Disk druid believes that cylinders 1-22 contain an EXT3 partition, but it *also* believes that those cylinders are free. This is definitely not promising, so I rebooted to delete all linux partitions by hand and tried once again to use Disk Druid by hand. At this point I gave up and decided to go with Disk Druid by hand. Problem: nobody has gotten around to updating the release notes link on the fedora website -- it still points to the FC2 release notes. A brief look at the release notes on the CD reveals that there are no recommendations for specific partition sizes in sight. Poked around with google and found something plausible in the way of partition sizes. Eventually decided that I should make /boot separate, give eveything else to a PV, allocate a swap and a / and rearrange things after installation. Okay, so now I see some VERY suspicious behavior in disk druid. DD sees the XP partition at cylinders 23-1647, bt it ALSO thinks that cylinders 1-9922 are free. I create a small partition, which happens to land before the XP partition, and now I see NewPartition:Free:XP:Free as expected. Delete this new partition and the expected Free:XP:Free appears. Now create LV of max allowable size and it looks like the cylinders are plausible. Then attempt to re-create /boot and give it all remaining space. DD won't use the low space, choosing instead to eat into the space previously given to the LVM PV. Delete that, select the front free space by hand, and used EDIT to create the /boot partition where it needed to be. It begins to smell to me like somebody may have "fixed" DiskDruid. Fdisk clearly doesn't have any problems figuring out the partitioning scheme. On the unlikely chance that it matters, note that because this system was rearranged with Partition Magic the partitions do not appear in the partition table in the same order that they are layed out on the disk. Not clear why/if this should matter, but there it is. Since this bug causes total install failure, I recommend that it should go to a severity high. Version-Release number of selected component (if applicable): Version on initial FC3 release CD 1 How reproducible: Always Steps to Reproduce: See details in description Actual Results: FC3 cannot be installed using automatic partitioning. Release notes insufficient to enable a confident hand-install because needed partition sizes are undocumented. Expected Results: FC3 should have installed -- or at least made it past the partitioning stage. :-) Additional info: I'm rating this high because inability to install amounts to loss of use of a machine once the prior release has been whacked.
I'm not certain whether I should open another bug report. I have a slightly different configuration: 1st partition 2 GB FAT32 W95 primary 2nd partition 8 GB EXT W95 Extended with . 1 GB FAT32 Logical . 7 GB FREE SPACE Selected "Delete all linux partitions" and "Use available free space" but "Automatic Partitioning" selection results in an error message which says that it cannot create a LVM volume and that there is no free space on the disk. I had to use Disk Druid to create the swap, boot, and / partitions in the free space. Why is there no option for non-LVM auto-partitioning? Shouldn't LVM work in an extended partition?
Kam's report sounds like a different bug. The bug I encountered very definitely has to do with failure to digest MD volumes correctly.
clumens fixed this in CVS last week