Bug 707014
Summary: | vgreduce --removemissing --force is activating some lvs | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Lehman <dlehman> | ||||
Component: | lvm2 | Assignee: | LVM and device-mapper development team <lvm-team> | ||||
Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 19 | CC: | agk, bmarzins, bmr, dwysocha, heinzm, jbrassow, jonathan, lvm-team, msnitzer, prajnoha, prockai, zkabelac | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2014-10-06 14:22:11 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: | |||||||
Attachments: |
|
Description
David Lehman
2011-05-23 18:36:56 UTC
I tried to reproduce, but any LVs remain deactivated as expected. Can you post the -vvvv log + the lvm.conf file so we can have a look what's happening in your case? Thanks. I am trying to get this output for you, but apparently adding more 'v's leads to new deadlocks/hangs. I will attach a file containing the output with -vv, but with -vvv or -vvvv I have yet to get the vgreduce command to complete. Created attachment 501152 [details]
logs of lvm output from vgreduce and vgchange -an
The vgchange command is what we have added to work around failures in the following vgremove call. If you like I can remove it to demonstrate the original failure.
See logs: 16:51:08,311 ERR program: VolGroup/lv_swap is active exclusive locally ... 16:51:08,314 ERR program: Unable to deactivate open VolGroup-lv_swap (253:0) This means that VolGroup-lv_swap was activated and is in use before vgreduce run. Isn't there some magic "activate all swaps" before the command? No, there's nothing like that. /proc/swaps was empty. Could you add either an 'lvs -a' or 'dmsetup status' before the vgreduce is run so we can see if the volume was active and open before hand? Can you please paste "dmsetup table" before the vgreduce is run? (Or even better - output of lsblk before vgreduce is run). Or even better, lsblk before and after so we can prove that vgreduce activated something. I can simply prepare the same configuration and vgreduce of course do not activate anything. BTW after "vgreduce --removemissing --force $vgname" is $vgname reapaired and lv_swap still available (but inactive) because it was on still existing PV. Is it really what do you want to achieve here? Milan, I think you are right -- this seems to be caused by some systemd magic. Once I confirm I will close this bug. Sorry for the noise. This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 |