Bug 878225
Summary: | unlock of VG w/ multiple encrypted PVs in custom leads to traceback | ||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Lehman <dlehman> | ||||||||||||||||||||||||||||||||
Component: | anaconda | Assignee: | David Lehman <dlehman> | ||||||||||||||||||||||||||||||||
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||||||||||
Priority: | unspecified | ||||||||||||||||||||||||||||||||||
Version: | 23 | CC: | 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
David Lehman
2012-11-19 21:29:44 UTC
Created attachment 648131 [details]
File: anaconda-tb
Created attachment 648132 [details]
File: product
Created attachment 648133 [details]
File: type
Created attachment 648134 [details]
File: storage.log
Created attachment 648135 [details]
File: version
Created attachment 648136 [details]
File: environ
Created attachment 648137 [details]
File: executable
Created attachment 648138 [details]
File: anaconda.log
Created attachment 648139 [details]
File: syslog
Created attachment 648140 [details]
File: hashmarkername
Created attachment 648141 [details]
File: packaging.log
Created attachment 648142 [details]
File: cmdline_file
Created attachment 648143 [details]
File: release
Created attachment 648144 [details]
File: program.log
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. 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 Yeah, +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 #21) > So either the reproducer is not complete or it doesn't happen always. Did you do this on a system with multiple disks? 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. (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? (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. 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. 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). 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 in bug 875942 comment 30. 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. Ian, can you please reproduce the issue, switch to TTY2, find /tmp/anaconda-tb-* file and attach it here? Thanks. Created attachment 680417 [details]
anaconda-tb from Ian Kelling's repro
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 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 We need to account for hidden devices when populating the devicetree. "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. 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 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... 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 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. 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. |