Bug 878225

Summary: unlock of VG w/ multiple encrypted PVs in custom leads to traceback
Product: [Fedora] Fedora Reporter: David Lehman <dlehman>
Component: anacondaAssignee: David Lehman <dlehman>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 23CC: anaconda-maint-list, awilliam, cra, dmyerstu, g.kaviyarasu, jonathan, kparal, mbanas, rbinkhor, robatino, sbueno, vanmeeuwen+fedora
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:d56569456dc6201de6eafc478506969b529810e05f32cc9a80f98503cf72afa7 AcceptedNTH RejectedBlocker
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-20 12:30:32 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: 752664, 920667    
Attachments:
Description Flags
File: anaconda-tb
none
File: product
none
File: type
none
File: storage.log
none
File: version
none
File: environ
none
File: executable
none
File: anaconda.log
none
File: syslog
none
File: hashmarkername
none
File: packaging.log
none
File: cmdline_file
none
File: release
none
File: program.log
none
anaconda-tb from Ian Kelling's repro none

Description David Lehman 2012-11-19 21:29:44 UTC
Description of problem:
Testing fix for bug 875942 and hit this because we are adding the VG and the PVs to the LVM reject filter in earlier runs through devicetree.populate since in those runs we've only unlocked some of the encrypted PVs and therefore the VG is incomplete.

The current strategy for handling of incomplete raid and lvm does not involve ignoring anything, so the code that does the filtering should get disabled.


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 "/tmp/updates/pyanaconda/storage/devicelibs/lvm.py", line 401, in lvactivate
:    raise LVMError("lvactivate failed for %s: %s" % (lv_name, msg))
:  File "/tmp/updates/pyanaconda/storage/devices.py", line 2526, in _setup
:    lvm.lvactivate(self.vg.name, self._name)
:  File "/tmp/updates/pyanaconda/storage/devices.py", line 715, in setup
:    self._setup(orig=orig)
:  File "/tmp/updates/pyanaconda/storage/devicetree.py", line 1300, in handleVgLvs
:    lv_device.setup()
:  File "/tmp/updates/pyanaconda/storage/devicetree.py", line 1759, in _setupLvs
:    if self.handleVgLvs(device):
:  File "/tmp/updates/pyanaconda/storage/devicetree.py", line 1947, in _populate
:    if self._setupLvs():
:  File "/tmp/updates/pyanaconda/storage/devicetree.py", line 1850, in populate
:    self._populate()
:  File "/tmp/updates/pyanaconda/ui/gui/spokes/custom.py", line 2336, in on_unlock_clicked
:    self.__storage.devicetree.populate()
:LVMError: lvactivate failed for root: running lvm lvchange -a y --config  devices { filter=["r|/loop3$|","r|/loop4$|","r|/loop5$|","r|/loop6$|","r|/loop7$|","r|/fedora$|","r|/luks-055018a7-30e3-4783-bc0c-5f6fb083b0f0$|","r|/luks-055018a7-30e3-4783-bc0c-5f6fb083b0f0$|","r|/fedora$|","r|/luks-055018a7-30e3-4783-bc0c-5f6fb083b0f0$|","r|/luks-055018a7-30e3-4783-bc0c-5f6fb083b0f0$|","r|/luks-a86d55aa-5456-4875-88c7-9f3d71635bdd$|","r|/luks-a86d55aa-5456-4875-88c7-9f3d71635bdd$|"] }  fedora/root failed

Comment 1 David Lehman 2012-11-19 21:29:53 UTC
Created attachment 648131 [details]
File: anaconda-tb

Comment 2 David Lehman 2012-11-19 21:29:56 UTC
Created attachment 648132 [details]
File: product

Comment 3 David Lehman 2012-11-19 21:29:57 UTC
Created attachment 648133 [details]
File: type

Comment 4 David Lehman 2012-11-19 21:30:03 UTC
Created attachment 648134 [details]
File: storage.log

