Help understanding LVM + LUKS

Software & Operating Systems Linux
,
1

Hi,

I was wondering would anyone be able to help me get a better understanding of how LVM and LUKS work together on Linux storage devices?

I had another thread where I was trying to understand the best way to re-partition a data drive I had but while looking into that issue I found that my SSD is not being utilised as well as it should and I would like to address that first. I did add to that thread but my post was too wordy and probably didn’t make much sense.

So I thought I’d see if I could be a bit more concise here.

I have an SSD with the following partitions:

NAME                                            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                               8:0    0 489.1G  0 disk  
├─sda1                                            8:1    0   512M  0 part  /boot/efi
├─sda2                                            8:2    0     2G  0 part  /boot
└─sda3                                            8:3    0   256G  0 part  
  └─fedora--ssd-root                            253:0    0   256G  0 lvm   
    └─luks-fa9f909c-6a08-4554-b354-074aa04a80ee 253:3    0   256G  0 crypt /

There is a single LVM volume group for the SSD called fedora-ssd

--- Volume group ---
  VG Name               fedora-ssd
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               256.00 GiB
  PE Size               4.00 MiB
  Total PE              65536
  Alloc PE / Size       65536 / 256.00 GiB
  Free  PE / Size       0 / 0   
  VG UUID               iLJ7iR-npsd-D4OY-cVWs-Wvoy-KIdG-RYYH39

From what I understand, the “fedora-ssd” volume group is backed by only the /dev/sda3 partition/physical volume and does not really represent the entire SSD (/dev/sda1 and /dev/sda2 being outside of LVM because they are needed during boot)

--- Physical volume ---
  PV Name               /dev/sda3
  VG Name               fedora-ssd
  PV Size               256.00 GiB / not usable 2.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              65536
  Free PE               0
  Allocated PE          65536
  PV UUID               8OWONx-Y8nW-1Y3A-fqyw-eDmM-UGzz-zlLaJn

Is this correct so far?

I would like to move my /home partition to my SSD. There’s about 248GB of space un-allocated on the SSD but the existing root partition is far to big so I would also like to reclaim some of that space.

So my second question is, what is the best way to do this?

My first thoughts were to resize /dev/sda3 to between 60-80GB (I’m currently only using 11GB) then create /dev/sda4 with the remaining space on the SSD for /home.

But the more I think about it the more I realise this seems like how things would have been done before LVM. And I would also like the new /home to be encrypted so would probably have to create a new LUKS volume for the new /dev/sda4

Instead, If I were to expand /dev/sda3to fill the remaining un-allocated space on the SSD (giving it approx 500GB), would this space then be available to the fedora-ssd volume group (and more importantly still part of the existing LUKS volume)?

Is so, can I then shrink the fedora-ssd-root logical volume to 60GB with lvreduce and create a new fedora-ssd-home logical volume that takes the remaining space in the fedora-ssd volume group.

Again sorry for the length of the post, I tried to keep it as sort as I could, but does the second approach sound reasonable or am I still not understanding LVM correctly?

Any advice or clarification would be appreciated.

Thanks

2 Likes
2

In the true spirit of Linux I’ve figured this out for myself :wink:

I’ve been doing a lot more reading about LVM but I haven’t been able to find a definitive answer to my question. Many of the sources seem to either propose different methods or completely contradict each other.

So I decided to go with what I think is the more logical approach given my setup. To that end I installed another Fedora 29 VM and setup the virtual disks to mimic the setup on my host. I then read up on the different commands I need to go with the second approach (extending the existing /dev/sda3 partition and PV so that all the un-allocated space is available to the fedora-ssd volume group)

I figured I might as well document it here in case anyone is interested or needs to do something similar. However, please be aware that since I’m winging it, this is what has worked for me and I chose to do it all on a VM until I was comfortable with the process.

Step 1) Started with a test VM configured with two virtual drives with a similar setup to that of my host.

