LVM and LUKS – How to Increase LVM When Using LUKS2 on Debian Buster

clonezilladebiangpartedlukslvm

I'm running Debian Buster on a ThinkPad T420 which is equipped with a 250 GB SSD. Since I needed more disk space I used Clonezilla to clone my current Debian installation from the internal 250 GB SSD to a new 500 GB SSD connected via an USB to SATA adapter. Afterwards I replaced the 250 GB SSD with the 500 GB SSD and used GParted live to increase the size of the extended partition (/dev/sda2) and the LVM2 PV partition (/dev/sda5). Everything worked fine and the system is up and running again. Unfortunately, I cannot use the new space yet, because the root LVM also has to be resized:

user@debianbook:~$ lsblk
NAME                         MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                            8:0    0 465,8G  0 disk  
├─sda1                         8:1    0   243M  0 part  /boot
├─sda2                         8:2    0     1K  0 part  
└─sda5                         8:5    0 465,5G  0 part  
  └─sda5_crypt               254:0    0 465,5G  0 crypt 
    ├─user--deb--vg-root     254:1    0 204,3G  0 lvm   /
    └─user--deb--vg-swap_1   254:2    0   7,9G  0 lvm   [SWAP]

Which steps are necessary to increase the root LVM on /dev/sda5?

Best Answer

it's like Russian dolls: disk -> MBR partition scheme -> extended partition container -> logical partition -> LUKS -> PV -> VG -> LV-> filesystem. So the root filesystem isn't simply on /dev/sda5.

What you already did:

  • enlarge disk
  • enlarge extended partition container (/dev/sda2)
  • enlarge partition (/dev/sda5)

What's left:

  • LUKS: no special handling. metadata is at the start and thus LUKS isn't affected. LUKS (actually the device-mapper backend) already coped with the change in size. It's just that if the additional space wasn't zeroed inside LUKS (which is not a good idea for SSD endurance), the additional unused data will appear as random data there.

  • PV: (summary with pvs) while the potential space available to the PV increased, the PV must be told about it to actually use it. To occupy the whole space available no special option is needed to pvresize, as described in the manual:

    Expand a PV after enlarging the partition.

    pvresize /dev/sda1

    For your case:

    pvresize /dev/mapper/sda5_crypt

  • VG: (summary with vgs) nothing to do, VG inherits its available size from the PV(s) it uses so appears larger right after the PV was made larger. VG is a LVM2 abstraction not having a visible direct device mapper counterpart.

  • LV: (summary with lvs) the generic command is lvresize but better use lvextend which can only make it larger for safety. You can tell it to use as additional space the whole free space available (but see the filesystem part before doing it):

    lvextend -l +100%FREE user-deb-vg/root

  • filesystem: now it has more available space it can be enlarged too.

    As it's Debian's default, I'm assuming EXT4 was used here. As / is already mounted, this has to be done in online mode (meaning kernel's filesystem driver must be involved) which is supported by the EXT4 filesystem (and a few others). To enlarge to the available space provided by the LV, again no specific size option is needed:

    resize2fs /dev/mapper/user--deb--vg-root

    But actually the two last steps (LV+FS) can be combined in a single command using here:

    lvextend --resizefs -l +100%FREE user-deb-vg/root

    which has the advantage of autodetecting the filesystem and running the right command for the right filesystem.

You don't have to use the whole available size. You could choose +50%FREE to leave ~ 130GB as reserve, especially if you want to create a separate filesystem later (in an additional LV).

Related Question