I recently found myself in a situation where a couple of VMs I run in my lab ran low on space. Normally this would not be an issue as one can always add extra capacity live and extend partitions and / or logical volumes and resize the filesystem on top but what does one need to do when you also throw luks encryption to the mix?
Worry not, luks has got you covered 🙂
Here’s my history log with output for the relevant commands:
#lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 40G 0 disk
├─sda1 8:1 0 1G 0 part /boot/efi
├─sda2 8:2 0 2G 0 part /boot
└─sda3 8:3 0 36.9G 0 part
└─dm_crypt-0 252:0 0 36.9G 0 crypt
└─ubuntu--vg-ubuntu--lv 252:1 0 36.9G 0 lvm /
sr0
11:0 1 2.6G 0 rom
... notice the new size ...
#lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 100G 0 disk
├─sda1 8:1 0 1G 0 part /boot/efi
├─sda2 8:2 0 2G 0 part /boot
└─sda3 8:3 0 36.9G 0 part
└─dm_crypt-0 252:0 0 36.9G 0 crypt
└─ubuntu--vg-ubuntu--lv 252:1 0 36.9G 0 lvm /
sr0 11:0 1 2.6G 0 rom
Run cfdisk on /dev/sda (in my case, adjust for your case) and resize the relevant partition (in my case /dev/sda3)
#lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 100G 0 disk
├─sda1 8:1 0 1G 0 part /boot/efi
├─sda2 8:2 0 2G 0 part /boot
└─sda3 8:3 0 96.9G 0 part
└─dm_crypt-0 252:0 0 36.9G 0 crypt
└─ubuntu--vg-ubuntu--lv 252:1 0 36.9G 0 lvm /
sr0
11:0 1 2.6G 0 rom
Now the magic command
#cryptsetup resize dm_crypt-0
#lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 100G 0 disk
├─sda1 8:1 0 1G 0 part /boot/efi
├─sda2 8:2 0 2G 0 part /boot
└─sda3 8:3 0 96.9G 0 part
└─dm_crypt-0 252:0 0 96.9G 0 crypt
└─ubuntu--vg-ubuntu--lv 252:1 0 36.9G 0 lvm /
sr0 11:0 1 2.6G 0 rom
#pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/dm_crypt-0 ubuntu-vg lvm2 a-- <36.93g 0
#pvresize /dev/mapper/dm_crypt-0
Physical volume "/dev/mapper/dm_crypt-0" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized
#pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/dm_crypt-0 ubuntu-vg lvm2 a-- <96.93g 60.00g
#vgs
VG #PV #LV #SN Attr VSize VFree
ubuntu-vg 1 1 0 wz--n- <96.93g 60.00g
#lvresize /dev/ubuntu-vg/ubuntu-lv -L+60g
Size of logical volume ubuntu-vg/ubuntu-lv changed from <36.93 GiB (9454 extents) to <96.93 GiB (24814 extents).
Logical volume ubuntu-vg/ubuntu-lv successfully resized.
#lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
ubuntu-lv ubuntu-vg -wi-ao---- <96.93g
And the last bit ... resizing the filesystem
#xfs_growfs /
meta-data=/dev/mapper/ubuntu--vg-ubuntu--lv isize=512 agcount=4, agsize=2420224 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=1
= reflink=1 bigtime=1 inobtcount=1 nrext64=0
data = bsize=4096 blocks=9680896, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=16384, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 9680896 to 25409536And there you have it … all the above commands were executed on a live system where there was no need for a reboot or start/stop. (in my case this happened inside a VM but will work on a physical server as well – the difference comes from how the extra capacity is added to it)
If you don’t feel comfortable doing this live on a production system (which should not be the case) you can always add the extra capacity inside the VM or physical machine, resize the partition(s) and stop/start or reboot the system to get luks to detect the capacity change and then proceed with resizing the logical volume(s) and/or filesystem(s)
Enjoy!