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