You are not logged in.

#1 2010-09-17 13:51:56

delcypher
Member
Registered: 2010-04-17
Posts: 42

[SOLVED]LVM on LUKS... extending volume group to another LVM partition

Hi I've followed the instructions on

http://www.pindarsign.de/webblog/?p=767

This is working fine. I have a second hard drive (sdb) that has a LUKS partition (sdb1) on it that I wish to use with my current volume group (volgroup).

My plan is to do the following...

cryptsetup luksOpen /dev/sdb1 securedrive #open LUKS partion
pvcreate /dev/mapper/securedrive #setup physical volume
vgextend volgroup /dev/mapper/securedrive #extend my volume group (volgroup) onto my second drive
lvextend -l 100%FREE volgroup/home #grow logical volume so that now it will use second drive
resize2fs /dev/volgroup/home #resize filesystem now that the home logical volume is larger

In principle that should work but I haven't tried it yet (for reasons I'm about to explain).

My concern is how I'm going to make this work when the system boots. I'm not sure what will happen when the kernel boots as in its current configuration one of the physical volumes (my second hard drive) will be missing when it decrypts my first hard drive as the second hard drive will not yet of been decrypted (so it can present the physical volume used for my volume group).

So my question is how do I make this work at boot? I have a feeling if I put an entry in /etc/crypttab that this won't work as the other volumes might not be able to mount without the presence of the physical volume needed for my volume group.

My current kernel parameter line is

kernel /vmlinuz26 cryptdevice=/dev/sda4:volgroup root=/dev/mapper/volgroup-root ro

Can I add another cryptdevice line... e.g. (I got the idea from here https://bbs.archlinux.org/viewtopic.php?id=92830)

cryptdevice=/dev/sdb1:volgroup

so I have...

kernel /vmlinuz26 cryptdevice=/dev/sda4:volgroup cryptdevice=/dev/sdb1:volgroup root=/dev/mapper/volgroup-root ro

Or is this approach doomed to failure?

I don't want to do anything yet as I'm afraid I'll be left with an unbootable system If the volume group is unaccessible.


Also a seperate question... if you have a "LVM volume group" that spans multiple drives how does the kernel know which drives to use?

Thanks.

Last edited by delcypher (2010-09-20 10:01:17)

Offline

#2 2010-09-17 16:22:08

delcypher
Member
Registered: 2010-04-17
Posts: 42

Re: [SOLVED]LVM on LUKS... extending volume group to another LVM partition

Oh I've seen this post (https://bbs.archlinux.org/viewtopic.php?id=101341) so I may give that a try. But what if you have say three or more hard drives that make up LVM volume group that are each on an encrypted partition?

Offline

#3 2010-09-20 10:00:45

delcypher
Member
Registered: 2010-04-17
Posts: 42

Re: [SOLVED]LVM on LUKS... extending volume group to another LVM partition

Okay I've managed to sort this out myself.

I didn't know this before but the "encrypt" hook is just a shell script that is run when executing the initramfs image (that starts the kernel). I simply modified the "encrypt" hook so that you could specify multiple devices (seperated by commas) in the cryptsetup parameter, e.g.

kernel /vmlinuz26 cryptdevice=/dev/sda4:volgroup,/dev/sdb1:volextend root=/dev/mapper/volgroup-root ro

Note you can actually use any name for the mapper devices. I used volgroup & volextend but they can be called anything as this has no effect on the name of your LVM "volumne group" (in my case volgroup).

To do this yourself you should

0. This is an optional step but you may wish to generate a custom initramfs image of your current configuration just incase you manage to mess up the encrypt hook. You can do this by running the following command

mkinitcpio -g /boot/kernel26-backup.img

and then by adding it as an option in /boot/grub/menu.lst (assuming you use grub).
1. Edit /lib/initcpio/hooks/encrypt with the required changes. I've put my version of the hook on paste bin -> http://pastebin.com/59J3JRj3
2. Regenerate the initramfs image using the following command

mkinitcpio -p kernel26

3. Edit /boot/grub/menu.lst (assuming you are using grub) and modify your kernel parameters so that all the drives that you need decrypting are available to the lvm2 hook used later.

I'll try to contact a developer and see if I can get this change submitted. Not really sure who I should speak to though.

Hope this helps someone.

Offline

#4 2012-02-07 15:13:45

synthead
Member
From: Seattle
Registered: 2006-05-09
Posts: 1,326

Re: [SOLVED]LVM on LUKS... extending volume group to another LVM partition


Touch my kernel

Offline

#5 2014-10-16 15:37:25

EscapedNull
Member
Registered: 2013-12-04
Posts: 129

Re: [SOLVED]LVM on LUKS... extending volume group to another LVM partition

Thanks! I haven't tried it yet, but it looks like exactly what I need. I'd like to see this go upstream if it hasn't already. These would probably be the people to contact:

Thomas Bächler <thomas@archlinux.org>
Dave Reisner <dreisner@archlinux.org>

Bonus points if you send a git-format-patch along with it. I'll do so if it still isn't upstream when I get some free time.

Offline

#6 2014-10-16 15:50:32

delcypher
Member
Registered: 2010-04-17
Posts: 42

Re: [SOLVED]LVM on LUKS... extending volume group to another LVM partition

Oh this was a long time a go. I don't think I ever got around to sending this upstream sad

It's very likely that the encrypt hook has changed since I hacked it so you may need to write from scratch with my modified script serving as a guide.

Offline

#7 2014-10-16 17:29:42

EscapedNull
Member
Registered: 2013-12-04
Posts: 129

Re: [SOLVED]LVM on LUKS... extending volume group to another LVM partition

delcypher wrote:

Oh this was a long time a go. I don't think I ever got around to sending this upstream sad

It's very likely that the encrypt hook has changed since I hacked it so you may need to write from scratch with my modified script serving as a guide.

You're probably right about the encrypt hook being changed since you forked it; I hadn't thought about that. Bash isn't my forte, but the encrypt hook doesn't look too complicated. I'll see what I can do.

Offline

Board footer

Powered by FluxBB