Bug#393728: dm-crypt on raid does not play nicely

[Max Vozeler <max@nusquama.org>]

Hi all,

On Tue, Oct 17, 2006 at 05:35:24PM +0200, Miroslav Kure wrote:
> I installed from today's i386 netinst (20061016) with the following
> setup:
> 
> /dev/hda1   16MB /boot
> /dev/hda2  500MB physical volume for raid
> 
> /dev/hdb1   16MB unused
> /dev/hdb2  500MB physical volume for raid
> 
> RAID 1 was created from /dev/hda2 and /dev/hdb2 and on the top of it
> dm-crypt partition was created with all defaults.
> 
> After returning from "Configure encrypted volumes" the new device
> md0_crypt was created as expected, but there was no "partition" inside
> it to use.
> 
> I had to press enter on the md0_crypt device itself and it offered me
> to create new partition table, which in turn created free space, which
> then I was able to partition. (Quite surprised as I did not see this
> with partman-crypto yet.) 

I think I've tracked down at least part of the problem.

When you select "Configure encrypted volumes", partman-crypto creates
the dm-crypt mapping, creates a crypt_active file inside the partman
directory of /dev/md0 and goes to restart partman. Normally the partman
device directories are then restored in init.d/30parted, but /dev/md*
are explicitly excluded from it.

The directories for /dev/md* are instead recreated from scratch in
init.d/31md-devices. This looses all settings stored in the directory,
including the method and crypt_active files, which serve as indicator
for init.d/51crypto that it needs to create a partman disk along with a
"loop"-type partition table on it. Instead, it just ignores the device
and leaves "detecting" it to partman.

Since there is no existing partition table, partman asks to create a
new one. Unless you selected a "loop"-type partition table, this can in
turn allow to create multiple partitions on the dm-crypt device - which
I think is not actually possible to do with plain dm-crypt devices
(without LVM, that is). So I think this at least explains why partman
allowed but handled this setup incorrectly.

I'm not sure how we can fix this, though. The current way -md works
is to recreate partman devices on each restart, while -crypto relies 
on them being restored. Changing this, I think, implies fundamental
changes to either -dm or -crypto, which is probably out of scope for 
the moment, at least before the etch release.

For the moment, I actually think it would be best to not offer
crypto-on-dm setups to prevent this problem. 

cheers,
Max