Extending LUKS LVM - The Correct Way?

My LUKS-encrypted LVM resides on /dev/sda2. After upgrading my HDD to a bigger one, I created a new partition /dev/sda5 (NOT encrypted), made it a part of my Volume Group “system”, and then extended my Logical Volume /dev/mapper/system-home. The procedure was as follow and it seems to be working. The big question is, is this secure?


cryptsetup luksOpen /dev/sda2 cr_lvm
vgchange -a y
fdisk /dev/sda5
pvcreate /dev/sda5
vgextend system /dev/sda5
lvextend -L +500G /dev/mapper/system-home
resize2fs /dev/mapper/system-home

No, I don’t think that’s secure. The data that is on “/dev/sda5” won’t be encrypted.

I have never done what you are trying. But I think you needed to first encrypt “/dev/sda5” (LUKS encryption). Then open that with “cryptsetup luksOpen”. That gives a virtual device under “/dev/mapper”. And I think that virtual device is what you needed to use to expand the LVM.

I think there is a lot more to be done, and it’s difficult if you’re working with a volume holding your root (/), in which case it looks like you have to perform your operations by first booting up Live media (ie LiveCD or Live USB).

Here is an Arch Wiki guide which to me looks like the steps aren’t very “generalized,” so may need to be modified to your specific setup as you go along. If you decide to follow the Ubuntu guide below instead, this Arch guide may still be handy…
https://wiki.archlinux.org/index.php/Resizing_LVM-on-LUKS

This Ubuntu guide looks to be a bit more descriptive, especially about the different layers/“shells” that need to be modified…
https://help.ubuntu.com/community/ResizeEncryptedPartitions

Unlike the steps described above, the following describes the steps I would have intuitively thought best… Decrypting, then expanding, then re-encrypting but it can take a very long time…
https://www.lisenet.com/2013/extend-an-encrypted-luks-partition/

TSU

It’s possible (and more simple to administer later) to increase size of encrypted partition assuming free space is adjacent to it. Actually, it can be done almost online, the only thing that needs unmounting is to inform kernel of new partition size (partition in use cannot be resized). You can resize partition on disk, resize cryptocontainer, PV, LV and filesystem while they are in use.

I honestly have spent a lot of time reading different guides and I’m still reading. The problem is they’re mostly too case-specific and mostly focused on shrinking than expanding. If possible, please tell me how should I do this in more details.

My free space is not adjacent to my crypted partition and I’m not even sure if it’s safe to move partitions to make free space available.

After further readings, I concluded that since I have LVM-over-LUKS, it’s not possible to enlarge the partition unless there is free space adjacent to it. Here are my questions:

  1. Is the above correct?

  2. Since my LUKS is on sda2 and I have Windows 10 on sda4 (and sda3), is it reasonably safe to move sda3 and sda4 partitions so as to make free space adjacent to sda2?

  3. Is it possible to transform my LVM-over-LUKS to LVM-over-LUKS-over-LVM (so as to get over the limitation of adjacent free space by using the LVM features)?

Can not increase size of any partition or container unless space is adjacent

Safe is a relative thing. Any time you play with partitions you should backup important data and have a recovery plan

LVM was designed to allow linkage of multiple LVM partitions but the encryption throws an additional problem and I don’t know the details

I did something like that, but with Windows 7. I used “gparted” to move the partitions.

Windows complained about files system problems. It was able to fix them (sort of, but I could still see evidence).

Fortunately, I had the sense to take a full backup before I moved partitions around (with Acronis True Image). So I restored Windows from the backup, but to the new location (after moving the partition). That worked.

I didn’t actually try to move my encrypted LVM. I did the partition move just before installing opensuse 13.2. So I backed up the home volume from my encrypted LVM, then deleted the LVM partition. After moving things around and then fixing with Acronis, I recreated the LVM where I wanted it, and restored the home volume from my backup. By the way, I used “dar” from the command line for the linux file system backup and restore. And I used the encryption option of “dar”, so that my backup was encrypted.

That all worked okay.

  1. Is it possible to transform my LVM-over-LUKS to LVM-over-LUKS-over-LVM (so as to get over the limitation of adjacent free space by using the LVM features)?

That looks too complex.

As far as I know, it is still possible to add more space to an LVM. As long as the space that you add is also a LUKS encrypted partition (preferably with the same encryption key), that should work. And once you have added the space, the LVM utilities should allow you to grow volumes. If using “plymouth”, it should handle the crypto and only prompt once for the encryption key (assuming that both use the same key).

I’ll admit that I have never tried this. I guess I should experiment with it some day.

I can confirm that what nrickert proposed does indeed work. The problem is solved.

Initially, I was thinking about auto-mounting the new LUKS partition by using a key-file that was encrypted in the old LUKS partition. But using the same key, as suggested by nrickert, is much easier and safer in my personal opinion. There is no prompt for the second passphrase etc.; you just insert it once as usual.

Great thanks to people here, especially nrickert.

For future reference, I’m going to mention the steps I took:

From a livecd, I created a new LUKS encrypted partition with LINUX LVM file system (/dev/sda5) with the** same key** that I had used when creating LUKS on /dev/sda2 . Then I did the following:


cryptsetup luksOpen /dev/sda2 cr_lvm
cryptsetup luksOpen /dev/sda5 new_crypt
vgchange -a y
pvcreate new_crypt
vgextend system /dev/mapper/new_crypt
lvresize /dev/mapper/system-home -l 100%FREE
e2fsck -f /dev/system/home
resize2fs /dev/system/home
e2fsck -f /dev/system/home

Then I edited /etc/crypttab (of my Linux system not live environment) and added the following like:

new_crypt /dev/sda5 none none

That’s all. Reboot and you’re good to go.

Reference:
http://www.ms.unimelb.edu.au/~trice/luks-resize/

Thanks for filling in the details.

And, yes, that’s exactly how it should work.

Perhaps consider changing “/etc/crypttab” to use the UUID rather than the device name.

Thank you. Is there any advantage? Should I consider doing the same with /etc/fstab? How should I find out the correct UUIDs?

At one time, I had fedora on one of my computers.

If I booted it with a USB drive plugged in, then the internal drive was “/dev/sdb”. Otherwise it was “/dev/sda”.

The device names are not guaranteed to be reliable. The device-id ("/dev/disk/by-id/some-string") or the UUID is more reliable where available. If using UUID, then replace “/dev/sda5” by “UUID=1234-5678” (except use the actual UUID). And yes, you can also do that in “/etc/fstab”.

You can find the UUID with the command

# blkid

For a LUKS partition, the UUID is in the LUKS header somewhere. You need the UUID for the LUKS partition, not the UUID for part of the LVM that is inside.

I think you can also use

# blkid /dev/sda5

to get just the one UUID for that partition.

This makes it resistant to device renaming.

Should I consider doing the same with /etc/fstab?
Makes sense for the same reason.

How should I find out the correct UUIDs?

In crypttab it is LUKS UUID, in fstab - filesystem UUID. You should see both with e.g. blkid command.

Thanks for the clear explanations.

In addition to blkid, the following command could be used for LUKS UUIDs:

cryptsetup luksUUID /dev/sda5

Also in /etc/crypttab, only the second item should be written as UUID.

I changed both fstab and crypttab and it worked just fine.