This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 500808 - partitioning backtrace: removal of logical part
partitioning backtrace: removal of logical part
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
11
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
anaconda_trace_hash:e2f312f2e7c48a662...
:
: 498820 501580 503100 503230 (view as bug list)
Depends On:
Blocks: F11Blocker/F11FinalBlocker
  Show dependency treegraph
 
Reported: 2009-05-14 06:17 EDT by Jens Petersen
Modified: 2010-01-25 09:12 EST (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-25 11:29:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Attached traceback automatically from anaconda. (178.18 KB, text/plain)
2009-05-14 06:18 EDT, Jens Petersen
no flags Details
Attached traceback automatically from anaconda. (158.40 KB, text/plain)
2009-05-22 16:02 EDT, James Laska
no flags Details
Attached traceback automatically from anaconda. (100.24 KB, text/plain)
2009-05-23 04:35 EDT, Vladi
no flags Details
Attached traceback automatically from anaconda. (198.15 KB, text/plain)
2009-06-27 12:08 EDT, indbleta
no flags Details

  None (edit)
Description Jens Petersen 2009-05-14 06:17:59 EDT
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 06:18:06 EDT
Created attachment 343938 [details]
Attached traceback automatically from anaconda.
Comment 2 Chris Lumens 2009-05-19 16:26:30 EDT
*** Bug 501580 has been marked as a duplicate of this bug. ***
Comment 3 Chris Lumens 2009-05-19 16:33:05 EDT
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 04:12:36 EDT
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 07:41:30 EDT
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 12:13:04 EDT
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 16:02:21 EDT
Created attachment 345157 [details]
Attached traceback automatically from anaconda.
Comment 8 Vladi 2009-05-23 04:35:33 EDT
Created attachment 345183 [details]
Attached traceback automatically from anaconda.
Comment 9 Chris Lumens 2009-05-28 16:21:51 EDT
This should be fixed in anaconda-11.5.0.57-1.
Comment 10 Chris Lumens 2009-05-28 17:12:11 EDT
*** Bug 503100 has been marked as a duplicate of this bug. ***
Comment 11 Chris Lumens 2009-05-29 11:14:28 EDT
*** Bug 498820 has been marked as a duplicate of this bug. ***
Comment 12 Chris Lumens 2009-05-29 14:45:27 EDT
*** Bug 503230 has been marked as a duplicate of this bug. ***
Comment 13 Bug Zapper 2009-06-09 11:48:56 EDT
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 12:08:29 EDT
Created attachment 349663 [details]
Attached traceback automatically from anaconda.

Note You need to log in before you can comment on or make changes to this bug.