On 1/4/07, Martin Michlmayr <tbm@xxxxxxxxxx> wrote:
* Clemens Fruhwirth <clemens@xxxxxxxxxxxxx> [2007-01-04 12:56]:
> So, can we close the bug against cryptsetup in this case?
#403426 is really about the header corruption which you have fixed in
SVN. It should be closed when the Debian maintainers make a new
upload with that fix.
> Maybe someone else can verify that?
CCing Gordon. :)
Ok, so here are some interesting results...
I am able to access the LUKS partition on the NSLU2 running 2.6.18
from subversion (which includes flush_anon_page-generic.patch and
flush_anon_page-arm.patch) with both cryptsetup-1.0.4-8 (the latest
version in testing) and cryptsetup-1.0.4-8 plus 02_fix_arm.dpatch and
03_no_header_conv.dpatch that were posted to this thread.
$ sudo cryptsetup luksOpen /dev/sdb3 testfs
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.
gordon@LKG7102D7:~$ sudo mount /dev/mapper/testfs /mnt/tmp
gordon@LKG7102D7:~$ sudo umount /mnt/tmp
gordon@LKG7102D7:~$ sudo cryptsetup luksClose testfs
However, I have found that I am unable to access the LUKS partition
when the system is under heavy load and swapping.
$ sudo cryptsetup luksOpen /dev/sdb3 testfs
Enter LUKS passphrase:
Enter LUKS passphrase:
Enter LUKS passphrase:
Command failed: No key available with this passphrase.
gordon@LKG7102D7:~$ uptime
00:22:23 up 16 min, 2 users, load average: 3.01, 1.85, 0.93
gordon@LKG7102D7:~$ free
total used free shared buffers cached
Mem: 29988 28908 1080 0 172 3028
-/+ buffers/cache: 25708 4280
Swap: 88316 67508 20808
Once the system load decreases and the swapping stops, I am able to
access the LUKS partition again. This behaviour is very repeatable.
Martin, I wonder if this has anything to do with the virtual memory
bug in the kernel that we experienced with apt. It could be that this
bug existed before 2.6.19 but was much harder to trigger (e.g. see
http://lkml.org/lkml/2007/1/3/285). It would be interesting to try
accessing a LUKS partition under heavy load while running 2.6.20-git,
but that will have to wait until the weekend for me to test it.
Gordon
--
Gordon Farquharson
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
