[SOLVED] LVM2 upgrade caused LVM partition to not be recognized

A recent upgrade to LVM2, 2.02.179, caused a curious anomaly to my bootup sequence. My /home partition, which is mounted on /dev/slack/slack, was not being initialized. After downgrading to the previous version, 2.02.177, LVM was again being initialized. I don't know how many others have experienced this problem, if at all, but I just thought I'd share my experience.

I don't know if this is related, but it seems like it might be:

Version 2.02.178 ================ There are going to be some large changes to the lvm2 codebase over the next year or so. Starting with this release. These changes should be internal rather than having a big effect on the command line. Inevitably these changes will increase the chance of bugs, so please be on the alert.

https://github.com/lvmteam/lvm2/blob...notes/2.02.178

Originally Posted by fskmh I don't know if this is related, but it seems like it might be: https://github.com/lvmteam/lvm2/blob...notes/2.02.178

I think that might be the root of the problem. Part of the side effects of the code change could be that the code for initializing LVM will be different. Anyway, I'm sticking with the previous version until this problem is solved.

Has your home volume been around a long time? In other words, could it still be using an old metadata version that's now been removed?

I'm using LVM for almost everything here, and so far no problems with the new version.

Originally Posted by volkerdi Has your home volume been around a long time? In other words, could it still be using an old metadata version that's now been removed? I'm using LVM for almost everything here, and so far no problems with the new version.

The LVM volume is approximately 2-3 years old, and I've never had a problem with it being detected until the latest update. So I don't know whether it has old metadata information or not.

# pvscan
  PV /dev/md127   VG raid1           lvm2 [457.12 GiB / 429.12 GiB free]
  PV /dev/sdc1    VG noraid          lvm2 [596.17 GiB / 336.17 GiB free]
  PV /dev/md3     VG raid0           lvm2 [298.10 GiB / 88.10 GiB free]
  Total: 3 [1.32 TiB] / in use: 3 [1.32 TiB] / in no VG: 0 [0   ]

Column 5 (starting from 1, that is) is the metadata version.

Originally Posted by Richard Cranium # pvscan PV /dev/md127 VG raid1 lvm2 [457.12 GiB / 429.12 GiB free] PV /dev/sdc1 VG noraid lvm2 [596.17 GiB / 336.17 GiB free] PV /dev/md3 VG raid0 lvm2 [298.10 GiB / 88.10 GiB free] Total: 3 [1.32 TiB] / in use: 3 [1.32 TiB] / in no VG: 0 [0 ] Column 5 (starting from 1, that is) is the metadata version.

This is the output from pvscan:

# pvscan
  PV /dev/sdc1   VG slack           lvm2 [<2.73 TiB / 0    free]
  PV /dev/sdb1   VG slack           lvm2 [<2.73 TiB / 0    free]
  PV /dev/sdd1   VG slack           lvm2 [<2.73 TiB / 0    free]
  PV /dev/sde1   VG slack           lvm2 [<3.64 TiB / 0    free]
  Total: 4 [<11.83 TiB] / in use: 4 [<11.83 TiB] / in no VG: 0 [0   ]

Every time I try to upgrade to the latest version, /dev/slack/slack fails to initialize.

So what are my options here? Is there a way to "refresh" the metadata so that it is recognized on the next boot by the latest version of lvm2?

Any help will be much appreciated!

What does

vgscan

tell you?

# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "raid1" using metadata type lvm2
  Found volume group "noraid" using metadata type lvm2
  Found volume group "raid0" using metadata type lvm2

Originally Posted by Richard Cranium What does vgscan tell you? # vgscan Reading all physical volumes. This may take a while... Found volume group "raid1" using metadata type lvm2 Found volume group "noraid" using metadata type lvm2 Found volume group "raid0" using metadata type lvm2

# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "slack" using metadata type lvm2

I believe it is safe to say that your machine is using lvm2 metadata everywhere.

Well, I guess we can look at the logical volumes as well...

# lvscan
  ACTIVE            '/dev/raid1/rootlv' [16.00 GiB] inherit
  ACTIVE            '/dev/raid1/homelv' [4.00 GiB] inherit
  ACTIVE            '/dev/raid1/loglv' [4.00 GiB] inherit
  ACTIVE            '/dev/raid1/optlv' [4.00 GiB] inherit
  ACTIVE            '/dev/noraid/mongolv' [80.00 GiB] inherit
  ACTIVE            '/dev/noraid/tmplv' [180.00 GiB] inherit
  ACTIVE            '/dev/raid0/mongolv' [130.00 GiB] inherit
  ACTIVE            '/dev/raid0/slackrepolv' [80.00 GiB] inherit

I ass-u-me that "inherit" means the logical volume is using the metadata from the volume group, but I'm sitting on where I got that information.

Sat Jun 23 01:22:07 UTC 2018
a/aaa_elflibs-15.0-x86_64-2.txz:  Rebuilt.
  Upgraded libacl.so.1 and libattr.so.1.
  Added libaio.so.1 (needed by future versions of lvm).
a/lvm2-2.02.177-x86_64-1.txz:  Upgraded.
  Revert to the previous working version of lvm2. Based on the comments
  in the release notes for version 2.02.178, perhaps it would be prudent
  to sit out the next year and a half of planned instability. I can't
  recall ever _needing_ to upgrade LVM (the version number has been on
  2.02.x for well over a decade)... let's avoid being beta testers as
  upstream refactors everything.

Well, as Pat has seen fit to revert to the previous working version, I consider this matter closed. Thanks for all the help!