Created attachment 474790 [details]
The bug report
Description of problem:
Exception on manual disk partitioning
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start installation on a harddisk, that has already three NTFS disk partitions and sufficient free space to install fedora
3. In the custom disk partitioning screen create a boot partition, root partition and swap partition, but don't select "force to be a primary partition"
4. select the boot partition again and select "edit".
5. On the partition editing screen now select "force to be a primary partition"
6. See the exception occur.
Exception makes the installation abort
Anaconda should show a screen saying that creating a primary partition is not possible and continue installation process.
dupe of bug 627153?
No it is not about modfying NTFS partitions.
The NTFS partitions in this case are there to fill up the partition table so that there is no space anymore to create a primary partition after I had created all the linux partitions to be extended partitions.
anaconda 14.22 exception report
Traceback (most recent call first):
File "/usr/lib/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 2149, in devices
raise DeviceTreeError("duplicate paths in device tree")
File "/usr/lib/python2.7/site-packages/pyanaconda/storage/__init__.py", line 449, in partitioned
for device in self.devicetree.devices:
File "/usr/lib/python2.7/site-packages/pyanaconda/storage/partitioning.py", line 823, in doPartitioning
disks = storage.partitioned
File "/usr/lib/python2.7/site-packages/pyanaconda/iw/partition_gui.py", line 1582, in refresh
File "/usr/lib/python2.7/site-packages/pyanaconda/iw/partition_gui.py", line 1697, in editPartition
File "/usr/lib/python2.7/site-packages/pyanaconda/iw/partition_gui.py", line 1639, in editCB
DeviceTreeError: duplicate paths in device tree
Finally, a good reproducer for this bug.
What's happening, more or less, is we're raising an exception during partition allocation and failing to return things to a usable state before returning to the main partitioning screen. This case involves an extended partition. I'm curious to see whether that is a common thread of the various reproducers.
As you have already three primary partitions on the disc the disc partitioning tool of fedora creates the boot-, root- and swap partitions on an extended partition. This extended partition is on the fourth location of the BIOS partitoning table.
As in the next step by changing the boot partition request to "Force to be primary" you create a "problem", because there is no room for a primary partion anymore. This should be explained to the user in an eror screen. And the "Force to be primary" request should be ignored.
Today I reproduced this test on F16-Alpha.RC5 and saw that the bug is still there!
I was not able to report the exception directly from anaconda to the bugzilla, as I was doing the test in an IPv6 setting and bugzilla.redaht.com still does not resolve to an IPv6 address.
I will shortly try this again in IPv4 namespace to upload the report to bugzilla.
Should I change Version of this bug to Fedora 16?
Report is saved under #733942
*** Bug 733942 has been marked as a duplicate of this bug. ***
Note the fixed in version. The fix will be in the first beta trees.
anaconda-16.16-1.fc16 has been submitted as an update for Fedora 16.
anaconda-16.16-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.