Comment 5 David Lehman 2012-11-19 21:30:05 UTC
Created attachment 648135 [details]
File: version

Comment 6 David Lehman 2012-11-19 21:30:06 UTC
Created attachment 648136 [details]
File: environ

Comment 7 David Lehman 2012-11-19 21:30:08 UTC
Created attachment 648137 [details]
File: executable

Comment 8 David Lehman 2012-11-19 21:30:10 UTC
Created attachment 648138 [details]
File: anaconda.log

Comment 9 David Lehman 2012-11-19 21:30:12 UTC
Created attachment 648139 [details]
File: syslog

Comment 10 David Lehman 2012-11-19 21:30:14 UTC
Created attachment 648140 [details]
File: hashmarkername

Comment 11 David Lehman 2012-11-19 21:30:15 UTC
Created attachment 648141 [details]
File: packaging.log

Comment 12 David Lehman 2012-11-19 21:30:17 UTC
Created attachment 648142 [details]
File: cmdline_file

Comment 13 David Lehman 2012-11-19 21:30:19 UTC
Created attachment 648143 [details]
File: release

Comment 14 David Lehman 2012-11-19 21:30:21 UTC
Created attachment 648144 [details]
File: program.log

Comment 15 David Lehman 2012-11-19 21:34:38 UTC
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.

Comment 16 Adam Williamson 2012-11-20 00:25:25 UTC
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.

Comment 17 Dennis Gilmore 2012-11-20 00:27:40 UTC
+1 NTH here

Comment 18 Kevin Fenzi 2012-11-20 00:30:18 UTC
Yeah, +1 NTH

Comment 19 Adam Williamson 2012-11-20 00:35:26 UTC
AcceptedNTH at least (blocker status can wait for a meeting)

Comment 20 Fedora Update System 2012-11-20 22:03:23 UTC
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

Comment 21 Kamil Páral 2012-11-21 16:25:14 UTC
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.

