On Tue, Oct 5, 2021 at 6:57 PM Ming Hung Tsai <mtsai@redhat.com> wrote:
On Tue, Oct 5, 2021 at 11:54 PM Zdenek Kabelac <zkabelac@redhat.com> wrote:
> But before continuing with advices - what is the version of kernel lvm2 & your
> device-mapper-persistent-data package (aka  'cache_check -V)
>
These are the software versions:
$ /usr/sbin/cache_check -V
0.9.0
$ /usr/sbin/lvm version
  LVM version:     2.03.11(2) (2021-01-08)
  Library version: 1.02.175 (2021-01-08)
/dev/mapper/control: open failed: Permission denied
Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.02.175 (2021-01-08) and kernel driver (unknown version).
  Configuration:   ./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=${prefix}/include --mandir=${prefix}/share/man --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --libdir=/lib/x86_64-linux-gnu --sbindir=/sbin --with-usrlibdir=/usr/lib/x86_64-linux-gnu --with-optimisation=-O2 --with-cache=internal --with-device-uid=0 --with-device-gid=6 --with-device-mode=0660 --with-default-pid-dir=/run --with-default-run-dir=/run/lvm --with-default-locking-dir=/run/lock/lvm --with-thin=internal --with-thin-check=/usr/sbin/thin_check --with-thin-dump=/usr/sbin/thin_dump --with-thin-repair=/usr/sbin/thin_repair --with-udev-prefix=/ --enable-applib --enable-blkid_wiping --enable-cmdlib --enable-dmeventd --enable-editline --enable-lvmlockd-dlm --enable-lvmlockd-sanlock --enable-lvmpolld --enable-notify-dbus --enable-pkgconfig --enable-udev_rules --enable-udev_sync --disable-readline
$ uname -a
Linux archer 5.14.0-1-amd64 #1 SMP Debian 5.14.6-3 (2021-09-28) x86_64 GNU/Linux
 
> lvconvert --repair should be able to handle this case - although likely
> without 'smart' placement' of fixed metadata (pvmove needed after metadata fix)
I tried running lvconvert --repair earlier (please see the 1st of my mails) and even trough the operation finished successfully (as in the $? == 0) I couldn't activate the volume afterwards.
 
cache_repair might not handle this case perfectly. If possible, you
could upload the "original" metadata somewhere for me to take a look,
by dd it into a binary file.
Unfortunately I deleted the original metadata volume when I was trying to remove the cached volume.

So right now, I guess, the question is how do I remove the cached volume, as the repair doesn't seem to be possible.

Regards,
Krzysztof Chojnowski