Bug 567576

Summary: PartitionException: Could not get flag on inactive partition /dev/sda-1
Product: [Fedora] Fedora Reporter: He Rui <rhe>
Component: pypartedAssignee: David Cantrell <dcantrell>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 13CC: awilliam, david.k.lam, dcantrell, flokip, hdegoede, jlaska, jonathan, marco.bosch, rhe, stephent98, the.masch, vanmeeuwen+fedora
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: anaconda_trace_hash:c8c14b3f5d31a4843b166a72142a2845a3f55808c9654ebd9609bebabc6dbefa
Fixed In Version: pyparted-3.1-1.fc14 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-26 20:56:38 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: 538274    
Attachments:
Description Flags
Attached traceback automatically from anaconda.
none
Attached traceback automatically from anaconda.
none
pyparted patch "fixing" this none

Description He Rui 2010-02-23 10:23:00 UTC
The following was filed automatically by anaconda:
anaconda 13.29 exception report
Traceback (most recent call first):
  File "/usr/lib/python2.6/site-packages/parted/partition.py", line 147, in getFlag
    return self.__partition.get_flag(flag)
  File "/usr/lib/python2.6/site-packages/parted/decorators.py", line 30, in localeC
    ret = fn(*args, **kwds)
  File "<string>", line 2, in getFlag
  File "/usr/lib/python2.6/site-packages/parted/partition.py", line 200, in getFlagsAsString
    if self.getFlag(flag):
  File "/usr/lib/anaconda/storage/devices.py", line 986, in __str__
    "flags": self.partedPartition.getFlagsAsString()})
  File "/usr/lib/anaconda/storage/devicetree.py", line 2068, in getDeviceByName
    log.debug("found %s" % found)
  File "/usr/lib/anaconda/storage/partitioning.py", line 824, in doPartitioning
    device = storage.devicetree.getDeviceByName(extendedName)
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1581, in refresh
    doPartitioning(self.storage)
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1680, in editPartition
    if self.refresh(justRedraw=not actions):
  File "/usr/lib/anaconda/iw/partition_gui.py", line 1560, in createCB
    self.editPartition(device, isNew = True)
PartitionException: Could not get flag on inactive partition /dev/sda-1

Comment 1 He Rui 2010-02-23 10:23:10 UTC
Created attachment 395681 [details]
Attached traceback automatically from anaconda.

Comment 2 He Rui 2010-02-23 10:44:05 UTC
Description of problem:

I tried to install Fedora-13-Alpha-RC2. At Partitioning step, I selected Create custom layout and added /boot and / manually. The first time, when I gave 5000M to / and clicked ok. It hanged. The second time, I repeated the steps, exception occurred.

Version-Release number of selected component (if applicable):
 * Fedora-13-Alpha-RC2
 * anaconda 13.29

How reproducible:
The first time it hanged. the second time exception occurred.

Steps to Reproduce:
1. Boot netinst.iso
2. Proceed through install to partitioning step:

a. Choose create cumstom layout and click next.
b. Create 500M ext4 /boot.
c. Create 5000M ext4 /.

issue happened at c.

Comment 3 David Lehman 2010-02-23 18:00:27 UTC
I have verified that the hang occurs when the extended partition is marked as active, while this exception is raised when it is marked as inactive. I have also verified that both the hang and the exception result from the call to parted.Partition.getFlagsAsString(). If I remove this call, all is well.

Comment 4 He Rui 2010-02-26 11:56:44 UTC
Created attachment 396520 [details]
Attached traceback automatically from anaconda.

Comment 5 Hans de Goede 2010-03-01 21:50:22 UTC
Ok, I've this one tracked down:

The problem lies within pyparted, and to be precise within the tracking of the
"ownership" of pedPartition objects.

We can have multiple python partition objects point to one pedPartition and
when we then remove a partition from the table, pydisk.c assumes the python
partition object now owns the pedPartition as it is no longer part of the disk
(this happens for example when temporarily removing the extended partition when
re-allocating partitons when doing manually partitioning)

However, we may have another python partition object pointing to that same
pedPartition object. If we then loose the reference which we used to remove the
partition from the disk, which happens when we do self.partitions.invalidate()
in parted/disk.py (I think). The underlying pedPartition object gets destroyed
/ free-ed.

Now the other python partition object (the one in the devicetree), has a
pointer to memory which is being re-used.

The destroying happens because the python partition object used for removing
the partition from the disk thinks it is the owner as the partition is no
longer owned by the disk. But it is not necessarily the *only* owner, yet it
still destroys it.

I'll attach a patch for pyparted, which makes this problem go away for me. I've
just successfully done an installation with custom partitioning using 7 new
partitions.

Comment 6 Hans de Goede 2010-03-01 21:50:51 UTC
Created attachment 397201 [details]
pyparted patch "fixing" this

Comment 7 Hans de Goede 2010-03-01 21:52:43 UTC
*** Bug 569496 has been marked as a duplicate of this bug. ***

Comment 8 Hans de Goede 2010-03-02 08:10:38 UTC
Re-opening this for tracking getting this fix into F-13 after the alpha is released.

Comment 9 Hans de Goede 2010-03-02 08:20:34 UTC
*** Bug 567118 has been marked as a duplicate of this bug. ***

Comment 10 Hans de Goede 2010-03-22 09:40:52 UTC
*** Bug 572278 has been marked as a duplicate of this bug. ***

Comment 11 Hans de Goede 2010-03-22 09:41:21 UTC
*** Bug 575603 has been marked as a duplicate of this bug. ***

Comment 12 Hans de Goede 2010-03-22 09:48:44 UTC
*** Bug 575390 has been marked as a duplicate of this bug. ***

Comment 13 Fedora Update System 2010-03-22 15:51:53 UTC
pyparted-3.1-1.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/pyparted-3.1-1.fc13

Comment 14 Fedora Update System 2010-03-23 23:21:15 UTC
pyparted-3.1-1.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update pyparted'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/pyparted-3.1-1.fc13

Comment 15 He Rui 2010-03-24 08:21:56 UTC
I retested anaconda 13.36 by installing F13-beta-tc1 and this issue didn't happen again.

Comment 16 Adam Williamson 2010-03-26 20:56:38 UTC
so we can close this, right?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 17 He Rui 2010-03-29 06:56:48 UTC
(In reply to comment #16)
> so we can close this, right?
> 

I can't reproduce it on anaconda 13.37 any more. So I think we can close this. Thanks, Adam.

Comment 18 Hans de Goede 2010-04-19 13:32:56 UTC
*** Bug 583214 has been marked as a duplicate of this bug. ***