Bug 578553

Created attachment 403774 [details]
Attached traceback automatically from anaconda.

F13B rc2 dvd install on F13 VM.

This is a stretch in that I was experimenting with anaconda's raid and VG creation methods and chose to try in a VM.  I was trying to create 4 software raid partitions, then a raid 10 device, then a VG on the raid 10 device.  It seemed that the partitions were created, however, no matter the method, **within anaconda's partitioner**, I would get a traceback and in tty-2 parted showed only one or the 4 expected raid partitions on /dev/vda and an extended partition that was too small.  I got it to work by creating the partitions in tty-2 **before** anaconda looked for devices.  Then anaconda saw the partitions and nicely created the raid 10 device and then the VG and LV and installation was normal after that.

I do not know if F13 VM is at fault here or if anaconda is at fault or if I am at fault for pressing the software.

If I get a chance in the next couple of days, I will try the same initial approach outside of a VM and see what happens.

I would lower the severity to low since this is in no way a normal effort.

Created attachment 404235 [details]
Attached traceback automatically from anaconda.

(In reply to comment #3)
> Created an attachment (id=404235) [details]
> Attached traceback automatically from anaconda.    

F13-Beta-RC3
Fedora-13-Beta-x86_64-netinst.iso on a CDRW
anaconda 13.37.2 exception report

Created attachment 412109 [details]
Attached traceback automatically from anaconda.

Created attachment 412115 [details]
Attached traceback automatically from anaconda.

Created attachment 412162 [details]
Attached traceback automatically from anaconda.

Created attachment 412259 [details]
Attached traceback automatically from anaconda.

Any addition descriptions of preexisting layouts and steps taken would be useful in identifying the factors common among your various cases.

Here is a rough example of the kind of description that proves useful when trying to locate the critical factors: I started with two drives. Here's the output of parted -l: .... I chose custom layout, deleted sda3, created a new partition on sda of size XXX and growable with no upper limit. It ended up being sda3. Then I created another partition on sda of fixed size YYY. It ended up being sda5. Then I clicked on "Next", then clicked on "Activate storage" and got this traceback.

Too long ago to recall the exact steps, but, I did try to recreate the steps OUTSIDE of a VM and there were no problems.  This led me to believe the VM to be the problem.

Best I can remember:

Create a VM using a single large real partition and point to an .iso for the boot CD.
Choose custom parititioning and then create 4 partitions of type software raid, then create a raid 10 device from the 4 partitions and then create a PV from the raid 10 device and then create a single VG and then LVs.  

If I can, I will try this again and record the steps.  Otherwise, not sure it is worth pursuing.

Created attachment 423560 [details]
Attached traceback automatically from anaconda.

Created attachment 423561 [details]
Attached traceback automatically from anaconda.

Hi - this is quite close to bug 568219.

I have the same issue with anaconda 13.42/i386 

System (Dell XPS) has BIOS RAID, with three WIN partions (factory tools,
factory restore, win7). Any partitioning scheme (manual w/standard partions (no
lvm), lvm auto, lvm review fails, fails with "too many primary partions".

I did not find any workaround and basically gave up installation on that system.


I tried to prepartition the disk, telling anaconda to replace existing
partitions, which led to what follows (prob'ly a separete bug):

 Traceback (most recent call first):
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1070, in populate
    devstring = device.name
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1844, in getScreen
    self.populate(initial = 1)
  File "/usr/lib/anaconda/gui.py", line 1393, in setScreen
    new_screen = self.currentWindow.getScreen(anaconda)
  File "/usr/lib/anaconda/gui.py", line 1405, in setScreen
    return self.setScreen()
  File "/usr/lib/anaconda/gui.py", line 1314, in nextClicked
    self.setScreen ()
 AttributeError: 'NoneType' object has no attribute 'name'

(full traceback had separately been reported here:
[http://www.google.it/url?sa=t&source=web&cd=1&ved=0CBcQFjAA&url=http%3A%2F%2Fforums.fedoraforum.org%2Fattachment.php%3Fattachmentid%3D19742%26d%3D1277495147&ei=Fj08TIzkD47-OdvG5MQP&usg=AFQjCNESY6NU1mDaHd7ic2N9WNVFL4Pr3A&sig2=a9sl-DTePlck5vAxRunNXQ])

I think the 'PartitionException: Too many primary partitions.' are dupes of bug 568219. If you are still seeing it, please re-open that bug and attach the traceback.

I am also seeing 'PartitionException: Can't have overlapping partitions.' in logs from Steve, mohamed and none. Please open a new bug for these.

alien, the name problem is bug 584328, please attach your traceback under that bug number.

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

Created an attachment (id=438829)
Attached traceback automatically from anaconda.