A logical volume that should be serving data shows as inactive. In lvs output, lv_attr position 5 is - where you expect a. No device-mapper table is loaded, no /dev/dm-N device exists, and nothing can mount, open, or write to that LV. Applications see a missing block device, and if this LV backs root or a critical service, the system may not have booted properly.

lvchange -ay is the standard activation command, but it can fail for several distinct reasons. With thin snapshots that carry the activation skip flag, lvchange -ay can even exit 0 without activating the LV. Always verify with dmsetup ls or lvs that the LV actually transitioned to active state.

What this means

When lv_attr position 5 shows -, the LV exists in LVM metadata on disk but has no corresponding device-mapper table loaded in the kernel. The kernel cannot route I/O to the underlying physical extents. The LV is metadata only, not a usable block device.

Other values in position 5:

  • a = active (device-mapper table loaded, /dev/dm-N exists)
  • s = suspended (I/O is blocked, processes touching this device are in D state)
  • I = invalid snapshot (COW exception store overflowed, snapshot is dead)
  • i = inactive with table (table exists but device is not mapped)

A suspended state (s) is different from inactive. Suspended means the dm table is loaded but I/O is frozen. This is normal during resize or reshape operations (sub-second), but if it persists for minutes, a kernel-level issue is blocking the resume.

Some LVs are intentionally inactive and should not trigger alerts: templates, backup snapshots, and thin pool internal LVs (tmeta, tdata). Thin pool internal LVs are managed as part of the pool and should not be activated independently.

