You are not logged in.
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
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
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
Offline
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
Oh this was a long time a go. I don't think I ever got around to sending this upstream
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
Oh this was a long time a go. I don't think I ever got around to sending this upstream
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