When expanding an LVM physical volume (PV) after increasing the underlying block device size, you might encounter situations where pvresize fails to recognize the additional space. The system appears stuck with the original PV size despite the partition showing available space in fdisk.

First confirm the actual disk geometry using low-level tools:

# Check block device size at kernel level
blockdev --getsize64 /dev/vda2

# Verify partition table
parted /dev/vda unit s print

Most commonly, this occurs when the partition table hasn't been properly updated after storage expansion. The kernel continues to see the old partition boundaries until refreshed.

Here's the full workflow to properly extend an LVM PV:

# 1. Rescan the device at SCSI/block level
echo 1 > /sys/class/block/vda/device/rescan

# 2. Update partition table (non-destructive)
parted /dev/vda resizepart 2 100%

# 3. Re-read partition table 
partprobe /dev/vda

# 4. Force PV metadata refresh
pvresize --debug /dev/vda2

# 5. Verify the new space
pvdisplay /dev/vda2

If the issue persists, check for these less common scenarios:

• Filesystem signatures at the end of the original partition
• LVM metadata alignment issues (use pvresize --setphysicalvolumesize)
• Virtual machine storage expansion not properly communicated to the guest OS

For AWS EBS volumes attached to Linux instances:

# After modifying volume size in AWS console
sudo growpart /dev/xvda 2
sudo pvresize /dev/xvda2
sudo lvextend -l +100%FREE /dev/mapper/vg-root
sudo xfs_growfs /  # For XFS filesystems

To avoid this situation:

1. Always verify both the partition and filesystem layers after storage operations
2. Use lsblk --fs to see complete storage hierarchy
3. Consider using whole-disk PVs instead of partitions when possible

You've just extended your block device partition, but pvresize stubbornly refuses to acknowledge the extra space. This frustrating scenario occurs when the underlying disk geometry changes but the LVM metadata isn't properly updated. Let's break down what's happening under the hood.

First, confirm your actual partition size matches what LVM sees:

# Check physical disk and partition layout
lsblk
fdisk -l /dev/vda

# Verify PV information
pvdisplay /dev/vda2
pvscan

After resizing a partition, the Linux kernel may not automatically recognize the change. The key commands many miss are:

# Ensure kernel sees the new partition table
partprobe /dev/vda
blockdev --rereadpt /dev/vda

# Alternative method for older systems
echo 1 > /sys/block/vda/device/rescan

When standard pvresize fails, try these advanced techniques:

# Force metadata refresh with debug output
pvresize -vvv /dev/vda2

# Alternative approach using pvcreate
pvcreate --uuid tehZic-5vfN-rsrm-B8lN-lpgc-yQT1-ioH1V0 --restorefile /etc/lvm/backup/debian /dev/vda2
vgcfgrestore debian

As a last resort, you can recreate the PV metadata while preserving your VG:

# Backup your VG configuration first!
vgcfgbackup -f /root/vg_backup debian

# Remove and recreate the PV
pvremove /dev/vda2
pvcreate /dev/vda2
vgextend debian /dev/vda2

For smoother LVM operations in the future:

• Always run partprobe after partition changes
• Use lsblk to verify kernel visibility before LVM commands
• Consider using parted instead of fdisk for resizing operations