LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware - Installation (https://www.linuxquestions.org/questions/slackware-installation-40/)
-   -   How Do I Keep DM-CRYPT Mapping on Partitioned RAID1 Device in Slack64 13.37 (https://www.linuxquestions.org/questions/slackware-installation-40/how-do-i-keep-dm-crypt-mapping-on-partitioned-raid1-device-in-slack64-13-37-a-4175418890/)

TracyTiger 07-27-2012 12:43 AM
How Do I Keep DM-CRYPT Mapping on Partitioned RAID1 Device in Slack64 13.37
 
I can partition a LUKS enabled RAID device but the partitions are lost and not recreated after a reboot.

I can't keep/recreate /dev/mapper/crypt0p1 RAID partitions after a reboot. If I don't encrypt the partitions it works fine as the /dev/md* devices are available after a reboot.

I can also have the LUKS enabled RAID device available via /etc/crypttab but I can't manage to get partitions created from a RAID device to cooperate.

Any advice on how to accomplish this is appreciated. Perhaps it's not possible without complicating the boot process scripts.

The rest of this post is just the details summarizing how I've unsuccessfully attempted this.


Code:

--------------
In the past I've created systems with software RAID1 encrypted via LUKS for
the root partition with and without LVM.  I learned how a few years ago by
following README_CRYPT.TXT and README_RAID.TXT found on the Slack CD/DVD.
Works well, lasts a long time. (Thanks Eric and Amritpal)

I'm building a new system and saw that the --auto=mdp option of mdadm
permits partitioning of a RAID device.
https://raid.wiki.kernel.org/index.p..._/_LVM_on_RAID


So I thought I'd change the hierarchy.  Rather then creating multiple
partition sets on a disk device and building  multiple RAID devices (each
with LUKS) I'm trying to build a single RAID device (enabled with LUKS) out
of a single set of partitions and then partition that RAID device and
mount the separate partitions via the normal fstab.
                                       
This should permit using a single passphrase for LUKS instead of needing one
for each of several RAID devices.  (I'm aware of how to simplify things by
using key files to unlock subsequent file systems and using LVM but I wanted
to try the idea of partitioning RAID devices.

If someone can point out where I've gone wrong I'd appreciate it.

If it's not possible to maintain the dmcrypt device mapping as partitions of
a RAID device then I'll just return to my old methods with LVM or using
multiple disk partitions.

Note that I'm not yet attempting to use the root parition.  I'm just trying
to get it to work on some extra mount points for starters.

--------------------

Details Summarized::

A full install (no kdei) of Slack64 13.37 from DVD with no updates since the
original release last year.  Two disks sda sdb with root on sda1.  sda3 and
sdb3 used to create RAID1 device /dev/md0.

All commands run as root from a console terminal.

fdisk used to create sda3 sdb3 of type fd.

no swap - 16GB RAM

mdadm --create /dev/md0 --level mirror --auto=mdp --verbose --raid-devices 2 /dev/sda3 /dev/sdb3

/proc/mdstat confirms RAID device built and active

ls -al /dev/md* shows  /dev/md0 with a current modification time

cryptsetup -s 256 luksFormat /dev/md0

cryptsetup luksOpen /dev/md0 crypt0

Use fdisk /dev/mapper/crypt0 to create 2 1GB Linux partitions.

fdisk -l shows the 2 partitions on disk /dev/mapper/crypt0
 - /dev/mapper/crypt0p1
 - /dev/mapper/crypt0p2

But /dev/mapper/crypt0p1 & p2 also show up as DISKS without partition
tables.  This doesn't happen to sda1 when you create a partition on sda.

mkfs.ext4 /dev/mapper/crypt0p1 & p2

tune2fs -l /dev/md0p1 & p2 confirms the file systems

mdadm --detail --scan > /etc/mdadm.conf

mkdir /hd1 /hd2

Edit fstab to add
/dev/mapper/crypt0p1    /hd1    ext4    defaults    0  0
/dev/mapper/crypt0p2    /hd2    ext4    defaults    0  0

mount -a

Copy a sample file to each directory /hd1 & /hd2

edit /etc/crypttab to show
crypt0    /dev/md0

All looks good.

At this point we have the following block devices

/dev/dm-0  major 253 minor 0
/dev/dm-1  major 253 minor 1
/dev/dm-2  major 253 minor 2

/dev/mapper/control (character file)
/dev/mapper/crypt0  -->>  ../dm-0
/dev/mapper/crypt0p1 major 253 minor 1
/dev/mapper/crypt0p2 major 253 minor 2

/dev/md0 major 9 minor 0

/etc/crypttab contains:
crypt0  /dev/md0

/etc/fstab contains in part:
/dev/mapper/crypt0p1  /hd1  ext4  defaults  0  0
/dev/mapper/crypt0p2  /hd2  ext4  defaults  0  0

/proc/mdstat shows md0 as an active array with 2 devices sda3 sdb3

REBOOT

The encrypted partitions don't survive or are not recreated after reboot

Mount of /hd1 /hd2 fails stating the special devices /dev/mapper/crypt0p1 &
p2 don't exist

The following exist after the reboot...

/dev/dm-0  major 253 minor 0
(no dm-1 dm-2)

/dev/mapper/control (character file)
/dev/mapper/crypt0  -->>  ../dm-0

/dev/md0 major 9 minor 0

The encrypted partitions don't survive or or not recreated after reboot

Some shot-in-the-dark variations of /etc/crypttab lines that didn't work...

crypt0      /dev/mdo
crypt0p1    /dev/md0
crypt0p2    /dev/md0
crypt0p1    /dev/mapper/crypt0
crypt0p2    /dev/mapper/crypt0


In other trials I don't have any problems keeping partitions of a RAID device
across reboots if I don't encrypt.  That is, the devices

/dev/md0
/dev/md0p1
/dev/md0p2

would all hang around for the new party after the reboot and their associated
file systems automatically mount without problems.

The problem is getting the dm-crypt mapping to work after a reboot.

Perhaps I'm extending this idea of partitioning and devices
beyond what is intended and I don't really understand what is meant by "partitioning" RAID devices.

Any advice or references to other documentation is appreciated.

--------------------

Alien Bob 07-27-2012 04:31 AM
What command did you use to create the necessary initrd?

Eric

TracyTiger 07-27-2012 10:53 AM
I didn't know that initrd was necessary since I'm NOT doing this on the root partition.

I initially tried this on the root partition using:

mkinitrd -c -k 2.6.37.6 -m ext4:ehci-hcd:uhci-hcd:usbhid -f ext4 -C /dev/md2 -r cryptroot1 -R

... where md1 is an unencrypted boot RAID device and md2 is the RAID LUKS root partition.

But in this case I'm just experimenting with the HUGE kernel on a non-root partition.

I started out a few days ago trying to do this with the root partition (and mkinitrd) but found when it failed and I restarted the system from a DVD, that I couldn't mount the device & file system to explore/fix so I would have had to reinstall Slack with every trial. I backed off to a simpler set up just trying to mount something on /hd1 /hd2 until I can find out how to get the block devices to exist after reboot.

I'll try it using an initrd and the generic kernel that comes with 13.37.

Alien Bob 07-27-2012 01:08 PM
Try running "/usr/share/mkinitrd/mkinitrd_command_generator.sh" and check the output of that command (it does not do anything, it just shows a working mkinitrd command). It may be of help.

Eric

TracyTiger 07-29-2012 08:57 PM
No Success
 
I've been unable to use the partitions of LUKS enabled RAID device.

I used the mkinitrd command generator recommended and saw that I had not tried the "-u" option.

Whether using the huge kernel and no initrd or using the generic kernel with initrd I haven't been able to create the /dev/mapper/xxx devices needed for the partitions. I can create the raid device /dev/md0 and the LUKS opened device /dev/mapper/luksmd0. I just cannot have the system create (after a reboot) the subsequent devices needed for the partitions. /dev/mapper/luksmd0p1 & p2.

I used the following command to create the initrd resulting in the default named device luksmd0.
Code:
mkinitrd -c -k 2.6.37.6 -m ext4:ehci-hcd:uhci-hdc:usbhid -f ext4 -C /dev/md0 -r /dev/sda1 -u -R
"fdisk -l" shows disk /dev/mapper/luksmd0 with 2 partitions: /dev/mapper/luksmd0p1 and /dev/mapper/luksmd0p2. So as far as I can tell, these two devices need to exist in order to mount the partitions just like /dev/sda1 needs to exist to use the partitions of /dev/sda.

Neither entries in /etc/crypttab nor the multiple colon separated arguments I've tried to "-C" in the mkinitrd command have led to success. Since the whole idea is to use a single key to unlock a single LUKS enabled device, I didn't think they would work.

As I mentioned before, the RAID partitions work if dm-crypt is not used.

With the current boot/load process perhaps it's not (easily) possible to use partitions of a LUKS enabled RAID device.

Lack of partitioning LUKS enabled RAID devices isn't a show stopper as I can still use the method of partitioning the disk first to create the RAID devices which are then LUKS enabled and a file system created. It just involves multiple keys. And LVM still works fine with a single key on RAID with LUKS.


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