The following was filed automatically by anaconda: anaconda 13.23 exception report Traceback (most recent call first): File "/usr/lib/anaconda/storage/devices.py", line 697, in _setFormat raise DeviceError("cannot replace active format", self.name) File "/usr/lib/anaconda/storage/devices.py", line 1170, in _setFormat StorageDevice._setFormat(self, format) File "/usr/lib/anaconda/storage/devices.py", line 705, in <lambda> lambda d,f: d._setFormat(f), File "/usr/lib/anaconda/storage/deviceaction.py", line 259, in __init__ self.device.format = format File "/usr/lib/anaconda/iw/partition_dialog_gui.py", line 285, in run actions.append(ActionCreateFormat(usedev, format)) File "/usr/lib/anaconda/iw/partition_gui.py", line 1676, in editPartition actions = parteditor.run() File "/usr/lib/anaconda/iw/partition_gui.py", line 1640, in editCB self.editPartition(device) File "/usr/lib/anaconda/iw/partition_gui.py", line 1141, in treeActivateCB self.editCB() DeviceError: ('cannot replace active format', 'sda6')
Created attachment 388344 [details] Attached traceback automatically from anaconda.
= Additional details = I have a single drive I use to dual boot 2 different versions of Fedora and Windows. The drive configuration is as follows: sda1 - ntfs (Windows) sda2 - Windows recovery partition (I think) sda3 - /boot partition for F12 sda4 - extended sda5 - LVM sda6 - /boot partition for Rawhide sda7 - master grub partition to choose between F12, Rawhide and Windows The LVM configuration is as follows * fc_root - F12 '/' partition * home - shared '/home' * rhel_root - Rawhide '/' partition * swap - well, swap partition = Steps to reproduce = 1) Boot the kernel+initrd from /boot partition on /dev/sda6. 2) Proceed through install, choosing a custom partition layout 3) Attempt to partition using the following scheme a. Repartition existing LVM LV rhel_root as '/' b. Setup '/home' as a mount (do not partition) c. Repartition existing LVM LV swap as 'swap' d. Repartition existing /dev/sda6 as /boot ... click OK Traceback!
dlehman - Is this handled by your action sorting fix (a54c02c0517fc912f86dfc2951707f2ebdef74ad) from yesterday?
(In reply to comment #3) > dlehman - Is this handled by your action sorting fix > (a54c02c0517fc912f86dfc2951707f2ebdef74ad) from yesterday? No, they're unrelated.
Somehow what happened here is parted told us that /dev/sda6 contained a valid disklabel. We evidently don't correctly handle replacingexisting disklabel formats. For now this is going to be a low priority given the circumstances required (disklabel on unpartitionable device).
anaconda-13.29-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/anaconda-13.29-1.fc13
python-urlgrabber-3.9.1-5.fc13,anaconda-13.29-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/python-urlgrabber-3.9.1-5.fc13,anaconda-13.29-1.fc13
anaconda-13.29-1.fc13, python-urlgrabber-3.9.1-5.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 anaconda python-urlgrabber'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F13/FEDORA-2010-2688
python-urlgrabber-3.9.1-5.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/F13/FEDORA-2010-2688
python-urlgrabber-3.9.1-5.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 python-urlgrabber'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F13/FEDORA-2010-2688
No longer seeing this issue using the RC4 Live media