NAME                                          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                                             8:0    0   20G  0 disk  
├─sda1                                          8:1    0    1G  0 part  /boot
└─sda2                                          8:2    0    8G  0 part  
  └─luks-27d26d63-fe76-4564-a85f-a31bcd79f6a7 253:0    0    8G  0 crypt 
    └─fedora--ssd-root                        253:2    0    8G  0 lvm   /
sdb                                             8:16   0   12G  0 disk  
└─sdb1                                          8:17   0    8G  0 part  
  └─luks-36d79c96-0b25-4e03-85c0-94a8c6a72636 253:1    0    8G  0 crypt 
    ├─fedora--hd-swap                         253:3    0    2G  0 lvm   [SWAP]
    ├─fedora--hd-home                         253:4    0    1G  0 lvm   /home
    ├─fedora--hd-tmp                          253:5    0    1G  0 lvm   /tmp
    └─fedora--hd-var                          253:6    0    3G  0 lvm   /var
sr0

Note: As the test VM is booting from legacy BIOS rather than UEFI I only have /dev/sda1 and /dev/sda2. On my host I have an EFI partition so the root partition is /dev/sda3

The goal is to move /home (fedora-hdd-home) from the fedora-hdd volume group on /dev/sdb1 to a new logical volume on on fedora-ssd. I also wanted to make sure that the new /home is encrypted as part of the existing LUKS volume on /dev/sda2 but since I now understand that LUKS (LUKS volume?) sits between LVM and the block device I shouldn’t have to do any additional work here since I am just extending /dev/sda2 and creating the new LV in the layer above.

Step 2) Resizing /dev/sda2

Since this is the root partition (and it’s encrypted) I am not sure if this can be done while the OS is running or even in single user mode.

I wasn’t able to find consistent information on how a partition is resized (Some say it can be resized in place, others say it needs to be deleted and recreated using fdisk). So, I figured the easiest way to do it would be to create a GParted Live USB and let it take care of any delete/recreates for me.

So I booted the test VM with the GParted USB and set to work.

GParted supports LUKs volumes so the first thing I needed to do was to decrypt the partition I wanted to resize (Open Encryption)

GParted_001
GParted_001.png820×648 61.2 KB

Then it was just a case of resizing the partition to consume all of the un-allocated space on the disk before writing the changes to disk

GParted_002
GParted_002.png798×545 42 KB

Step 3) Resizing the /dev/sda2 physical volume and fedora-ssd volume group (*** or not)

I had thought that once I resized the /dev/sda2 I would need to resize the LVM physical volume and the volume group but that didn’t seem to be required. When I rebooted the VM, the fedora-ssd volume group had detected the new partition size.

NAME                                          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                                             8:0    0   20G  0 disk  
├─sda1                                          8:1    0    1G  0 part  /boot
└─sda2                                          8:2    0   19G  0 part
  └─luks-27d26d63-fe76-4564-a85f-a31bcd79f6a7 253:0    0   19G  0 crypt 
    └─fedora--ssd-root                        253:2    0    8G  0 lvm   /
sdb                                             8:16   0   12G  0 disk  
└─sdb1                                          8:17   0    8G  0 part  
  └─luks-36d79c96-0b25-4e03-85c0-94a8c6a72636 253:1    0    8G  0 crypt 
    ├─fedora--hd-swap                         253:3    0    2G  0 lvm   [SWAP]
    ├─fedora--hd-home                         253:4    0    1G  0 lvm   /home
    ├─fedora--hd-tmp                          253:5    0    1G  0 lvm   /tmp
    └─fedora--hd-var                          253:6    0    3G  0 lvm   /var
sr0                                            11:0    1 1024M  0 rom

So I am going with yet another assumption, because I did the resizing offline Fedora LVM just detected the changes during the next boot.

