pvscan Not Finding Disk: Troubleshooting Guide

The email arrived at 07:42 on a Tuesday. A client’s file server had gone quiet overnight. The server rebooted the evening before for a routine kernel update, and when it came back, the OS looked fine. One thing was missing. The 4 TB data volume, the one holding six years of project archives, was not mounted.

I logged in and ran the usual first command.

df -h

No /data. I checked the logical volumes.

lvs

Nothing. Not even the volume group name in the output. My stomach dropped, because I already knew what the next command would say.

pvscan

There it was. The output showed only the system volume. The disk that should have been the physical volume underneath /data did not exist, as far as LVM was concerned.

Meanwhile lsblk showed the disk sitting right there. The kernel could see it. LVM could not. That gap between what the kernel knows and what LVM believes is the heart of every “pvscan not finding disk” problem, and it is almost always fixable without touching the data at all.

Why pvscan misses a disk it should see

LVM does not read disks directly. It works through a pipeline: kernel, udev, device mapper, then the LVM tools themselves. pvscan walks the block devices the kernel exposes, applies a filter, and reads the LVM metadata it finds on them.

Three things can break that pipeline:

1. The kernel does not see the disk. No udev event, no device node, nothing for LVM to scan.
2. LVM filters the device out. The device exists, but a rule in lvm.conf tells LVM to ignore it.
3. The metadata or cache is stale. LVM found the device before, then lost track of it.

I have seen all three in production. The second one, the filter, is by far the most common, and it is also the easiest to fix once you know where to look.

Step 1: confirm the kernel can see the disk

Start at the bottom of the stack. If the kernel does not know the disk exists, no LVM command will help you.

lsblk
blkid
dmesg | grep -iE 'sd|nvme|error' | tail -20

lsblk shows every block device the kernel exposes. If your disk appears here with its partition, the kernel layer is healthy and you can skip to Step 2. If it does not appear at all, the problem is physical or virtual, not LVM.

In virtualized environments this happens more often than you would think. A VMware or cloud disk gets detached, then reattached, and the guest never rescans its SCSI bus. The fix is a rescan, not a reboot.

echo "- - -" > /sys/class/scsi_host/host*/scan
partprobe

Run lsblk again. When the disk shows up, move to the next layer.

Step 2: check the LVM device filter

This is the one that bites. LVM ships with a default filter that accepts the obvious devices and rejects the rest. Somewhere in your lvm.conf, a filter rule can silently exclude the exact disk you need.

The filter lives in two places. filter is the main one. global_filter is applied earlier in the pipeline, before the full LVM stack starts, and it overrides everything. Backup tools, Proxmox installations, and multipath setups are notorious for writing restrictive global_filter rules that come back to haunt you months later.

Check what LVM is actually using right now:

lvmconfig devices filter
lvmconfig devices global_filter

A typical safe filter looks like this:

filter = [ "a|/dev/sd.*|", "a|/dev/nvme.*|", "a|/dev/vd.*|", "r|.*|" ]

Read it as allow all SCSI, NVMe, and virtio devices, then reject everything else. If your data disk is /dev/sdc, this filter passes it. But if someone tightened the filter to allow only sd[a-b], your /dev/sdc disappears from LVM entirely. The disk is there. The filter says no.

Here is the telltale symptom. pvscan reports fewer devices than lsblk, and the missing device follows a predictable name pattern, all sd* disks except that one, or everything under /dev/mapper/.

Fix the filter, then force LVM to re-read it:

pvscan --cache

No reboot needed. The device filter is read every time an LVM tool starts.

Step 3: refresh the LVM cache and udev

Modern LVM keeps device metadata in /etc/lvm/cache/.cache and runtime state under /run/lvm. A stale cache can hide a device that returned to the system after an outage or a hypervisor hiccup.

Refresh everything in the right order:

udevadm trigger
pvscan --cache
vgscan

pvscan --cache tells LVM to forget what it knew and rescan from scratch. vgscan rebuilds the volume group list from the metadata it finds. If your physical volume has a known UUID, you can search for it directly:

pvs --uuid | grep -i <partial-uuid>

The UUID does not change when a device name changes. That is your anchor when everything else moves.

Step 4: device renamed or behind multipath

