I want to remove my swap LVM LV out of its current LUKS container, and have it unencrypted instead.

I want to avoid something like gparted to have control of every step in the process.

  1. After doing lvremove on the swap LV and pvmove to get contiguous PV extents, how do I work out the minimum size to pass to pvresize?

  2. Given the now shrunken PV, how do I work out exactly how many sectors or MiB the LUKS container should contain, so I can shrink the LUKS partition to match?

  3. Am I right in thinking that a LUKS container doesn't have a length, and is shrunk by simply shrinking the partition?

  4. Is there a way of checking at the LVM level that the final extents of the PV are still accessible, ie, that they are indeed inside the shrunken partition's addressable sectors?

  • Doesn't pvresize use the smallest possible size by default?
    – ajeh
    Commented Aug 3, 2018 at 18:30

2 Answers 2



From the man page:

pvresize will refuse to shrink PhysicalVolume if it has allocated extents after where its new end would be.

So you could just do this by trial & error. Actually pvresize will tell you part of it:

/dev/dm-7: cannot resize to 17564 extents as 18620 are allocated.

To determine the exact size, you need to know the PE size (e.g. 4MiB) and 1st PE offset (e.g. 1MiB). And of course, the number of the last allocated extent.

pvs -o pv_name,pe_start,vg_extent_size,seg_pe_ranges

So the total size could for example be 1MiB (1st PE) + 18620 * 4MiB (PE size).


You need to know the LUKS header size / data offset. Usually this is 4096 sectors, i.e. 2MiB. Check with cryptsetup luksDump, Payload offset.

So your new partition size is the LUKS Payload offset plus whatever size you resized the PV itself to.


Yes and no. LUKS doesn't keep the size in its metadata, so if you are going to close the LUKS container, or even reboot, then yes, it will just use the size of the block device itself.

But for an online resize, you would need to set it with cryptsetup resize, to whatever size you used in pvresize.


I sometimes do this by passing the offending device in read-only mode to a qemu/KVM instance, running some Linux rescue system. It's hard to check on the host (with, say, a read-only loop device) because LVM doesn't like to see duplicate PV UUIDs, or VG/LV names. LVM will refuse to activate, should the PV turn out to be smaller than expected.

  • Excellent, thank you. Note for self and others: cryptsetup resize --size takes 512-byte sectors, so multiply PV MBs by 2048.
    – Tom Hale
    Commented Aug 4, 2018 at 3:43
  • Wouldn't it be best practice to use pvresize --setphysicalvolumesize <smaller-partition-size>M? (The units are always powers of 2, regardless of capitalisation). Would you consider adding this to your answer?
    – Tom Hale
    Commented Aug 4, 2018 at 4:10
  • Always use -v with cryptsetup, or be sure to check its exit status.
    – Tom Hale
    Commented Aug 4, 2018 at 4:14
  • Get PE size from: sudo pvdisplay /dev/mapper/<NAME>
    – Tom Hale
    Commented Aug 5, 2018 at 5:21

Consider pvshrink which does most of the calculations in frostschutz's answer, and has a --test mode which doesn't make any changes.

Not the answer you're looking for? Browse other questions tagged .