While it might be easier (safer) to create a new partition using any remaining space and then luksFormat, pvcreate, vgextend, lvextend... here's the steps that should accomplish what you're asking.
You'll need to verify and input your numbers because they very likely won't be the same.
Establishing a baseline (my current config):
Code:
[root@localhost ~]# fdisk -l /dev/vda ; lsblk ; pvs; vgs; lvs; grep root /etc/fstab; df -h /
Disk /dev/vda: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf9b4642b
Device Boot Start End Sectors Size Id Type
/dev/vda1 * 2048 1026047 1024000 500M 83 Linux
/dev/vda2 1026048 12582911 11556864 5.5G 5 Extended
/dev/vda5 1028096 12582911 11554816 5.5G 83 Linux
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 252:0 0 10G 0 disk
├─vda1 252:1 0 500M 0 part /boot
├─vda2 252:2 0 1K 0 part
└─vda5 252:5 0 5.5G 0 part
└─luks-60526c0a-611c-4f0e-a3bd-ed5ace1ee7fc 253:0 0 5.5G 0 crypt
├─kali--nusch-root 253:1 0 4.9G 0 lvm /
└─kali--nusch-swap 253:2 0 508M 0 lvm [SWAP]
PV VG Fmt Attr PSize PFree
/dev/mapper/luks-60526c0a-611c-4f0e-a3bd-ed5ace1ee7fc kali-nusch lvm2 a-- 5.50g 144.00m
VG #PV #LV #SN Attr VSize VFree
kali-nusch 1 2 0 wz--n- 5.50g 144.00m
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root kali-nusch -wi-ao---- 4.87g
swap kali-nusch -wi-ao---- 508.00m
/dev/mapper/kali--nusch-root / ext4 defaults,x-systemd.device-timeout=0 1 1
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/kali--nusch-root 4.7G 1.4G 3.2G 30% /
We can see that I have a 10GiB disk; using 12582911 of 20971520 sectors; leaving approximately 4GiB unallocated. Extended partition vda2 is consumed by logical partition vda5 which is encrypted using LUKS. The unlocked side, luks-60526c0a..., is a physical volume for volume group kali-nusch which contains 2 logical volumes (root & swap -- 4.9G & 508M, respectively). The root filesytem is formatted ext4 and, after a bit of overhead, provides approximately 4.7G usable space.
Given my configuration and your desired outcome, let's move on to resizing the partition(s) step.
First, we must remove the existing partitions (5,2).
Code:
[root@localhost ~]# fdisk /dev/vda
Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/vda: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf9b4642b
Device Boot Start End Sectors Size Id Type
/dev/vda1 * 2048 1026047 1024000 500M 83 Linux
/dev/vda2 1026048 12582911 11556864 5.5G 5 Extended
/dev/vda5 1028096 12582911 11554816 5.5G 83 Linux
Command (m for help): d
Partition number (1,2,5, default 5): 5
Partition 5 has been deleted.
Command (m for help): d
Partition number (1,2, default 2): 2
Partition 2 has been deleted.
Now that they've been removed, we'll use the starting sectors from the partition printed output above. Knowing that vda2 is an extended partition beginning at 1026048 and vda5 is a logical partition beginning at 1028096, let's recreate them using the unallocated space we've identified exists beyond their ending sector (12582911).
Code:
Command (m for help): n
Partition type
p primary (1 primary, 0 extended, 3 free)
e extended (container for logical partitions)
Select (default p): e
Partition number (2-4, default 2): 2
First sector (1026048-20971519, default 1026048): 1026048
Last sector, +sectors or +size{K,M,G,T,P} (1026048-20971519, default 20971519):
Created a new partition 2 of type 'Extended' and of size 9.5 GiB.
Command (m for help): n
Partition type
p primary (1 primary, 1 extended, 2 free)
l logical (numbered from 5)
Select (default p): l
Adding logical partition 5
First sector (1028096-20971519, default 1028096): 1028096
Last sector, +sectors or +size{K,M,G,T,P} (1028096-20971519, default 20971519):
Created a new partition 5 of type 'Linux' and of size 9.5 GiB.
Remember, as long as we are using at least or greater than the same sectors, we should be fine and the data remain intact. Let's confirm before we commit anything to disk by reviewing the changes we've made.
Code:
Command (m for help): p
Disk /dev/vda: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xf9b4642b
Device Boot Start End Sectors Size Id Type
/dev/vda1 * 2048 1026047 1024000 500M 83 Linux
/dev/vda2 1026048 20971519 19945472 9.5G 5 Extended
/dev/vda5 1028096 20971519 19943424 9.5G 83 Linux
Looks good to me. I'm now consuming approximately 9.5G versus previously 5.5G and I'm well beyond the previous ending sector of 12582911. Let's write out our changes and proceed.
Code:
Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).
[root@localhost ~]# reboot
NOTE: While tools exist to force the kernel to re-read the partitions, it is recommended to reboot since this is the disk that contains our root filesystem. There's many long thread discussions about this that I won't get in to here.
Once the reboot completes successfully it's time to move on to the next steps.
Depending on your distribution and version, resizing the luks device may not be necessary. I'm including it here for thoroughness.
Alright, on to resizing our LUKS device...
Code:
[root@localhost ~]# cryptsetup resize /dev/mapper/luks-60526c0a-611c-4f0e-a3bd-ed5ace1ee7fc
Let's take a moment to assess and verify where we are and what remains.
Code:
[root@localhost ~]# lsblk ; pvs; vgs; lvs
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 252:0 0 10G 0 disk
├─vda1 252:1 0 500M 0 part /boot
├─vda2 252:2 0 1K 0 part
└─vda5 252:5 0 9.5G 0 part
└─luks-60526c0a-611c-4f0e-a3bd-ed5ace1ee7fc 253:0 0 9.5G 0 crypt
├─kali--nusch-root 253:1 0 4.9G 0 lvm /
└─kali--nusch-swap 253:2 0 508M 0 lvm [SWAP]
PV VG Fmt Attr PSize PFree
/dev/mapper/luks-60526c0a-611c-4f0e-a3bd-ed5ace1ee7fc kali-nusch lvm2 a-- 5.50g 144.00m
VG #PV #LV #SN Attr VSize VFree
kali-nusch 1 2 0 wz--n- 5.50g 144.00m
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root kali-nusch -wi-ao---- 4.87g
swap kali-nusch -wi-ao---- 508.00m
From this output we can see that luks-60526c0a... is now approximately 9.5G, the physical volume still reports only approximately 5.50G which the volume group reflects. I'm going to move through these steps fairly quickly because, while they do carry some risk to your filesystem & data, they are quite common steps and quite robust these days.
Extend our physical volume & verify:
Code:
[root@localhost ~]# pvresize /dev/mapper/luks-60526c0a-611c-4f0e-a3bd-ed5ace1ee7fc
Physical volume "/dev/mapper/luks-60526c0a-611c-4f0e-a3bd-ed5ace1ee7fc" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
[root@localhost ~]# pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/luks-60526c0a-611c-4f0e-a3bd-ed5ace1ee7fc kali-nusch lvm2 a-- 9.50g 4.14g
[root@localhost ~]# vgs
VG #PV #LV #SN Attr VSize VFree
kali-nusch 1 2 0 wz--n- 9.50g 4.14g
Now that we have approximately 9.5G total in our volume group giving is approximately 4G free, let's move on to extending our logical volume (root) and then it's filesystem to wrap this up:
Code:
[root@localhost ~]# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root kali-nusch -wi-ao---- 4.87g
swap kali-nusch -wi-ao---- 508.00m
[root@localhost ~]# lvextend -L+3G kali-nusch/root
Size of logical volume kali-nusch/root changed from 4.87 GiB (1246 extents) to 7.87 GiB (2014 extents).
Logical volume root successfully resized
[root@localhost ~]# vgs; lvs; df -h /
VG #PV #LV #SN Attr VSize VFree
kali-nusch 1 2 0 wz--n- 9.50g 1.14g
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root kali-nusch -wi-ao---- 7.87g
swap kali-nusch -wi-ao---- 508.00m
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/kali--nusch-root 4.7G 1.4G 3.2G 30% /
While the logical volume has been increased by 3G (from nearly 5G to nearly 8G now), we still need to address the filesystem. Recall that we're using ext4 in this demonstration. If you're using a different filesystem you'll need to execute the appropriate command to resize that filesystem. For example, xfs uses xfs_growfs.
The last step:
Code:
[root@localhost ~]# resize2fs /dev/kali-nusch/root ; df -h /
resize2fs 1.42.11 (09-Jul-2014)
Filesystem at /dev/kali-nusch/root is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/kali-nusch/root is now 2062336 blocks long.
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/kali--nusch-root 7.7G 1.4G 6.0G 18% /
As you can see, we now have approximately 7.7G available on our root filesystem after the resize2fs completes compared to the approximately 4.7G we had at the beginning.
