Hi, Am Friday 20 February 2009 11:50:48 schrieb Wearenotalone: > Yesterday i continued looking for a solution to my problem. At first i > changed my <volume> definition to > > <volume fskeycipher="aes-256-cbc" fskeyhash="sha512" > options="fsk_cipher=aes-256-cbc,fsk_hash=sha512,keyfile=/my/encrypted.key,f >sck,noexec,nodev,nosuid,relatime,cipher=aes-cbc-essiv:sha256,keybits=256,has >h=sha512" fskeypath="/my/encrypted.key" user="MYUSERNAME" mountpoint="/mnt" > path="/my/encrypted.img" /> Was there a mount error without the changes? The options fsk_cipher and fsk_hash are duplicates of fskeycipher and fskeyhash, so I am wondering why you added them.
> After this unsatisfactory result i updated libpam-mount to version 1.18 Please test with official Debian packages, unless you want to take this problem to the official mailing list. I will package libpam-mount >> 1.10 when there is a safe upgrade path for the new cmtab code (ie.a fallback to mtab). > But why is a loop device attached to my LUKS partition? Is it not enough > if only the LUKS partition is mounted and not another loop device on top > of it? What is your exact setup after mounting? I assume the following /my/encrypted.img ----> (loop) /dev/loop0 ----> (luks) /dev/mapper/_my_enrypted_img ----> (loop) /dev/loop1 If this is the case, the second /dev/loop1 mount is indeed unneeded. > At the moment i am searching for the place in the sources where the > (second) loop device (/dev/loop1) is attached to my LUKS partition. Do > you have a hint where i could search? Is this only occuring in the 1.18 codebase, or in 1.10 also? Regards, Bastian
signature.asc
Description: This is a digitally signed message part.