flowchart TD
    A["LV inactive
(lv_attr pos 5 = '-')"] --> B{"PV missing?"}
    B -->|"Yes"| C["Linear/striped: data inaccessible
RAID: degraded mode possible"]
    B -->|"No"| D{"vgck passes?"}
    D -->|"No"| E["Metadata corruption
Restore from archive"]
    D -->|"Yes"| F{"Thin pool LV?"}
    F -->|"Yes"| G["tmeta/tdata
ordering issue"]
    F -->|"No"| H{"Thin snapshot
with k flag?"}
    H -->|"Yes"| I["Use lvchange -ay -K"]
    H -->|"No"| J["Activation filter
or boot autoactivation"]

Common causes

CauseWhat it looks likeFirst thing to check
Missing PV dependencyLV health shows p in lv_attr position 9; pvs shows [unknown] devicepvs -o pv_name,vg_name,pv_attr,pv_missing
Metadata corruptionvgck returns non-zero; multiple LVs in the same VG fail to activatevgck -v <vgname>
Autoactivation failure at bootSystem boots to emergency mode or missing mount points; LVs inactive after rebootjournalctl -u lvm2-pvscan@*
Activation skip flag (thin snapshots)lv_attr position 10 shows k; lvchange -ay exits 0 but LV stays inactivelvs -o lv_name,lv_attr (look at position 10)
Thin pool internal LV orderingError: “Activation of logical volume is prohibited while tdata is active”lvs -a -o lv_name,lv_attr,lv_active
Activation filter in lvm.confError: “Not activating since it does not pass activation filter”volume_list and auto_activation_volume_list in /etc/lvm/lvm.conf
Clustered lock contentionlvchange -ay hangs or fails with lvmlockdlvmlockctl -i or dlm_tool ls

Quick checks

All of these are read-only and safe to run at any time:

# LV activation state (position 5 of lv_attr)
lvs -o lv_name,vg_name,lv_attr,lv_active

# Verify device-mapper has the device loaded
dmsetup ls | grep <vgname>-<lvname>

# Check for missing PVs
pvs -o pv_name,vg_name,pv_attr,pv_missing

# VG partial status (position 4 of vg_attr shows 'p' if partial)
vgs -o vg_name,vg_attr,vg_missing_pv_count

# VG metadata consistency
vgck -v <vgname>

# Suspended dm devices (should be transient only)
dmsetup info -c -o name,suspended

# Activation errors from the journal
journalctl -u lvm2-pvscan@* --no-pager -n 50

# D-state processes stuck on dm I/O
ps aux | awk '$8 ~ /D/'

# lvm.conf activation filters
grep -E 'volume_list|auto_activation_volume_list' /etc/lvm/lvm.conf

# Thin snapshot activation skip flag (position 10 = 'k')
lvs -o lv_name,lv_attr,origin

How to diagnose it

Step 1: Confirm the LV is actually inactive

lvs -o lv_name,vg_name,lv_attr,lv_active <vgname>/<lvname>
dmsetup ls | grep <vgname>-<lvname>

If lv_attr position 5 is a but dmsetup ls does not show the device, you have a kernel/userspace desync. LVM metadata says active but the kernel device-mapper table is not loaded. This is rare but can happen after a partial table load failure.

Step 2: Check for missing PVs

pvs -o pv_name,vg_name,pv_attr,pv_missing
vgs -o vg_name,vg_attr,vg_missing_pv_count

A missing PV is the most common reason an LV will not activate. If the VG is partial (p in vg_attr position 4), any linear or striped LV with extents on the missing PV cannot be activated. RAID LVs may activate in degraded mode.

Check dmesg for the underlying cause:

dmesg | grep -i 'I/O error\|offline\|not ready\|device not found' | tail -30

Step 3: Check thin pool internal LV state

If the inactive LV is a thin pool (or a thin volume whose pool is inactive), check the internal LVs:

lvs -a -o lv_name,lv_attr,lv_active,pool_lv <vgname>

Thin pools have internal tdata and tmeta LVs. If these are in an inconsistent state (one active, one not), the pool cannot activate. The error typically reads: “Activation of logical volume is prohibited while logical volume _tdata is active.”

Step 4: Check for the activation skip flag

Thin snapshot LVs are created with an activation skip flag (k in lv_attr position 10). lvchange -ay without -K will silently skip activation of these LVs:

lvs -o lv_name,lv_attr <vgname>
# Position 10 = 'k' means skip activation is set

Step 5: Attempt activation and capture the error

lvchange -ay -v <vgname>/<lvname> 2>&1

The error message from lvchange is your primary diagnostic. Common messages:

  • “Couldn’t find device with uuid”: missing PV
  • “Activation of logical volume is prohibited while…”: thin pool ordering issue
  • “Not activating since it does not pass activation filter”: volume_list filter
  • Metadata read errors: corruption

Step 6: Verify with dmsetup, not exit code

dmsetup ls | grep <vgname>-<lvname>
dmsetup info <vgname>-<lvname>

lvchange can return exit code 0 when the activation skip flag causes it to skip an LV. Always verify the dm device exists.

Metrics and signals to monitor

SignalWhy it mattersWarning sign
LV activation state (lv_attr position 5)Directly tells you whether the LV is usable- where a is expected
PV accessibilityMissing PV prevents activation of dependent LVsPV shows [unknown] or pv_missing set
VG metadata consistency (vgck)Corruption can prevent all LVs in the VG from activatingNon-zero exit code
LV health status (lv_attr position 9)p indicates missing PV dependencyAny non-- value
dm device suspended statePersistent suspension blocks all I/OSUSPENDED for more than a few seconds
D-state process countProcesses stuck on dm I/OGrowing count with dm device in stack
LVM command execution timeSlow commands indicate lock contention or device problemslvs or pvs taking more than a few seconds

Fixes

Missing PV preventing activation

If the PV is genuinely gone (disk failure, SAN LUN removed), linear and striped LVs with extents on that PV cannot be recovered. The data on those extents is lost.

For RAID LVs, activate in degraded mode:

# Activate a RAID LV with one missing PV (degraded mode)
lvchange -ay --activationmode degraded <vgname>/<lvname>

--activationmode has three values:

  • complete (default): no missing PVs allowed, most restrictive
  • degraded: allows RAID LVs to activate with missing PVs at reduced redundancy
  • partial: allows any LV to activate with missing PVs, for recovery only

For recovery scenarios where you need to access a linear LV despite a missing PV:

# WARNING: partial activation may return I/O errors for extents on the missing PV.
# Data on the missing PV is still inaccessible. Use only for recovery.
lvchange -ay --activationmode partial <vgname>/<lvname>

Once the PV issue is resolved (disk replaced, SAN LUN re-presented), verify the PV is back and the VG is no longer partial:

pvs -o pv_name,vg_name,pv_attr
vgs -o vg_name,vg_attr

Thin pool internal LV ordering

When activation fails with “Activation of logical volume is prohibited while logical volume _tdata is active,” the internal LVs are in an inconsistent state. Deactivate the pool and its internals, then reactivate:

# Deactivate the pool and all its internal LVs
lvchange -an <vgname>/<poolname>

# Reactivate the VG to ensure correct ordering
vgchange -ay <vgname>

If thin_check is timing out during activation (large pools can take 5-30 seconds to load and validate metadata), verify the pool metadata is not corrupted:

# Deactivate the pool first
lvchange -an <vgname>/<poolname>

# Check metadata integrity
thin_check /dev/mapper/<vgname>-<poolname>_tmeta

Activation skip flag on thin snapshots

Thin snapshots have the k flag by default. Activate with -K (--ignoreactivationskip):

lvchange -ay -K <vgname>/<snapshotname>

Activation filter blocking autoactivation

If the error is “Not activating since it does not pass activation filter,” check lvm.conf:

grep -E 'volume_list|auto_activation_volume_list' /etc/lvm/lvm.conf

If volume_list or auto_activation_volume_list is defined, only matching VG or LV tags will be activated. An empty auto_activation_volume_list means no LVs are autoactivated. If this list is too restrictive, boot-time activation fails silently.

The volume_list filter is distinct from devices/global_filter. The activation filter controls which LVs are activated. The device filter controls which block devices LVM scans.

Boot-time autoactivation failure

Modern LVM2 (2.03.x) uses event-based autoactivation. When event_activation=1 (the default), lvm2-activation-generator exits without generating static systemd units. Instead, udev rules trigger pvscan --cache -aay when PVs appear.

If boot activation fails:

# Check what autoactivation did during boot
journalctl -u lvm2-pvscan@* --no-pager -n 100

# Check if event-based activation is configured
grep event_activation /etc/lvm/lvm.conf

# Manually trigger activation
vgchange -ay

Common boot-time causes:

  • initramfs not rebuilt after LVM configuration changes (dracut -f or update-initramfs -u)
  • iSCSI or multipath not ready when activation runs (PVs not yet visible)
  • global_filter in lvm.conf too restrictive, excluding the PV device
  • thin_check timing out during boot (large pools loading slowly)

Clustered lock contention

In clustered LVM (lvmlockd with sanlock or DLM), activation requires acquiring a lock. If the lock manager is slow or contention is high, lvchange -ay may fail or hang.

# Check lock state
lvmlockctl -i

# For DLM-based setups
dlm_tool ls

lvmlockd uses lock retries rather than queueing. High contention may require tuning retry settings in lvm.conf.

Metadata corruption

If vgck reports metadata inconsistency, activation may fail across multiple LVs in the VG. Recovery uses archived metadata:

# List available archives
vgcfgrestore --list <vgname>

# Review recent archives
ls -lt /etc/lvm/archive/<vgname>* | head -10

# Restore from a known-good archive
# WARNING: this overwrites current metadata. Only use when corruption is confirmed.
# vgcfgrestore -f /etc/lvm/archive/<vgname>_<timestamp>.vg <vgname>

Only restore metadata after confirming the current state is unrecoverable. If the corruption is from a bad disk sector in the metadata area, replacing the disk first is safer.

Prevention

  • Document which LVs should be active. Build a baseline map of expected active LVs and their mount points. Alerting on unexpected inactive state requires knowing what “expected” means for each host.
  • Verify autoactivation after every initramfs or LVM config change. Rebuild initramfs and reboot (or simulate activation in a maintenance window) before relying on it in production.
  • Audit lvm.conf filters regularly. Both volume_list (activation filter) and global_filter (device scan filter) can silently prevent activation. Review after any storage topology change.
  • Monitor vgck periodically. Metadata corruption caught early is recoverable from archives. Corruption caught during an incident is much harder to deal with.
  • Know your thin pool configuration. Whether internal LVs are in a consistent state, whether thin_check is timing out, and whether activation skip flags are set on snapshots are all things to verify before you need to activate in an emergency.
  • For clustered LVM, monitor lock manager health. lvmlockd or DLM/sanlock outages will block all activation. Build monitoring for the lock layer, not just LVM itself.

How Netdata helps

  • Per-second LV activation state collection through the LVM collector shows the exact moment an LV transitions from active to inactive, correlated with disk errors, process state changes, and boot sequence timing on the same timeline.
  • PV accessibility monitoring detects missing PVs within seconds and correlates the event with the LV activation state change, confirming whether the missing PV caused the inactive LV.
  • D-state process tracking surfaces processes stuck in uninterruptible sleep, the application-visible symptom of an inactive or suspended LV.
  • Disk I/O error correlation from kernel logs surfaces the underlying hardware or path failure that caused a PV to disappear, linking root cause to LVM-layer symptom in a single timeline.
  • LVM command execution timing detects when the LVM management plane itself is degraded. Slow lvs or pvs commands may indicate lock contention or device scanning problems blocking activation.