Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

Not sure about the severity; as luck would have it my system can boot,
but many volumes were rendered entirely unavailable so for some this
would be a showstopper.

This issue appears to be specific to the use of thin provisioned
logical volumes.  Non-thin volumes even in the same vg come up just
fine.

   * What led up to the situation?

Automated update to kernel 4.9.0-8-amd64.  The latest stable lvm2
package version 2.02.168-2 was on the system.

This combination does not work.  Apparently the thin params in
question originate out of the kernel's dm ioctl, yielding the error in
the headline from lvs, vgchange, etc.

Also, most of the tools segfault starting after I ran vgchange -ay
manually to try and activate the missing volumes.  Unclear why they
didn't segfault starting from the first run.

Non-thin volumes were activated properly at initramfs time.  So I was
able to poke around and ultimately fix things by updating lvm2.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

I built the lvm2 packages from testing, installed those, and now it
works.  The only missing build-dep was debhelper, satisfied from
backports.  The system info below reflects my self-built testing
backport of lvm2, which is version 2.03.02-1.

Notably I did not install a newer thin-provisioning-tools, just the
packages from building lvm2.

BTW this lvm2-vs-kernel breakage issue, including debian having "old"
lvm2 tools, is the subject of one of Linus's patented gentle
discussions on lkml, wherein he is adament that 'NOBODY gets to say
"oh, you should just update user land tools"'.*  So it would be nice
for the deb lvm team to either mask this issue by somehow guaranteeing
compatibility of shipped versions and/or applying all due pressure
upstream to eliminate this sort of breakage.

* https://lore.kernel.org/lkml/1ec0a220-d5b0-1c27-e63b-c4d3f4ce9d77@torlan.ru/T/

I've hit what I think is a thin related issue on upgrading to
bullseye/testing. My boot hangs on fsck timing out on the 3 thin
provisioned partitions. I manually did a vgchange -ay to active them but it
didn't solve the problem. If I drop into maintenance mode and manually
"mount -a" things do mount and I can exit and continue the boot.

I'm not sure the best way to further diagnose this and see if it's really
related.

Hi,

Just a quick note that the failure mode still exists after upgrading to
bookworm (testing). If anyone has any pointers on how to diagnose mount
failures during initrd I'd happily run some experiments.