Bug 500808

Summary: partitioning backtrace: removal of logical part
Product: [Fedora] Fedora Reporter: Jens Petersen <petersen>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 11CC: anaconda-maint-list, bblakesl, cerbe, dlehman, duck, gvarisco, indbleta, jgranado, jlaska, mattdm, pbrobinson, ploujj, rmaximo, sertacyildiz, silas, valent.turkovic, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: anaconda_trace_hash:e2f312f2e7c48a6623b118d0db45bedcf52a4ff521d22c4dccf800a96c2abc4b
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-06-25 15:29:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 446452    
Attachments:
Description Flags
Attached traceback automatically from anaconda.
none
Attached traceback automatically from anaconda.
none
Attached traceback automatically from anaconda.
none
Attached traceback automatically from anaconda. none

Description Jens Petersen 2009-05-14 10:17:59 UTC
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

Comment 1 Jens Petersen 2009-05-14 10:18:06 UTC
Created attachment 343938 [details]
Attached traceback automatically from anaconda.

Comment 2 Chris Lumens 2009-05-19 20:26:30 UTC
*** Bug 501580 has been marked as a duplicate of this bug. ***

Comment 3 Chris Lumens 2009-05-19 20:33:05 UTC
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.

Comment 4 Joel Andres Granados 2009-05-21 08:12:36 UTC
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. :(

Comment 5 Joel Andres Granados 2009-05-21 11:41:30 UTC
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.

Comment 6 David Lehman 2009-05-21 16:13:04 UTC
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'.

Comment 7 James Laska 2009-05-22 20:02:21 UTC
Created attachment 345157 [details]
Attached traceback automatically from anaconda.

Comment 8 Vladi 2009-05-23 08:35:33 UTC
Created attachment 345183 [details]
Attached traceback automatically from anaconda.

Comment 9 Chris Lumens 2009-05-28 20:21:51 UTC
This should be fixed in anaconda-11.5.0.57-1.

Comment 10 Chris Lumens 2009-05-28 21:12:11 UTC
*** Bug 503100 has been marked as a duplicate of this bug. ***

Comment 11 Chris Lumens 2009-05-29 15:14:28 UTC
*** Bug 498820 has been marked as a duplicate of this bug. ***

Comment 12 Chris Lumens 2009-05-29 18:45:27 UTC
*** Bug 503230 has been marked as a duplicate of this bug. ***

Comment 13 Bug Zapper 2009-06-09 15:48:56 UTC
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

Comment 14 indbleta 2009-06-27 16:08:29 UTC
Created attachment 349663 [details]
Attached traceback automatically from anaconda.