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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