Physical volume showing 19GB (via the pvdisplay command)

  --- Physical volume ---
  PV Name               /dev/mapper/luks-27d26d63-fe76-4564-a85f-a31bcd79f6a7
  VG Name               fedora-ssd
  PV Size               <19.00 GiB / not usable 1.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              4863
  Free PE               2815   *** Excellent :)
  Allocated PE          2048
  PV UUID               11mayX-c2ws-j1fO-1aHG-V7FI-cGOv-RsTBrL

Volume group showing 19GB (via the vgdisplay command)

[shecks@nova-five ~]$ sudo vgdisplay fedora-ssd
  --- Volume group ---
  VG Name               fedora-ssd
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <19.00 GiB
  PE Size               4.00 MiB
  Total PE              4863
  Alloc PE / Size       2048 / 8.00 GiB
  Free  PE / Size       2815 / <11.00 GiB    *** Excellent :)
  VG UUID               yXcuKl-SgWG-ehvO-faSN-2OS9-C43s-6VnQLb

Step 4) Create the new /home logical volume on fedora-ssd

On my host I also want to reduce the size of the existing fedora-ssd-root LV before creating the new /home LV. I haven’t tested this yet but believe it can be done by shrinking the filesystem (via resize2fs) then resizing the fedora-ssd-root LV (via lvreduce). On my test VM I am just going to create the new /home LV with the space I have after the resize.

To create the new /home LV I used the lvcreate command as follows:

sudo lvcreate -l 100%FREE -n home fedora-ssd

This will create a new logical volume called fedora-ssd-home that consumes all of the remaining free space in the fedora-ssd volume group.

NAME                                          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                                             8:0    0   20G  0 disk  
├─sda1                                          8:1    0    1G  0 part  /boot
└─sda2                                          8:2    0   19G  0 part  
  └─luks-27d26d63-fe76-4564-a85f-a31bcd79f6a7 253:0    0   19G  0 crypt 
    ├─fedora--ssd-root                        253:2    0    8G  0 lvm   /
    └─fedora--ssd-home                        253:7    0   11G  0 lvm   *** Success :)
sdb                                             8:16   0   12G  0 disk  
└─sdb1                                          8:17   0    8G  0 part  
  └─luks-36d79c96-0b25-4e03-85c0-94a8c6a72636 253:1    0    8G  0 crypt 
    ├─fedora--hd-swap                         253:3    0    2G  0 lvm   [SWAP]
    ├─fedora--hd-home                         253:4    0    1G  0 lvm   /home
    ├─fedora--hd-tmp                          253:5    0    1G  0 lvm   /tmp
    └─fedora--hd-var                          253:6    0    3G  0 lvm   /var
sr0

The new LV has comsumed all the remaing extents on the PV

  --- Physical volume ---
  PV Name               /dev/mapper/luks-27d26d63-fe76-4564-a85f-a31bcd79f6a7
  VG Name               fedora-ssd
  PV Size               <19.00 GiB / not usable 1.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              4863
  Free PE               0
  Allocated PE          4863
  PV UUID               11mayX-c2ws-j1fO-1aHG-V7FI-cGOv-RsTBrL

And in turn, the volume groups is also now full

  --- Volume group ---
  VG Name               fedora-ssd
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <19.00 GiB
  PE Size               4.00 MiB
  Total PE              4863
  Alloc PE / Size       4863 / <19.00 GiB
  Free  PE / Size       0 / 0   
  VG UUID               yXcuKl-SgWG-ehvO-faSN-2OS9-C43s-6VnQLb

Step 5) Create filesystem on fedora-ssh-home using mkfs.ext4

sudo mkfs.ext4 /dev/fedora-ssd/home

The new LV can now be mounted and used for storage.

If anyone’s interested I will detail the steps I used to move my /home from fedora-hdd to the new fedora-ssd-home LV in another post.

1 Like
3

Now that I had my new home LV on my fake SSD drive I needed to figure out how to move the existing /home to it’s new errrm “home”

Again, I don’t know if there’s an easier way to do this of it can be done while logged in as a regular user but I figured it was a job for “root” so that’s the method I chose.

