Red Hat Bugzilla – Bug 707014
vgreduce --removemissing --force is activating some lvs
Last modified: 2014-10-06 10:32:30 EDT
Description of problem:
When the disk containing one or more PVs is removed, then you run 'vgreduce --removemissing --force $vgname' it appears that any LVs whose PEs are all in the still-present disks' PVs get activated. I can't see any reason why vgreduce should be activating any LVs at all.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Do a default anaconda install with two empty disks
2. Remove the second disk
3. Run vgreduce --removemissing --force $vgname
The command will complete, but then you have an active $vgname-lv_swap, which makes absolutely no sense.
No unexpectedly activated LVs since I didn't run any commands that should activate any LVs.
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.
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: