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
Created attachment 395681 [details] Attached traceback automatically from anaconda.
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.
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.
Created attachment 396520 [details] Attached traceback automatically from anaconda.
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.
Created attachment 397201 [details] pyparted patch "fixing" this
*** Bug 569496 has been marked as a duplicate of this bug. ***
Re-opening this for tracking getting this fix into F-13 after the alpha is released.
*** Bug 567118 has been marked as a duplicate of this bug. ***
*** Bug 572278 has been marked as a duplicate of this bug. ***
*** Bug 575603 has been marked as a duplicate of this bug. ***
*** Bug 575390 has been marked as a duplicate of this bug. ***
pyparted-3.1-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/pyparted-3.1-1.fc13
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
I retested anaconda 13.36 by installing F13-beta-tc1 and this issue didn't happen again.
so we can close this, right? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(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.
*** Bug 583214 has been marked as a duplicate of this bug. ***