I was encountering same, or highly similar issue, notably pvmove segfaults. Currently on Debian oldstable. I also found the relatively informative similar/related thread: https://lists.debian.org/debian-user/2011/06/msg01947.html https://lists.debian.org/debian-user/2011/06/msg02076.html
My situation "the same", or highly similar: pvmove segfaults lvs -a and lvdisplay -a show a [pvmove0] volume attempts at: pvmove --abort lvremove [-f] ...pvmove0 lvchange ... pvmove0 lvmremove [-f] ... pvmove0 all failed The threat mentioned above had suggestion to remove the dm device, however, using blkid on all dm devices, I found no DM device with the UUID shown by lvdisplay -a nor any devices/links with or containing name pvmove0, and pvmove0 (in lvdisplay -a, lvs -a) also showed it as size 0, and everything LVM related reported it as locked and inactive. Not sure what created this situation, but .. workaround for the above: I ran vgcfgbackup twice (so I'd have both "current" config saved, and one slightly older archive saved copy of same). I then edited the most recent saved copy, removing the pvmove0 section. I then used vgcfgrestore. After that, all was fine and good. :-) No more complaints or signs about pvmove0, and pvmove worked again fine and as expected. Suggestion - see if something can be added to the lvm code to recognize this situation and self-correct (or even prevent). It may also be quite feasible to reproduce the problem, by injecting such data into a file created by vgcfgbackup, then using vgcfgrestore (I've not attempted that). But, in case that may be useful, here's the section I'd removed: # pwd -P; sed -ne '/pvmove0 {/,/}/p' tigger_00754-383252791.vg /etc/lvm/archive pvmove0 { id = "23mVuC-uEaK-gB3Z-9WU0-nYbM-91ls-kQ9KXf" status = ["READ", "WRITE", "PVMOVE", "LOCKED"] flags = [] allocation_policy = "contiguous" segment_count = 0 } #