LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices


Reply
  Search this Thread
Old 05-19-2015, 09:58 AM   #1
nusch
LQ Newbie
 
Registered: Feb 2009
Posts: 14

Rep: Reputation: 0
Resize LVM insize luks


I have following setup:
/dev/sda1 - boot
/dev/sda2 - extended
/dev/sda5 - LUKS encrypted

after cryptsetup /dev/sda5 crypt1:
i have PV /dev/mapper/crypt1

VG kali-nusch

and LV /dev/kali-nusch/root

I want to increase size of root logical volume.

What stops me is first step - need to increase size of luks encrypted PV before resiszing vulume inside it. Standard tools like fdisk and parted don't know type and refuse to extend. How it should be correctly done without deleting partitions and moving data?
 
Old 05-19-2015, 07:03 PM   #2
rayfordj
Member
 
Registered: Feb 2008
Location: Texas
Distribution: Fedora, RHEL, CentOS
Posts: 488

Rep: Reputation: 78
Any time dealing with data/filesystem/disk manipulation, it is encouraged to have a [verified] backup on external / disconnected media from which to restore any important configuration or user data should a problem be encountered.


You'll need to...
- increase sda2 (extended) to use all available disk space
- increase sda5 (logical) within sda2 (extended) to the size you wish (or all available)
- use cryptsetup command to extend (resize) your LUKS partition
- use vgextend to increase your VG size if it wasn't picked up after a vgscan of the grown unlocked LUKS device
- use lvextend to increase your root LV to the desired size within available storage


This may mean deleting existing partitions and recreating them. As long as you get the correct starting sector and the ending sector is equal-to or greater-than the previous ending sector when (re-)creating partitions this shouldn't pose a problem.
 
Old 05-20-2015, 03:17 AM   #3
nusch
LQ Newbie
 
Registered: Feb 2009
Posts: 14

Original Poster
Rep: Reputation: 0
Exactly that's I want to do. The problem is with step 2 "increase sda5 (logical) within sda2 (extended) to the size you wish (or all available)" What command should I use ? Partition type is 83(ext) but it's luks encrypted PVM not ext, fdisk refuses to change size of it.
 
Old 05-21-2015, 08:06 AM   #4
rayfordj
Member
 
Registered: Feb 2008
Location: Texas
Distribution: Fedora, RHEL, CentOS
Posts: 488

Rep: Reputation: 78
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.
 
2 members found this post helpful.
Old 05-21-2015, 08:10 AM   #5
nusch
LQ Newbie
 
Registered: Feb 2009
Posts: 14

Original Poster
Rep: Reputation: 0
Thanks for your help, problem solved.
 
Old 05-21-2015, 08:44 AM   #6
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 17,916

Rep: Reputation: 2852Reputation: 2852Reputation: 2852Reputation: 2852Reputation: 2852Reputation: 2852Reputation: 2852Reputation: 2852Reputation: 2852Reputation: 2852Reputation: 2852
Awesome answer @rayfordj.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Lvm+luks siddartha Linux - Newbie 1 01-10-2013 09:18 PM
LUKS on LVM musiqdefunk Linux - Newbie 3 08-11-2012 05:07 AM
Luks/Lvm after dd duplication brodo Slackware 10 03-12-2009 03:56 PM
Resize ext4 partition with LUKS encryption wsduvall Linux - Software 1 03-09-2009 10:14 AM
LVM Resize - After logical resize, FS size does not match physical size. spectra Linux - Software 6 11-01-2006 11:28 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 10:10 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration