The following was filed automatically by anaconda: anaconda 11.5.0.51 exception report Traceback (most recent call first): File "/usr/lib/python2.6/site-packages/parted/disk.py", line 200, in removePartition if self.__disk.remove_partition(partition.getPedPartition()): File "/usr/lib/anaconda/storage/devices.py", line 760, in removePartition self.partedDisk.removePartition(partition) File "/usr/lib/anaconda/storage/devices.py", line 1221, in destroy self.disk.removePartition(self) File "/usr/lib/anaconda/storage/deviceaction.py", line 218, in execute self.device.destroy() File "/usr/lib/anaconda/storage/devicetree.py", line 671, in processActions action.execute(intf=self.intf) File "/usr/lib/anaconda/storage/__init__.py", line 238, in doIt self.devicetree.processActions() File "/usr/lib/anaconda/packages.py", line 117, in turnOnFilesystems anaconda.id.storage.doIt() PartitionException: Attempting to remove an extended partition that still contains logical partitions
Created attachment 343938 [details] Attached traceback automatically from anaconda.
*** Bug 501580 has been marked as a duplicate of this bug. ***
This is a bad one. What's going on here is that the action for deleting the extended partition is getting sorted to earlier than the action for deleting some of its logical partitions. This is happening in storage/devicetree.py:532 or thereabouts: if a1.device.disk == a2.device.disk: ret = cmp(a2.device.partedPartition.number, a1.device.partedPartition.number) else: ret = cmp(a2.device.name, a1.device.name) a1 and a2 are different objects here with different partedPartition instances, but a1.device.partedPartition and a2.device.partedPartition are somehow referring to the same on-disk partition. At the least, they both have the same number attribute, though other attributes on partedPartition that refer to objects have different instances. I have no idea how we get into this situation. Anyway since they have the same number, cmp returns 0 and the tie goes to the delete action for the extended partition. Kaboom.
I think this occurs because when we change the PartitionDevice.partedPartition object we don't take care to change it in the DiskDevice.partedDisk.partitions[offset] and/or the other way around. To date I have not found a good solution for this. :(
I think the cause of different partition objects is in pyparted. Whenever we erase a partition the whole partition table gets read once more, thereby creating new objects.
When we scheduled the destroy action for sda6, that process included calling parted.Disk.removePartition(sda5), which led to PartitionDevice sda6's partedPartition attribute being renumbered/renamed to sda5. We did not anticipate this change, so we did not call its updateName method. Hence a PartitionDevice whose name is 'sda6' and whose partedPartition has name 'sda5'.
Created attachment 345157 [details] Attached traceback automatically from anaconda.
Created attachment 345183 [details] Attached traceback automatically from anaconda.
This should be fixed in anaconda-11.5.0.57-1.
*** Bug 503100 has been marked as a duplicate of this bug. ***
*** Bug 498820 has been marked as a duplicate of this bug. ***
*** Bug 503230 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Created attachment 349663 [details] Attached traceback automatically from anaconda.