How to resize Logical Volume that is encrypted with LUKS

Question

I'm trying to understand what is the proper way to resize my logical volumes (I want to shrink one and extend other one without adding any additional pv).

As far as I understand, according to this link:lvm guide by Chris, and additional sources I read about VLM, The proper way is as following:

1. Shrink the file system of lv #1
2. Shrink the lv #1 size
3. extend the lv #2 size
4. fix/extend the file system of lv #2

In addition, I understand the architecture of the LVM (PV's that mapped to VG that mapped to LV's).

My gap is:

1. If I don't add any additional PV to the scheme, does I need to be care about the LUKS? Or shall this process, as long as the PV is not change, is doesn't effect the LUKS?
2. Does the partition, the PV, is encrypted as a unit or each lv encrypted by its own?
3. In my case, I want to resize /tmp and /var Based on my architecture, do I need to boot from disk on key and do it from livecd or can I do it from the host itself?

pvscan

PV /dev/nvme0n1p3   VG fedora_localhost-live   lvm2 [475.35 GiB / 4.00 MiB free]
  Total: 1 [475.35 GiB] / in use: 1 [475.35 GiB] / in no VG: 0 [0   ]

vgscan

Found volume group "fedora_localhost-live" using metadata type lvm2

lvscan

  ACTIVE            '/dev/fedora_localhost-live/root' [70.00 GiB] inherit
  ACTIVE            '/dev/fedora_localhost-live/home' [<348.35 GiB] inherit
  ACTIVE            '/dev/fedora_localhost-live/swap' [38.00 GiB] inherit
  ACTIVE            '/dev/fedora_localhost-live/var' [4.00 GiB] inherit
  ACTIVE            '/dev/fedora_localhost-live/tmp' [15.00 GiB] inherit

df -h

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         16G     0   16G   0% /dev
tmpfs            16G  124M   16G   1% /dev/shm
tmpfs            16G  2.4M   16G   1% /run
/dev/dm-2        69G  9.9G   56G  16% /
/dev/nvme0n1p2  976M  232M  678M  26% /boot
/dev/nvme0n1p1  599M   30M  570M   5% /boot/efi
/dev/sda1       826G  783G   44G  95% /mnt/workspace_HDD
/dev/dm-7       3.9G  3.0G  720M  81% /var
/dev/loop0      182M  182M     0 100% /var/lib/snapd/snap/spotify/36
/dev/loop1       90M   90M     0 100% /var/lib/snapd/snap/core/8268
/dev/dm-8       342G  3.8G  321G   2% /home
/dev/dm-9        15G   41M   14G   1% /tmp
tmpfs           3.2G  112K  3.2G   1% /run/user/1000

In addition, I will be happy to understand the mapping that Fedora did and with which path to use for the commands: lvreduce / lvexdend / resize2fs: I think I understand why each lv has "two" paths, one is for the logical volume and the second is the decrypted volume.

ls -l /dev/mapper/

total 0
crw-------. 1 root root 10, 236 Jan 18 18:10 control
lrwxrwxrwx. 1 root root       7 Jan 18 18:10 fedora_localhost--live-home -> ../dm-4
lrwxrwxrwx. 1 root root       7 Jan 18 18:10 fedora_localhost--live-root -> ../dm-0
lrwxrwxrwx. 1 root root       7 Jan 18 18:10 fedora_localhost--live-swap -> ../dm-1
lrwxrwxrwx. 1 root root       7 Jan 18 18:10 fedora_localhost--live-tmp -> ../dm-6
lrwxrwxrwx. 1 root root       7 Jan 18 18:10 fedora_localhost--live-var -> ../dm-5
lrwxrwxrwx. 1 root root       7 Jan 18 18:10 luks-3b985124-40c1-450b-8740-da85a6083aa5 -> ../dm-8
lrwxrwxrwx. 1 root root       7 Jan 18 18:10 luks-7791d468-c71b-4603-942e-5a30efc8d3fd -> ../dm-9
lrwxrwxrwx. 1 root root       7 Jan 18 18:10 luks-d695f07d-2017-4e36-a792-851cb23d26d1 -> ../dm-2
lrwxrwxrwx. 1 root root       7 Jan 18 18:10 luks-e0d65c04-dfdb-4f61-8b2f-0b76127eaf8e -> ../dm-3
lrwxrwxrwx. 1 root root       7 Jan 18 18:10 luks-f5400a56-7498-4a73-ab1b-40c331e74d6f -> ../dm-7

and last command: lsblk

