Created attachment 339156 [details]
Anaconda exception report
Description of problem:
After booting F11-Snap1-Live-i686 on a standard Intel P4 system with a single attached IDE disk, liveinst crashes when a volume of the existing custom disk layout is edited.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start liveinst on F11-Snap1-Live-i686.
2. Edit existing LVM disk layout.
Installer aborts with an exception when editing the first volume in order to set file system type and mount point.
Existing disk layout can be edited for further use.
- There was a similar bug which affected F11-rawhide maybe 2 months ago, but
it did not occur for the later F11-Nouveau-Test-Day release. So, I guess
it's a new bug.
- Custom disk layout was chosen. Only file system type and mount point of the
existing volumes were intended to be customized.
Expanding traceback from comment#0
anaconda None exception report
Traceback (most recent call first):
File "/usr/lib/anaconda/iw/partition_ui_helpers_gui.py", line 334, in createPreExistFSOptionSection
if not formatcb.get_active() and not origfs.migrate:
File "/usr/lib/anaconda/iw/lvm_dialog_gui.py", line 491, in editLogicalVolume
(row, self.fsoptionsDict) = createPreExistFSOptionSection(reallv, maintable, row, mountCombo, self.storage, ignorefs = ["mdmember", "lvmpv", "vfat"], luksdev=templuks)
File "/usr/lib/anaconda/iw/lvm_dialog_gui.py", line 716, in editCurrentLogicalVolume
File "/usr/lib/anaconda/iw/lvm_dialog_gui.py", line 747, in editLogicalVolumeCB
AttributeError: 'NoneType' object has no attribute 'get_active'
*** Bug 495202 has been marked as a duplicate of this bug. ***
*** Bug 495584 has been marked as a duplicate of this bug. ***
*** Bug 494138 has been marked as a duplicate of this bug. ***
Fixed in anaconda-188.8.131.52-1
I just tried the Fedora-11-Snap1-x86_64-Live-KDE CD again, downloaded and installed anaconda-184.108.40.206-1 from koji and then ran install to disk. Resulted in new crash, see bug 495665.
*** Bug 495404 has been marked as a duplicate of this bug. ***
I am still seeing something that might be related to this. I got a message about a failure to destroy sdb and then another traceback when I tried to directly file a bug from anaconda. Using dd to wipe the partition info allowed me to get past that issue. This was with 220.127.116.11-1.
With 18.104.22.168-1 I was able to complete an encrypted raid install.
I haven't seen this issue with recent versions of anaconda.