Reboots shuffle device names. The disk that was /dev/sdb becomes /dev/sdc when another disk is added first, or when the kernel probes devices in a different order. LVM metadata records device paths, so a renamed device can make a volume group look broken even though the data is perfectly intact.

Check the persistent names:

ls -l /dev/disk/by-id/ | grep -i lvm

If the disk sits behind multipath, the physical volume lives under /dev/mapper/, and the filter from Step 2 must allow it. Multipath setups break more than any other configuration, because the default filter rejects /dev/mapper/.* and nobody notices until a path fails.

multipath -ll

Whatever name you find, remember this. LVM identifies physical volumes by UUID, not by path. A rename is a path problem, not a data problem.

The recovery sequence that follows

Once pvscan sees the disk again, the rest is mechanical. It is the same sequence I walked through in the LVM recovery case study, where a database server lost its data directory overnight.

pvscan
vgs
vgchange -ay <volume-group>
mount /dev/<volume-group>/<logical-volume> /data

Do not run fsck on the way. The filesystem was never the problem. The link between disk and volume group was broken, and you just fixed the link.

If pvscan still refuses to see the disk after all four steps, stop and think before doing anything destructive. Copy the LVM metadata from /etc/lvm/archive/ somewhere safe first. Then, and only then, consider vgcfgrestore or vgimportclone. Recovery is possible, but it deserves a calm head, not a rushed one.

Quick reference: matching symptoms to causes

Symptom	Likely cause	Fix
lsblk shows the disk, pvscan does not	Device filter excludes it	Edit filter/global_filter, run pvscan --cache
pvscan shows nothing after VM disk reattach	No SCSI rescan in guest	echo "- - -" > /sys/class/scsi_host/host*/scan
Disk renamed after reboot, VG looks broken	Device path changed	Find by UUID with pvs --uuid, vgscan
Volume group exists but LV is inactive	PV was missing, VG deactivated	vgchange -ay <vg> then mount
pvscan hangs or scans forever	lvmetad or cache out of sync	pvscan --cache, udevadm trigger

Prevention: keep LVM findable

Every case I have walked through shared the same root pattern. Nobody expected the disk to disappear, so nobody had a checklist for bringing it back. A short list prevents most of the drama:

1. Mount by UUID, never by /dev/sdX. The name changes. The UUID does not.
2. Document the LVM layout. Volume group names, physical volumes, and which disk is which. One page of notes saves an hour of guessing.
3. Review your filter rules. Every time a disk is added, ask whether the current filter would let LVM see it.
4. Monitor the layer, not just the space. df -h tells you the filesystem is full. pvs and vgs tell you a physical volume went missing. The second alarm is the one that matters.
5. Test the recovery, not just the backup. Detach a test disk in staging and run this sequence. The first time you do it should not be in production at 3 a.m.

The broader Linux survival skills, storage and process diagnosis included, are collected in my basic Linux for system administrators guide, and the server-side hardening that keeps an attacker from turning a storage outage into a breach is covered in Linux server hardening best practices.

FAQ from the field

Does a missing disk mean my data is gone? Almost never. The data sits on the disk, and the disk is usually fine. LVM simply cannot see it, so it deactivates the volume group to protect integrity. Find the reason it cannot see the disk and the volume comes back.

Why would someone tighten the filter in the first place? To stop LVM from claiming disks it should not touch, like multipath maps, Ceph devices, or removable media. The intent is good. The execution is fragile, because a later disk addition can fall outside the rules.

Do I need to reboot after fixing the filter? No. The filter is read on every LVM command. pvscan --cache is enough to make LVM re-evaluate every device.

What if the disk really died? Then lsblk will not show it, dmesg will be full of I/O errors, and recovery moves from LVM commands to hardware replacement and pvmove on a healthy replacement. That scenario is the one covered in the LVM case study mentioned earlier.

Closing

The client’s file server came back the same morning. The fix was one line in the device filter and a pvscan --cache to make LVM forget its bad memory. Six years of archives, untouched, never lost.

The lesson stuck with me harder than the command. LVM does not hide your data to punish you. It hides it because it cannot see the disk, and the reason it cannot see the disk is almost always a small, discoverable, fixable thing. Work the pipeline from the kernel up, and the disk always shows up eventually.

---

I hope this pvscan troubleshooting guide helps you bring your volumes back faster than I did the first time.