Hi list, whenever I setup a crypt mapping with cryptsetup, an inode for the new crypto mappings blockdevice is created as expected. What is not created are the inodes for the partitions within the encrypted volume. >From what I could see in the uevent/udev communication cryptsetup only triggers an event for the creation of the (virtual) disk. Now, mdadm has a command line option, which triggers the creation of partition inodes, then again, they are created blindly, without really checking which of the partitions are there. Obviously there seems to be a general deficit in the udev/virtual volume handling, as I assume. The question is, how this problem can be resolved. A udev rule on it's own doesn't seem to be able to fix this problem. The question is, who should be responsible for the detection of partition within newly created volumes (this is pretty much true for mdadm, lvm, dmcrypt). The kernel has the code anyway, would it be feasable for cryptsetup to ask the kernel to scan a newly created virtual device and take action? Remember, there's not just partition table formats, but also disklabels etc. which could exist within an encrypted volume (Thinking further, if a md or lvm signature would be found they could be handled automaticly too right away). Or should all this be moved to some detection tool (something like vol_id which is used for UUID retrieval)? I wasn't sure where to direct this, because this is a design question involving different parts of the kernel, as well as devicemapper, dmcrypt/cryptsetup, mdraid etc. - I think this should be worked out and fixed in a generic solution suitable for everything surrounding virtual disks. Regards -Sven --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
