TL;DR

1
2
3
4
5
6

vgscan
pvs; vgs; lvs -a -o +devices,lv_health_status     # is a PV missing? which LV will not activate and why?

vgchange -ay                                       # normal attempt
vgchange -ay --activationmode degraded             # LVM raid1/raid5/raid6 LVs with a missing PV
vgchange -ay --activationmode partial              # any LV with a missing PV: ONLY to copy data, mount ro

If the failure is at boot (emergency shell because / or /home does not show up), run the same commands from the initramfs prompt, prefixed with lvm if there are no standalone binaries (lvm vgchange -ay), then exit.

What to look at first

CommandWhat it tells you
pvsWARNING: Couldn't find device with uuid … or [unknown]: a PV is gone. Dead disk, controller that did not enumerate, cable, or an ID that changed
lvs -a -o +devices,lv_health_statusAttribute p = partial; lv_health_status says partial, refresh needed, needs check…
dmesg | grep -iE 'sd[a-z]|nvme|error'Did the disk come back after the outage? Is it throwing read errors?
journalctl -b | grep -i lvmWhat autoactivation tried at boot and why it failed
ls /etc/lvm/archive/Copies of the metadata before every change; you need them if a restore is due

The three activation modes (man vgchange): complete (the default) only activates LVs with all their PVs present; degraded activates LVM RAID LVs missing a leg; partial activates any LV even with missing PVs, filling the gaps with errors or zeros, and is only for recovery.

Cases

1. A PV is missing

Fix the hardware first: reseat, change ports, check the controller. As soon as pvs sees it, vgchange -ay and done.

If the disk does not come back and the LV was linear across several PVs, whatever lived on that disk is gone. Rescue the rest read-only:

1
2
3

vgchange -ay --activationmode partial
mount -o ro /dev/vg01/data /mnt/rescue
rsync -a /mnt/rescue/ /somewhere/else/

And only after copying, clean up the VG: vgreduce --removemissing --force vg01.

2. LVM RAID LVs (raid1, raid5, raid6)

With a missing leg they come up in degraded mode:

1

vgchange -ay --activationmode degraded

Then replace the PV: vgextend vg01 /dev/sdX with the new disk and lvconvert --repair vg01/data. If the LV will not activate even so (reload ioctl … failed, _rimage_ sub-LVs active but not the LV), you are in the scenario where LVM RAID tooling falls short; restoring from backup is the honest way out. For parity RAID, mdadm under LVM gives better recovery tools.

3. Thin pool

Thin pools suffer the most from an outage: at boot, thin_check finds the metadata inconsistent and LVM refuses:

1

Check of pool vg01/pool0 failed (status:1). Manual repair required!

The fix is what the message says, with the pool inactive:

1
2

lvconvert --repair vg01/pool0
vgchange -ay vg01

--repair rebuilds the metadata into a new LV and keeps the old one as pool0_meta0; once you confirm the thin volumes mount fine, lvremove vg01/pool0_meta0. A thin pool with a missing PV will not activate even in degraded mode; only partial remains, to copy.

4. Broken metadata (PVs present, VG “incomplete” or “unknown”)

1
2
3

vgcfgrestore --list vg01                                # files in /etc/lvm/archive with date and reason
vgcfgrestore -f /etc/lvm/archive/vg01_00042-1234567890.vg vg01
vgchange -ay vg01

Metadata only: if what is missing is a disk, restoring the configuration does not bring it back.

5. The disk is there, but LVM ignores it

On RHEL 9, Fedora, and derivatives LVM only looks at the devices listed in /etc/lvm/devices/system.devices. If the outage made a disk come back under another identifier (controller change, different WWID, cloned disk), LVM does not consider it even though lsblk shows it:

1
2
3
4

lvmdevices                          # current list
lvmdevices --adddev /dev/sdc        # add the device
vgimportdevices -a                  # or import every VG it finds
vgchange -ay

After activating

An outage breaks filesystems more often than LVM. Before mounting read-write:

1
2

fsck -n /dev/vg01/data        # ext4: look only
xfs_repair -n /dev/vg01/data  # xfs: look only

And if the result looks scary, mount ro, copy, and repair afterwards.

Traps

  • partial fixes nothing: what is missing reads as zeros or errors and any write there is lost. Mount read-only and copy.
  • Do not vgreduce --removemissing before copying. It is the last step, not the first.
  • /etc/lvm/backup and /etc/lvm/archive are gold and live on the same disk that can fail. Copy them off the machine now and then (vgcfgbackup -f /external/path/%s.vg).
  • In VMs the “power failure” is a forced stop; same recipe. And if what does not boot is GRUB itself with root on LVM, that is another problem.

References: man 8 vgchange, man 7 lvmthin, and man 8 lvmdevices.