Before I start I should mention that by default root login is disabled on Fedora (and probably other distros) so I had to enable it by giving the root user a password (I don’t know how bad this is from a security point of view, but I needed to be able to log in as root)

So I used:

sudo passwd root

To set the password before rebooting.

Step 1) Boot the VM in single user mode and log in as root

To do this I rebooted the VM, interrupted the GRUB boot and added ‘1’ to the kernel boot parameters to boot into single user mode. Then I logged in as root using the password I set previously.

Step 2) Mount the new fedora-sdd-home LV

mkdir /mnt/home
mount /dev/fedora-ssd/home /mnt/home

Step 3) Copy the data from the existing /home to the new LV

cp -aR /home/* /mnt/home

*** It’s probably a good idea to do a diff here to make sure everything is as expected. On my VM I decided to leave the old /home mounted as /old_home so I could verify this later. I will probably do the same when I make the changes on my real PC and only get rid of the old mount after a few days of using the new setup.

Step 4) Change configuration so that the fedora-ssd-home LV is mounted at /home on boot.

To do this I needed to modify /etc/fstab

Since I am a Linux noob, I used nano rather than the masochistic vi or vim :wink:

nano /etc/fstab

The fstab on my test VM was as follows:

/dev/mapper/fedora--ssd-root /  ext4    defaults,x-systemd.device-timeout=0 1 1
UUID=01f93ba5-3d45-471a-a9ed-5cae617cd955 /boot                   ext4    defaults        1 2
/dev/mapper/fedora--hd-home /home                   ext4    defaults,x-systemd.device-timeout=0 1 2
/dev/mapper/fedora--hd-tmp /tmp                    ext4    defaults,x-systemd.device-timeout=0 1 2
/dev/mapper/fedora--hd-var /var                    ext4    defaults,x-systemd.device-timeout=0 1 2
/dev/mapper/fedora--hd-swap swap                    swap    defaults,x-systemd.device-timeout=0 0 0

Being lazy I decided just to change the line to mount fedora-hd-home so that it was mounted to /mnt/old_home/ (after creating /mnt/old_home) as follows:

/dev/mapper/fedora--hd-home /mnt/old_home ext4 defaults,x-systemd.device-timeout=0 1 2

And then added an additional line to mount the new fedora-ssd-home LV in its place:

/dev/mapper/fedora--ssd-home /home ext4 defaults,x-systemd.device-timeout=0 1 2

Then saved the file.

Step 5) Reboot the VM

After reboot the new fedora-ssd-home LV should be mounted at /home and all should be well with the world.

NAME                                          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                                             8:0    0   20G  0 disk  
├─sda1                                          8:1    0    1G  0 part  /boot
└─sda2                                          8:2    0   19G  0 part  
  └─luks-27d26d63-fe76-4564-a85f-a31bcd79f6a7 253:0    0   19G  0 crypt 
    ├─fedora--ssd-root                        253:2    0    8G  0 lvm   /
    └─fedora--ssd-home                        253:7    0   11G  0 lvm   /home
sdb                                             8:16   0   12G  0 disk  
└─sdb1                                          8:17   0    8G  0 part  
  └─luks-36d79c96-0b25-4e03-85c0-94a8c6a72636 253:1    0    8G  0 crypt 
    ├─fedora--hd-swap                         253:3    0    2G  0 lvm   [SWAP]
    ├─fedora--hd-home                         253:4    0    1G  0 lvm   /mnt/old_home
    ├─fedora--hd-tmp                          253:5    0    1G  0 lvm   /tmp
    └─fedora--hd-var                          253:6    0    3G  0 lvm   /var
sr0

Success … and there was much rejoicing :smiley:

I am now off to figure out how to clone my /dev/sda disk to a backup disk so I can make all these changes on my actual PC … depending on how that goes, I may or may not be back :thinking:

2 Likes
4

You are awsome dude.

2 Likes
5

Til March 23

6

Haha, I wouldn’t go that far!

Just waiting for someone to reply with “You did what? Don’t do that on physical hardware!!!”

In saying that, I’ve just run into my first snag, I went to do the root partition resize on the real SSD, booted the GParted Live USB and the “Open Encryption” option is greyed out … I think it’s because it’s an LVM2 volume.

** EDIT: I’ve just noticed that the volumes on my test VM were also marked as LVM2 so it’s not that.

Might have to learn how to do it manually after all, more research is in order.

1 Like
7

Well that wasn’t as bad as I expected.

Just out of curiosity (and a lot of laziness on my part) I decided to install GParted on my PC … “just to have a look”

And it turns out, it’s ok to grow a partition while it’s mounted (I thought because it was the root partition this wouldn’t be allowed), and it’s even handier because it’s already decrypted.

From the GParted documentation

*** Tip
Unmounted or inactive partitions enable the most resize options.

Support is available for online resize of some mounted or otherwise active partitions. 
However this support is often limited to grow only.

GParted_001_Live
GParted_001_Live.png1596×921 95 KB

And GParted seems to also take care of notifying LVM of the changes because I didn’t need to do anything the volume group to pickup the changes.

[shecks@red-dwarf ~]$ sudo vgdisplay fedora-ssd
[sudo] password for shecks: 
  --- Volume group ---
  VG Name               fedora-ssd
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <486.55 GiB                            *** Excellent :)
  PE Size               4.00 MiB
  Total PE              124556
  Alloc PE / Size       65536 / 256.00 GiB
  Free  PE / Size       59020 / <230.55 GiB                    *** Excellent :)
  VG UUID               iLJ7iR-npsd-D4OY-cVWs-Wvoy-KIdG-RYYH39

The physical volume was also refreshed

[shecks@red-dwarf ~]$ sudo pvdisplay /dev/sda3
[sudo] password for shecks: 
  --- Physical volume ---
  PV Name               /dev/sda3
  VG Name               fedora-ssd
  PV Size               <486.55 GiB / not usable 1.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              124556
  Free PE               59020                                   *** Excellent :)
  Allocated PE          65536
  PV UUID               8OWONx-Y8nW-1Y3A-fqyw-eDmM-UGzz-zlLaJn

Next steps will be to resize / root and then lvreduce the fedora-ssd-root LV

This is where it all might still end in tears.

1 Like
8

Well that didn’t go according to plan.

I created a new VM to test reducing the size of the / filesystem and LV before attempting to make the changed on my real SSD.

Everything went well in the VM, but when I went to make the same changes on my SSD I figured out why the GParted Live USB didn’t let me the open /dev/sda3 “LUKS” volume … because it’s not a LUKS volume :frowning:

It turns out when I installed Fedora originally I managed to set up the fedora-ssd-root LV with a LUKS volume inside it and not the other way around as I have been doing with my test VMs.

So I have this:

NAME                                            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                               8:0    0 489.1G  0 disk  
├─sda1                                            8:1    0   512M  0 part  /boot/efi
├─sda2                                            8:2    0     2G  0 part  /boot
└─sda3                                            8:3    0 486.6G  0 part  
  └─fedora--ssd-root                            253:0    0   256G  0 lvm   
    └─luks-fa9f909c-6a08-4554-b354-074aa04a80ee 253:2    0   256G  0 crypt /

Rather than something like this (from the test VM):

NAME                                          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                                             8:0    0   20G  0 disk  
├─sda1                                          8:1    0    1G  0 part  /boot
└─sda2                                          8:2    0   19G  0 part
  └─luks-27d26d63-fe76-4564-a85f-a31bcd79f6a7 253:0    0   19G  0 crypt 
    └─fedora--ssd-root                        253:2    0    8G  0 lvm   /

My plan (and what I have successfully done in my test VMs) is to eventually have a new fedora-ssd-home inside one LUKs volume.

I will have to learn how to screw up a test VM to match the screw up I made on my real hardware, there had to have been drink involved :thinking:

This is going to take some figuring out … my brain hurts.

9

Some progress has been made. I finally built up the courage to attempt to resize my / partition and reclaim some of that unused space in preparation for creating the new /home LV on my fedora-ssd volume group.

I’ve decided not to tempt faith and try to rearrange things so that I have the / and /home LVs inside a single LUKS volume backed by /dev/sda3, that will be a job for future me if I am doing a full re-install.

Instead I am just going to shrink the root LUKS and LV to 60GB and then setup the new /home the same way (e.g fedora-ssd-home LV containing a LUKS volume)

Question: How does Linux (boot process) handle decryption of multiple LUKS volumes with the same passphrase?

As far as I can tell (according to lsblk and the contents of /etc/crypttab), my setup currently has 5 separate LUKS volumes (because I split out /root /swap /var/ /tmp /home in to separate partitions when I drunkenly installed Fedora). But they all have the same passphrase and the Linux boot process is somehow smart enough to know that so only prompts me for the passphrase once.

I still can’t find anywhere that confirms this, but my current “theory” is that during boot it just checks the passphrase against the header of each LUKS volume to see if it can decrypt any of the master key slots and only prompts for another passphrase if it fails to decrypt a master key for any LUKS volume.

Sooooo … assuming my theory is sound, it stands to reason that if I create a new fedora-ssd-home LV and then create yet another LUKS volume inside it with the same passphrase … all should be well with the world :thinking: (apart from the fact that if I had understood all this when I installed Fedora in the first place I’d only have a single LUKS volume per drive … damn it :neutral_face:)

So that’s the plan …

Step 1) Resize the root LUKs volume

Because I am reducing the size of the volume and it’s the root volume I can’t do this online. And since it’s LUKS over LVM and not LVM over LUKS (*ouch my head hurts) the GParted UI in on the Live USB doesn’t like this and won’t let me work with the volume. So I needed to get familiar with cryptsetup.

Since the GParted Live DB is a Debian distro with all the command line tools I need I was able to use that.

Step 2) Boot a Live USB and decrypt the root LUKS volume

Once booted I opened the terminal and did some checking to make sure I was working with the correct volume. I found that you can check if a volume is a LUKs volume using the following command:

sudo cryptsetup luksDump <device>

So I ran sudo cryptsetup luksDump /dev/fedora-ssd/root to confirm that it was correct and it spat out the LUKS header.

Before the file-system on /dev/fedora-ssd/root could be manipulated it needed to be decrypted and mapped. I did this with the following command:

sudo cryptsetup luksOpen /dev/fedora-ssd/root decrypted_root

This will prompt for the volume passphrase and once complete will map the volume to /dev/mapper/decrypted_root

Step 3) Resize the file-system

I know that I am currently only using approx. 11GB on /root and pretty much have everything I need installed so I am going to reduce it down to 60G (probably still too large but much better than 256G)

I read a couple of tutorials that say there is a discrepancy between the units used by the file-system resizing tools and the LVM tools (e.g one uses 1024 for K,M,G etc and the other 1000). I’ll look into this in detail later but for the moment I decided to do the resize in 3 steps.

  1. Resize the file-system to 50G
  2. Resize the LV to 60G
  3. Resize the file-system again to consume the space (60G) in the LV

To resize the file-system I used the following command:

sudo resize2fs /dev/mapper/decrypted_root 50G

Note: You need to make sure you’re working on the mapped decrypted volume so it was “decrypted_root” in my case
Note: resize2fs will probably prompt you to run a filesystem check before the resize

I the resized the fedora-ssd-root logical volume using the following command:

sudo lvresize -L 60G /dev/fedora-ssd/root

Note: Here it’s resizing the LV so the name is /dev/fedora-ssd/root not the name of the mapped LUKS volume.
Note: You can use “+/-” when specify the size to expand or reduce “by” that amount but here I am explicitly resizing to 60G

Finally I resized the file-system on the LUKS volume to fill the LV:

sudo resize2fs /dev/mapper/decrypted_root

Note: If you don’t specify a size the file-system will be expanded to fill the entire partition/LV so should be 60G in this case.

Again, I don’t know if this 3 step resize is actually required, I need to read up a bit more to see if there are indeed still dependencies between the units used by the file-system tools and LVM but this worked for me.

Step 4) Close the LUKS volume, cross fingers and reboot

This was probably not required since I was rebooting anyway but to close the LUKS volume you can use the following command:

sudo cryptsetup close /dev/mapper/decrypted_root

At this point I crossed my fingers and rebooted back into Fedora

panic

Luckily there was no fire and no one died :grinning:

I now have a nice tidy 60G LUKS encrypted /root LV

NAME                                            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                               8:0    0 489.1G  0 disk  
├─sda1                                            8:1    0   512M  0 part  /boot/efi
├─sda2                                            8:2    0     2G  0 part  /boot
└─sda3                                            8:3    0 486.6G  0 part  
  └─fedora--ssd-root                            253:0    0    60G  0 lvm   
    └─luks-fa9f909c-6a08-4554-b354-074aa04a80ee 253:2    0    60G  0 crypt /

A nice tidy LV

--- Logical volume ---
  LV Path                /dev/fedora-ssd/root
  LV Name                root
  VG Name                fedora-ssd
  LV UUID                BCwerR-oGdZ-ajyl-kieO-dHlR-nC0v-L3e8b3
  LV Write Access        read/write
  LV Creation host, time localhost-live, 2018-05-02 17:43:36 +0100
  LV Status              available
  # open                 1
  LV Size                60.00 GiB                            *** Excellent :)
  Current LE             15360
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

And plenty of free space in my fedora-ssd volume group to create the new /home LV

  --- Volume group ---
  VG Name               fedora-ssd
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  6
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <486.55 GiB
  PE Size               4.00 MiB
  Total PE              124556
  Alloc PE / Size       15360 / 60.00 GiB
  Free  PE / Size       109196 / <426.55 GiB                  *** Excellent :)
  VG UUID               iLJ7iR-npsd-D4OY-cVWs-Wvoy-KIdG-RYYH39

In the next instalment of “Fumbling Through LVM + LUKS with Shecks” I will attempt to create my new fedora-ssd-home LV + LUKS volume and test my single passphrase theory.

10

It looks like my theory about multiple LUKS volumes with the same passphrase is reasonable. I’ve created a new LV for my new /home on my SSD with a new LUKS volume in it and I am still only prompted once at bootup for the passphrase. The new LUKS volume is decrypted and mapped as expected.

If anyone’s interested, here’s how I set it up.

Step 1) Create the new fedora-ssd-home LV

sudo lvcreate -L 400G -n home fedora-ssd

This will create a new LV called fedora-ssd-home and a device at /dev/fedora-ssd/home (mapped at /dev/mapper/fedora-ssd-home)

Step 2) Create the new encrypted LUKS volume in fedora-ssd-home

sudo cryptsetup luksFormat --hash=sha512 --key-size=512 --cipher=aes-xts-plain64 --verify-passphrase /dev/fedora-ssd/home

Note: You’ll be asked to enter and confirm the new passphrase to encrypt the master key for the volume, I used the same passphrase as my other LUKS volumes.

For the --hash, --key-size and --cipher parameters I just copied the config that the Fedora installer used when it created my fedora-ssd-root volume. You can see the config by dumping the LUKS header for the volume with cryptsetup luksDump <device>

|Version:       |1|
|---|---|
|Cipher name:   |aes|
|Cipher mode:   |xts-plain64|
|Hash spec:     |sha512|
|Payload offset:|4096|
|MK bits:       |512|
|MK digest:     <nope>
|MK salt:       <nope>
|               <nope>
|MK iterations: <nope>
|UUID:          |b118d37c-5818-4150-bcd0-b83b92f717b4|

Step 3) Add a filesystem to the new volume

You can do this now or when you map the volume and reboot after step 4 but I chose to do it now.

The LUKS volume must be decrypted and mapped before you can manipulate it. To do this use the cryptsetup command as follows:

sudo cryptsetup luksOpen /dev/fedora-ssd/home new_home

You’ll be prompted for the passphrase then the volume will be decrypted and mapped as /dev/mapper/new_home

Creating the filesystem is then just a case for running the mkfs command for the filesytem you want

sudo mkfs.ext5 /dev/mapper/new_home

Step 4) Add the new LUKS volume to /etc/crypttab

In order for the new LUKS volume to be decrypted during boot an entry needs to be added to the /etc/crypttab file. For this entry you need the UUID of the LUKS volume which you can get the LUKS volume header (see cryptsetup luksDump above)

The Fedora installer uses “luks-” followed by the UUID for the mapped name of the LUKS volume so I decided to do the same. So I added the following entry to /etc/crypttab

# /dev/fedora-ssd/home
luks-b118d37c-5818-4150-bcd0-b83b92f717b4 UUID=b118d37c-5818-4150-bcd0-b83b92f717b4 none discard

I used the same config “none” and “discard” options as my other LUKS volumes.

I then saved the file and rebooted.

As I’d hoped, during boot I was only prompted for a passphrase once and both my fedora-ssd-root and fedora-ssd-home
were successfully decrypted and mapped

NAME                                            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                               8:0    0 489.1G  0 disk  
├─sda1                                            8:1    0   512M  0 part  /boot/efi
├─sda2                                            8:2    0     2G  0 part  /boot
└─sda3                                            8:3    0 486.6G  0 part  
  ├─fedora--ssd-root                            253:0    0    60G  0 lvm   
  │ └─luks-fa9f909c-6a08-4554-b354-074aa04a80ee 253:2    0    60G  0 crypt /
  └─fedora--ssd-home                            253:7    0   400G  0 lvm   
    └─luks-b118d37c-5818-4150-bcd0-b83b92f717b4 253:11   0   400G  0 crypt

Now all I need to do is copy the data from my old /home to the “new home” and swap the mount points over … but that will be a job for the Live Linux USB and is the same process I documented above on my test VM.

Hopefully someone might find my adventure useful, or if anything, as a warning to do things correctly in the first place so there’s no need to go through all of this after the screw up :stuck_out_tongue_winking_eye:

11

Necro update

Finally got around to finishing this out (for now). I’ve managed to complete my ‘feng shui’ work on my SSHD and get it into a state that satisfies my OCD.

sdd                                               8:48   0   1.8T  0 disk  
└─sdd1                                            8:49   0   1.8T  0 part  
  └─luks-b82dc406-ba2a-418b-96fa-cb27badf7dbf   253:2    0   1.8T  0 crypt 
    ├─fedora--sshd-swap                         253:3    0    96G  0 lvm   [SWAP]
    ├─fedora--sshd-var                          253:5    0    32G  0 lvm   /var
    ├─fedora--sshd-tmp                          253:6    0     4G  0 lvm   /tmp
    └─fedora--sshd-data                         253:7    0     1T  0 lvm   /drives/sshd-data

I now have one LUKS volume with LVM inside rather than multiple LUKS volumes each with their own LVM logical volume (still don’t know how I managed to get it that screwed up)

Now I just need to figure out how to fix this mess:

└─sda3                                            8:3    0 486.6G  0 part  
  ├─fedora--ssd-root                            253:0    0    60G  0 lvm   
  │ └─luks-fa9f909c-6a08-4554-b354-074aa04a80ee 253:1    0    60G  0 crypt /
  └─fedora--ssd-home                            253:4    0   400G  0 lvm   
    └─luks-b118d37c-5818-4150-bcd0-b83b92f717b4 253:8    0   400G  0 crypt /home

With what I’ve learned along the way I think I could probably do this using a Live USB but not sure I should tempt faith … maybe I’ll do a fresh install when Fedora 30 is released :thinking: