Description of problem: Performing custom partitioning on a virt guest that has an existing F-18 LUKS LVM installation. I enter my password on the first encrypted volume I see and click Unlock, then get this traceback. Version-Release number of selected component: anaconda-18.28 Additional info: libreport version: 2.0.17 cmdline: /usr/bin/python /sbin/anaconda kernel: 3.6.6-3.fc18.x86_64 description: :The following was filed automatically by anaconda: :anaconda 18.28 exception report :Traceback (most recent call first): : File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1508, in _populate_right_side : typeCombo.set_active(type_index_map[device_type]) : File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1823, in on_selector_clicked : self._populate_right_side(selector) : File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1687, in _show_first_mountpoint : self.on_selector_clicked(page._members[0]) : File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1841, in on_page_clicked : self._show_first_mountpoint(page=page) : File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 701, in _do_refresh : self.on_page_clicked(self._accordion.currentPage()) : File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 2071, in on_unlock_clicked : self._do_refresh() :KeyError: None
Created attachment 643778 [details] File: anaconda-tb
Created attachment 643779 [details] File: product
Created attachment 643780 [details] File: type
Created attachment 643781 [details] File: ifcfg.log
Created attachment 643782 [details] File: storage.log
Created attachment 643783 [details] File: version
Created attachment 643784 [details] File: environ
Created attachment 643785 [details] File: executable
Created attachment 643786 [details] File: anaconda.log
Created attachment 643787 [details] File: syslog
Created attachment 643788 [details] File: hashmarkername
Created attachment 643789 [details] File: packaging.log
Created attachment 643790 [details] File: cmdline_file
Created attachment 643791 [details] File: release
Created attachment 643792 [details] File: program.log
We need special handling for the case of a vg that is also a leaf, probably a special display for the RHS that says something like "Not sure what this device is, but your only options are to remove it or leave it as-is."
*** Bug 877241 has been marked as a duplicate of this bug. ***
This means that anyone with a preexisting VG with encrypted PVs (read: encrypted autopart) who tries to unlock the PVs from the custom spoke will end up hitting a traceback and therefore will be unable to work with their existing VG. (Yes, same scenario as bug 878225. The immediate fix for this is what exposed that one.)
I'm at least +1 nth as this is a rather frustrating problem and not too hard to hit it - just try and install to a system with existing autopart encrypted LVM and go through custom part. I'm not sure it's bad enough to be blocker, but dlehman says the fixes for this and 878225 are small and tested, so I'm +/-0 blocker, +1 NTH.
+1 NTH here
+1 NTH
AcceptedNTH at least (blocker status can wait for a meeting)
anaconda-18.29.2-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2012-18468/anaconda-18.29.2-1.fc18
I wasn't able to reproduce the issue with anaconda 18.28, so I can't test the fix. I created default F18 encrypted LVM installation and rebooted back into the installer, but I could unlock it just fine. I had the whole VG encrypted. I also performed an F17 installation where I had VG unencrypted and only a single LV encrypted, but again, after rebooting to anaconda 18.28, I could unlock it just fine. So either the reproducer is not complete or it doesn't happen always.
(In reply to comment #24) > So either the reproducer is not complete or it doesn't happen always. It requires multiple disks. You unlock one of the PVs (preferably the one on the last disk), then click on the new entry that appears under the Unknown section on the left side. That entry should represent a VG, which should trigger the unhandled exception.
Discussed at 2012-11-21 blocker review meeting. We confirmed the NTH call on this but rejected it as a blocker as we think it's just a bit too complex to make the criteria, with the addition of the requirement for multiple disks. I will try and test it with RC1 if I can reproduce the failure.
Package anaconda-18.29.2-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.29.2-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-18468/anaconda-18.29.2-1.fc18 then log in and leave karma (feedback).
we need to confirm this is fixed in RC1.
anaconda-18.29.2-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Verified fixed in 18.29.2. That doesn't mean that there are no other problems (e.g. no LVs appeared after unlocking the VG), but this particular crash is gone.