NAME                                            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0                                             7:0    0 181.1M  1 loop  /var/lib/snapd/snap/spotify/36
loop1                                             7:1    0  89.1M  1 loop  /var/lib/snapd/snap/core/8268
sda                                               8:0    0 953.9G  0 disk  
├─sda1                                            8:1    0 825.9G  0 part  /mnt/workspace_HHD
└─sda2                                            8:2    0   128G  0 part  
sr0                                              11:0    1  1024M  0 rom   
nvme0n1                                         259:0    0   477G  0 disk  
├─nvme0n1p1                                     259:1    0   600M  0 part  /boot/efi
├─nvme0n1p2                                     259:2    0     1G  0 part  /boot
└─nvme0n1p3                                     259:3    0 475.4G  0 part  
  ├─fedora_localhost--live-root                 253:0    0    70G  0 lvm   
  │ └─luks-d695f07d-2017-4e36-a792-851cb23d26d1 253:2    0    70G  0 crypt /
  ├─fedora_localhost--live-swap                 253:1    0    38G  0 lvm   
  │ └─luks-e0d65c04-dfdb-4f61-8b2f-0b76127eaf8e 253:3    0    38G  0 crypt [SWAP]
  ├─fedora_localhost--live-home                 253:4    0 348.4G  0 lvm   
  │ └─luks-3b985124-40c1-450b-8740-da85a6083aa5 253:8    0 348.3G  0 crypt /home
  ├─fedora_localhost--live-var                  253:5    0     4G  0 lvm   
  │ └─luks-f5400a56-7498-4a73-ab1b-40c331e74d6f 253:7    0     4G  0 crypt /var
  └─fedora_localhost--live-tmp                  253:6    0    15G  0 lvm   
    └─luks-7791d468-c71b-4603-942e-5a30efc8d3fd 253:9    0    15G  0 crypt /tmp

According to the output of lsblk it looks like each lv is encrypted as a unit, or do I wrong?

I understand how LVM works without LUKS, I think I understand how LUKS works without LVM. But I don't understand how they work together and what is the relation between them and how to, practically, resize a logical volume when luks is exist as in my situation.

Thanks.

Answer 1

You have LUKS inside LVM, so yes, you have to care about LUKS. lvresize --resizefs does not work here, so you have to do it manually.

Without LUKS, the size of LV and size of filesystem would be identical. With LUKS, you also have to consider the LUKS header. This header is several MiBs large so the filesystem has to be a few MiBs smaller or the logical volume a few MiBs larger respectively. So there is enough space for both the LUKS header, and the filesystem.

Suppose you want to shrink /home to 100G and the LUKS header size is 16M (compare cryptsetup luksDump, payload or data offset).

If you make the /home filesystem 100G, the LV will have to be 100G+16M in size.

Alternatively make the filesystem 100G-16M in size, so the LV can be 100G sharp.

So, for example:

# shrink the filesystem first
resize2fs /dev/mapper/luks-home 100G

# shrink the LUKS
cryptsetup resize --device-size 100G luks-home

# shrink the LV
lvresize -L102416M lvm/home # 100G = 102400M + 16M

If you are unsure about the math, it's also common to shrink the filesystem even further (e.g. 99G instead of 100G) to add a safety margin, then grow it back to "real" device size later:

# after resizing the LV, grow LUKS and filesystem to device size
cryptsetup resize luks-home
resize2fs /dev/mapper/luks-home

Unlike traditional partitioning, with LVM there's no reason to use all available space right away. If your LVs were more reasonably sized, you'd have plenty of free LVM space to grow filesystems as needed, without having to go through a troublesome shrink process first.

Answer 2

It took me quite long, but after a few trails and errors on VM (I manage to destroyed a few machines before it works - so practice before you do it on the real system) and great help I got here, I manage to reduce the LV with scheme luks over lvm as follow:

1. Launch live-CD and enter rescue mode

2. Decrypt partition

   cryptsetup open /dev/mapper/fedora_localhost--live-tmp tmpCrypt

3. Shrink filesystem

   resize2fs /dev/mapper/tmpcrypt 6G
   

4. Close LUKS partition

   cryptsetup close /dev/mapper/tmpCrypt
   

5. Shrink LUKS header

   cryptsetup resize /dev/mapper/fedora_localhost--live-tmp
   

6. Shrink LV size (crypt size + 16M for LUKS header size = 6144+16)

   sudo lvreduce -L 6160M /dev/mapper/fedora_localhost--live-tmp
   

7. Resize LUKS again

   cryptsetup resize /dev/mapper/fedora_localhost--live-tmp
   

8. Decrypt partition

   cryptsetup open /dev/mapper/fedora_localhost--live-tmp tmpCrypt
   

9. Resize again the filesystem

   sudo resize2fs /dev/mapper/tmpCrypt
   

*Note: as much as I noticed, steps 8 and 9 are not mandatory - but I do them just to validate the filesystem before I reboot the system.