Resize an Encrypted LUKs filesystem with LVM on Linux

There is a CentOS 6 server that needed additional diskspace. I had no idea, that this server had an encrypted filesystem for one of it’s mount points. I thought the worst for procedures, but I found this one article that worked and worked well.

The situation was a VM on an ESXi server contained a LVM mount called for example, /backup that needed diskspace. Following the usual process of adding a disk via VMware, then scanning the OS for changes without restarting the VM, then fdisk, pvcreate, vgextend, and lvextend, all went well as planned.


for HOST in $(ls /sys/class/scsi_host) ; do echo '- - -'>"/sys/class/scsi_host/$HOST/scan" ; done
fdisk -l | grep Disk
lsblk
# Note the -cu switch is used for CentOS6, not needed for CentOS7
fdisk -cu /dev/sdb
pvcreate /dev/sdb1
vgscan
vgextend vg_backup /dev/sdb1
lvscan
lvextend  /dev/vg_backup/lv_backup -l +100%FREE

It wasn’t until I attempted to resize the filesystem that I could not. I found several articles to determine if the filesystem is encrypted or not, but this tool seemed to be the cleanest approach and showed that the backup was sure enough en’crypt‘ed.

[root@backupserver ~]# dmsetup status | grep crypt
backup: 0 50311168 crypt

Following the instructions from the source cited below, I was able to continue with this process.


# Determine the mount
[root@backupserver ~]# mount | grep /backup
/dev/mapper/backup on /backup type ext4 (rw)
# Determine the status of the mount
[root@backupserver ~]# cryptsetup status /dev/mapper/backup
/dev/mapper/backup is active and is in use.
&nbsp; type:&nbsp; LUKS1
&nbsp; cipher:&nbsp; aes-cbc-essiv:sha256
&nbsp; keysize: 256 bits
&nbsp; device:&nbsp; /dev/mapper/vg_backup-lv_backup
&nbsp; offset:&nbsp; 4096 sectors
&nbsp; size:&nbsp;&nbsp;&nbsp; 50311168 sectors
&nbsp; mode:&nbsp;&nbsp;&nbsp; read/write
# Check the space for /backup ie. 24G
[root@backupserver ~]# df -ThP | grep backup
/dev/mapper/backup&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ext4&nbsp;&nbsp;&nbsp; 24G&nbsp;&nbsp; 19G&nbsp; 3.5G&nbsp; 85% /backup
# Is it available via volume group, yes +8G
[root@backupserver ~]# vgs | grep backup
&nbsp; vg_backup&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3&nbsp;&nbsp; 1&nbsp;&nbsp; 0 wz--n- 31.99g&nbsp;&nbsp;&nbsp; 0
# Is it available via logical volume, yes 8G
[root@backupserver ~]# lvs | grep backup
&nbsp; lv_backup vg_backup&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -wi-ao---- 31.99g
# Resize the LUKS encrypted mount
[root@backupserver ~]# cryptsetup resize /dev/mapper/backup
# Now resize the space as usual.
[root@backupserver ~]# resize2fs /dev/mapper/backup
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/mapper/backup is mounted on /backup; on-line resizing required
old desc_blocks = 2, new_desc_blocks = 2
Performing an on-line resize of /dev/mapper/backup to 8385024 (4k) blocks.
The filesystem on /dev/mapper/backup is now 8385024 blocks long.
# check it again. Note more space
[root@backupserver backup]# cryptsetup status /dev/mapper/backup
/dev/mapper/backup is active and is in use.
&nbsp; type:&nbsp; LUKS1
&nbsp; cipher:&nbsp; aes-cbc-essiv:sha256
&nbsp; keysize: 256 bits
&nbsp; device:&nbsp; /dev/mapper/vg_backup-lv_backup
&nbsp; offset:&nbsp; 4096 sectors
&nbsp; size:&nbsp;&nbsp;&nbsp; 67080192 sectors
&nbsp; mode:&nbsp;&nbsp;&nbsp; read/write
# Space is there.
[root@backupserver backup]# df -ThP | grep backup
/dev/mapper/backup&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ext4&nbsp;&nbsp;&nbsp; 32G&nbsp;&nbsp; 19G&nbsp;&nbsp; 11G&nbsp; 64% /backup

Finished, successfully.

Source(s)
http://rabexc.org/posts/resizing-filesystem