Comment 22 David Lehman 2012-11-21 17:08:08 UTC
(In reply to comment #21)
> So either the reproducer is not complete or it doesn't happen always.

Did you do this on a system with multiple disks?

Comment 23 Adam Williamson 2012-11-21 17:27:10 UTC
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.

Comment 24 Kamil Páral 2012-11-21 20:01:19 UTC
(In reply to comment #22)
> (In reply to comment #21)
> > So either the reproducer is not complete or it doesn't happen always.
> 
> Did you do this on a system with multiple disks?

No, is it necessary to trigger the bug?

Comment 25 David Lehman 2012-11-21 20:04:06 UTC
(In reply to comment #24)
> (In reply to comment #22)
> > (In reply to comment #21)
> > > So either the reproducer is not complete or it doesn't happen always.
> > 
> > Did you do this on a system with multiple disks?
> 
> No, is it necessary to trigger the bug?

Yes -- hence the phrase "multiple encrypted PVs" in the bug summary.

Comment 26 Kamil Páral 2012-11-21 20:10:58 UTC
Ah, I misread that for multiple LVs. BTW multiple PVs doesn't inherently mean multiple disks. But thanks for clarification, I'll try to verify if no one else gets to it first.

Comment 27 Fedora Update System 2012-11-21 20:51:58 UTC
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).

Comment 28 Fedora Update System 2012-11-23 07:28:35 UTC
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.

Comment 29 Kamil Páral 2012-11-23 12:17:46 UTC
Verified in bug 875942 comment 30.

Comment 30 Ian Kelling 2013-01-17 12:31:31 UTC
I just hit this bug on F18 final release, so it seems this should be reopened. The bug report tool said it found this bug as a duplicate. I tried to unlock an encrypted partition (created using F17 installer) in the custom partioning setup and got a fatal error dialog.

The specific media I'm using:
http://fedora.mirror.constant.com/linux/releases/18/Fedora/x86_64/iso/Fedora-18-x86_64-netinst.iso

Let me know if there is more info I can provide, as I can duplicate the bug fairly easily.

Comment 31 Kamil Páral 2013-01-17 13:43:52 UTC
Ian, can you please reproduce the issue, switch to TTY2, find /tmp/anaconda-tb-* file and attach it here? Thanks.

Comment 32 Ian Kelling 2013-01-17 18:01:53 UTC
Created attachment 680417 [details]
anaconda-tb from Ian Kelling's repro

Comment 33 J.H.M. Dassen (Ray) 2013-01-20 12:05:36 UTC
I was attempting to install Fedora 18 on my workstation (which currently has Fedora 17 installed), while retaining my existing /home volume and several LVM LVs that are backing store for qemu/kvm VMs. The data I want to preserve exists on sda3 which is a LUKS encrypted LVM PV. I selected the drive on which to install, told anaconda not to use guided partitioning, was presented with the manual partitioning screen, was presented with the existing installation as "unknown", selected sda3, provided the passphrase for it, selected "Unlock" and was presented with "An unknown error has occurred".

Earlier I had followed a very similar procedure to upgrade my laptop (which is set up in a very similar fashion, including a LUKS encrypted partition holding all non-/boot content but which does not have an second drive attached to it) and there it had worked fine.

The vg_external/media referenced in the LVMError is an LV in a separate VG "vg_external" which is hosted on (external) sdb which I had _not_ selected as an installation target. Anaconda should not be attempting to activate this LV (or any other LVs in this VG) IMHO.

failed
LVMError: lvactivate failed for media: running lvm lvchange -a y --config  devices { filter=["r|/loop3$|","r|/loop4$|","r|/loop5$|","r|/loop6$|","r|/loop7$|","r|/sdb1$|","r|/sdb2$|","r|/vg_external-media$|","r|/vg_external-csb$|","r|/vg_external-rhel5beta$|","r|/vg_external-devel$|","r|/vg_external-rhel61beta$|","r|/vg_external-scratch$|","r|/vg_external-xmpp$|","r|/vg_external-MRG-exp$|","r|/vg_external-MRG$|","r|/vg_external-rhel-snap$|","r|/vg_external$|","r|/sdb5$|","r|/sdb6$|","r|/sdb7$|","r|/sdb8$|","r|/sdb$|"] }  


Package: anaconda-18.37.11
OS Release: Fedora release 18

Comment 34 Douglas Myers-Turnbull 2013-01-21 06:01:39 UTC
I tried to unlock an encrypted partition on the Anaconda disk partitioning screen. When I entered my password, there was a short delay, then Anaconda stopped. The encrypted partition was created by Anaconda for F17 (my previous installation).

Package: anaconda-18.37.11-1.fc18.x86_64
OS Release: Fedora release 18

Comment 35 David Lehman 2013-01-22 17:04:46 UTC
We need to account for hidden devices when populating the devicetree.

Comment 36 Adam Williamson 2013-01-25 00:09:22 UTC
"Anaconda should not be attempting to activate this LV (or any other LVs in this VG) IMHO."

If I recall correctly from similar output in another bug, it isn't: it's explicitly filtering it out.

Comment 37 Charles R. Anderson 2013-03-23 07:04:46 UTC
Custom partitioning/reclaim space, click on existing LUKS encrypted partition, type in Passphrase, click Unlock.

Package: anaconda-18.37.11
OS Release: Fedora release 18

Comment 38 Adam Williamson 2013-12-12 01:13:45 UTC
bumping to rawhide so it doesn't get auto-closed, devs, if you think this is no longer relevant with whatever changes have gone into 19 and 20, we can always close it...

Comment 39 Jan Kurik 2015-07-15 14:56:26 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Comment 40 Fedora End Of Life 2016-11-24 10:51:34 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 41 Fedora End Of Life 2016-12-20 12:30:32 UTC
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.