Bug#444914: [Pkg-cryptsetup-devel] Bug#444914: temporary-cryptsetup-$$ files appear in /dev/mapper
On 17/10/2007 David Härdeman wrote: > On Tue, October 16, 2007 20:16, Dick Middleton wrote: > > Jonas Meurer wrote: > >> I prepared cryptsetup packages with the proposed patch applied. could > >> you give them a try? > > > > I'll try it a bit more determinedly later but the initial signs are good. > > That's good to hear. > > Jonas, the race condition still remains in libdevmapper, this fix works > around it for cryptsetup so it still needs to be fixed in libdevmapper. I > say we reassign this bug, keep an eye on it and remove the Novell patch > once libdevmapper is fixed. Do you agree? Hey David, indeed your proposed solution sounds very sensible. except that we maybe should clone the bugreport first, reassign the original to devmapper and close the cloned one within the changelog. This way we document somewhere what the purpose of the udevsettle workaround/patch was. greetings, jonas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444914: [Pkg-cryptsetup-devel] Bug#444914: temporary-cryptsetup-$$ files appear in /dev/mapper
On Tue, October 16, 2007 20:16, Dick Middleton wrote: > Jonas Meurer wrote: >> I prepared cryptsetup packages with the proposed patch applied. could >> you give them a try? >> >> you can find them at http://people.debian.org/~mejo/cryptsetup/ > > I tried that; It works for me! Well ... er, I tried 4 times and rebuilt > initrd > which also worked properly. I noticed the passphrase prompt also comes > out > after the USB messages - is that something else you changed or was I just > lucky? Can't check now but I seem to recall that the initramfs scripts also run udevsettle now to give the device detection a chance to calm down. In the future the kernel will get capabilities to allow udev to know when it is done probing hardware (I think you could search LKML for "scsi_wait" if you're interested). > I'll try it a bit more determinedly later but the initial signs are good. That's good to hear. Jonas, the race condition still remains in libdevmapper, this fix works around it for cryptsetup so it still needs to be fixed in libdevmapper. I say we reassign this bug, keep an eye on it and remove the Novell patch once libdevmapper is fixed. Do you agree? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444914: [Pkg-cryptsetup-devel] Bug#444914: temporary-cryptsetup-$$ files appear in /dev/mapper
David Härdeman wrote: The problem seems to be documented here (and the ubuntu patch to libdevmapper seems to contain some relevant code): https://wiki.ubuntu.com/UdevDeviceMapper So, I'm CC:ing the maintainers for libdevmapper and udev to ask their advice before I reassign this BR. Have you seen this? https://bugzilla.novell.com/show_bug.cgi?id=285478 Dick
Bug#444914: [Pkg-cryptsetup-devel] Bug#444914: temporary-cryptsetup-$$ files appear in /dev/mapper
On Oct 05, David Härdeman <[EMAIL PROTECTED]> wrote: > The problem seems to be documented here (and the ubuntu patch to > libdevmapper seems to contain some relevant code): > https://wiki.ubuntu.com/UdevDeviceMapper All of this needs to be fixed in the lvm packages, udev does not ship any rules which interfere with the proposed solution. -- ciao, Marco signature.asc Description: Digital signature
Bug#444914: [Pkg-cryptsetup-devel] Bug#444914: temporary-cryptsetup-$$ files appear in /dev/mapper
On Mon, October 1, 2007 21:16, Dick Middleton wrote: > Package: cryptsetup > Version: 2:1.0.5-2 > Severity: important > > > I have a curious effect; sometimes I get an error with luksOpen such as > this: > > Failed to setup dm-crypt key mapping. > Check kernel for support for the aes-cbc-plain cipher spec and verify that > /dev/mapper/vg02-devil contains at least 261 sectors. > Failed to read from key storage > Command failed: No key available with this passphrase. > > None of these problems exist - it's a perfectly valid luks partition > so the cause remains a mystery for the moment however: > > On a subsequent attempt to luksOpen it will most likely succeed but > there then remains a file /dev/mapper/temporary-cryptsetup-$$ where $$ > is obviously a process number. This file can be removed with a > luksClose. > > To reiterate, this file remains after a subsequent successful attempt > not after the preceeding failure. > > This problem has only appeared on my system after upgrading the > hardware from a k7 system to an amd64 system and changing to a Debian > stock kernel (2.6.22-2-amd64) rather than a home brew (2.6.19) one. Ok, I've compared the two strace logs (they can be found in the bug report) and the error in the failure log seems to be at line 287 where some process has opened the temporary device that libdevmapper created (meaning libdevmapper can't remove it and errors out). I believe that you're seeing a race between libdevmapper and udev in the creation of the dm-* devices (and you probably see it now because you have a faster machine). The problem seems to be documented here (and the ubuntu patch to libdevmapper seems to contain some relevant code): https://wiki.ubuntu.com/UdevDeviceMapper So, I'm CC:ing the maintainers for libdevmapper and udev to ask their advice before I reassign this BR. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444914: [Pkg-cryptsetup-devel] Bug#444914: temporary-cryptsetup-$$ files appear in /dev/mapper
David Härdeman wrote:
Thanks, could you now do one more thing for me? A strace from a successful
invocation would be nice for comparison (I assume you've setup a test
partition for this considering the "testpwd" password that you use).
No, it's real; I just added a new password. Don't worry, I'll rebuild the
partition later.
Dick
Penguin(root):~/Downloads# Penguin(root):~/Downloads# echo "testpwd" | strace
cryptsetup luksOpen /dev/mapper/vg02-devil devil
execve("/sbin/cryptsetup", ["cryptsetup", "luksOpen", "/dev/mapper/vg02-devil",
"devil"], [/* 34 vars */]) = 0
brk(0) = 0x80a1000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7f74000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=79181, ...}) = 0
mmap2(NULL, 79181, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f6
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libpopt.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\22\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=26444, ...}) = 0
mmap2(NULL, 29484, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7f58000
mmap2(0xf7f5f000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xf7f5f000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libdevmapper.so.1.02.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220/\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=84800, ...}) = 0
mmap2(NULL, 83672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7f43000
mmap2(0xf7f56000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13) = 0xf7f56000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libuuid.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\t\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=8572, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7f42000
mmap2(NULL, 11504, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7f3f000
mmap2(0xf7f41000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xf7f41000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260a\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1335912, ...}) = 0
mmap2(NULL, 1340944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7df7000
mmap2(0xf7f39000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x142) = 0xf7f39000
mmap2(0xf7f3c000, 9744, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7f3c000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libselinux.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320>\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=83512, ...}) = 0
mmap2(NULL, 88980, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7de1000
mmap2(0xf7df5000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13) = 0xf7df5000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libsepol.so.1", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2204\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=220764, ...}) = 0
mmap2(NULL, 266048, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7da
mmap2(0xf7dd6000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x35) = 0xf7dd6000
mmap2(0xf7dd7000, 40768, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7dd7000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\000"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9684, ...}) = 0
mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7d9c000
mmap2(0xf7d9e000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xf7d9e000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7d9b000
set_threa
Bug#444914: [Pkg-cryptsetup-devel] Bug#444914: temporary-cryptsetup-$$ files appear in /dev/mapper
On Wed, October 3, 2007 10:39, Dick Middleton wrote:
> David Härdeman wrote:
>>> strace echo -n x| cryptsetup luksOpen /dev/mapper/vg02-devil
>>> devil
>>
>> Sorry, but you need to have the strace call on the right hand side of
>> the
>> pipe ("echo -n xxx | strace ..."). Could you please try again?
>
>> And it didn't seem to reproduce the same error (probably because you
>> used
>> a dummy password here).
>
> Try this one - it didn't come so easily this morning.
Thanks, could you now do one more thing for me? A strace from a successful
invocation would be nice for comparison (I assume you've setup a test
partition for this considering the "testpwd" password that you use).
--
David Härdeman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444914: [Pkg-cryptsetup-devel] Bug#444914: temporary-cryptsetup-$$ files appear in /dev/mapper
David Härdeman wrote:
strace echo -n x| cryptsetup luksOpen /dev/mapper/vg02-devil devil
Sorry, but you need to have the strace call on the right hand side of the
pipe ("echo -n xxx | strace ..."). Could you please try again?
And it didn't seem to reproduce the same error (probably because you used
a dummy password here).
Try this one - it didn't come so easily this morning.
Dick
Penguin(root):/etc/cron.daily# echo "testpwd" | strace cryptsetup luksOpen
/dev/mapper/vg02-devil devil | tee /tmp/errlog
execve("/sbin/cryptsetup", ["cryptsetup", "luksOpen", "/dev/mapper/vg02-devil",
"devil"], [/* 31 vars */]) = 0
brk(0) = 0x80a1000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7f3b000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=79181, ...}) = 0
mmap2(NULL, 79181, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f27000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libpopt.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\22\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=26444, ...}) = 0
mmap2(NULL, 29484, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7f1f000
mmap2(0xf7f26000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xf7f26000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libdevmapper.so.1.02.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220/\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=84800, ...}) = 0
mmap2(NULL, 83672, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7f0a000
mmap2(0xf7f1d000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13) = 0xf7f1d000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libuuid.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\t\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=8572, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7f09000
mmap2(NULL, 11504, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7f06000
mmap2(0xf7f08000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xf7f08000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260a\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1335912, ...}) = 0
mmap2(NULL, 1340944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7dbe000
mmap2(0xf7f0, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x142) = 0xf7f0
mmap2(0xf7f03000, 9744, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7f03000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libselinux.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320>\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=83512, ...}) = 0
mmap2(NULL, 88980, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7da8000
mmap2(0xf7dbc000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13) = 0xf7dbc000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libsepol.so.1", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\2204\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=220764, ...}) = 0
mmap2(NULL, 266048, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7d67000
mmap2(0xf7d9d000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x35) = 0xf7d9d000
mmap2(0xf7d9e000, 40768, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7d9e000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libdl.so.2", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\000"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0644, st_size=9684, ...}) = 0
mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7d63000
mmap2(0xf7d65000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xf7d65000
close(3)
Bug#444914: [Pkg-cryptsetup-devel] Bug#444914: temporary-cryptsetup-$$ files appear in /dev/mapper
On Wed, October 3, 2007 00:04, Dick Middleton wrote:
> David Härdeman wrote:
>> On Tue, Oct 02, 2007 at 10:10:40PM +0100, Dick Middleton wrote:
>>> David Härdeman wrote:
On Mon, October 1, 2007 21:16, Dick Middleton wrote:
> I have a curious effect; sometimes I get an error with luksOpen such
> as
> this:
>
> Failed to setup dm-crypt key mapping.
>>>
The first message is usually reported when a module is missing, but
then
it is curious that it would work later.
>>>
>>> This is the last of some 5 encrypted partitions that are opened. The
>>> main difference is that it's on a different physical device.
>>
>> Oh, I see, then the tests I suggested are not relevant.
>> (please keep the bug report address in the CC by the way)
>
> Oops, sorry about that.
>
>> It sounds very much like this bug:
>> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/105266
>
> It does look similar.
>
>> Could you please try running crypsetup under strace and capture a failed
>> invocation so that we can compare them?
>
> Is this helpful?
>
> strace echo -n x| cryptsetup luksOpen /dev/mapper/vg02-devil devil
Sorry, but you need to have the strace call on the right hand side of the
pipe ("echo -n xxx | strace ..."). Could you please try again?
> Process 11295 detached
> Failed to setup dm-crypt key mapping.
> Check kernel for support for the aes-cbc-plain cipher spec and verify that
> /dev/mapper/vg02-devil contains at least 261 sectors.
> Failed to read from key storage
> Command failed: No key available with this passphrase.
And it didn't seem to reproduce the same error (probably because you used
a dummy password here).
--
David Härdeman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#444914: [Pkg-cryptsetup-devel] Bug#444914: temporary-cryptsetup-$$ files appear in /dev/mapper
On Tue, Oct 02, 2007 at 11:04:13PM +0100, Dick Middleton wrote: > Is this helpful? Could have been, but you got the wrong trace. :) > strace echo -n x| cryptsetup luksOpen /dev/mapper/vg02-devil devil Please try the following: echo -n x | strace cryptsetup luksOpen /dev/mapper/vg02-devil devil Thanks, -- Jérémy Bobbio.''`. [EMAIL PROTECTED]: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#444914: [Pkg-cryptsetup-devel] Bug#444914: temporary-cryptsetup-$$ files appear in /dev/mapper
David Härdeman wrote:
On Tue, Oct 02, 2007 at 10:10:40PM +0100, Dick Middleton wrote:
David Härdeman wrote:
On Mon, October 1, 2007 21:16, Dick Middleton wrote:
I have a curious effect; sometimes I get an error with luksOpen such as
this:
Failed to setup dm-crypt key mapping.
The first message is usually reported when a module is missing, but then
it is curious that it would work later.
This is the last of some 5 encrypted partitions that are opened. The
main difference is that it's on a different physical device.
Oh, I see, then the tests I suggested are not relevant.
(please keep the bug report address in the CC by the way)
Oops, sorry about that.
It sounds very much like this bug:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/105266
It does look similar.
Could you please try running crypsetup under strace and capture a failed
invocation so that we can compare them?
Is this helpful?
strace echo -n x| cryptsetup luksOpen /dev/mapper/vg02-devil devil
execve("/bin/echo", ["echo", "-n", "x"], [/* 33 vars */]) = 0
brk(0) = 0x804d000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7f27000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=79181, ...}) = 0
mmap2(NULL, 79181, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f13000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260a\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1335912, ...}) = 0
mmap2(NULL, 1340944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xf7dcb000
mmap2(0xf7f0d000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x142) = 0xf7f0d000
mmap2(0xf7f1, 9744, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7f1
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7dca000
set_thread_area({entry_number:-1 -> 12, base_addr:0xf7dca6b0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0xf7f0d000, 4096, PROT_READ) = 0
munmap(0xf7f13000, 79181) = 0
brk(0) = 0x804d000
brk(0x806e000) = 0x806e000
fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xf7f26000
write(1, "x", 5)= 5
close(1)= 0
munmap(0xf7f26000, 4096)= 0
exit_group(0) = ?
Process 11295 detached
Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-cbc-plain cipher spec and verify that
/dev/mapper/vg02-devil contains at least 261 sectors.
Failed to read from key storage
Command failed: No key available with this passphrase.
Dick
Bug#444914: [Pkg-cryptsetup-devel] Bug#444914: temporary-cryptsetup-$$ files appear in /dev/mapper
On Tue, Oct 02, 2007 at 10:10:40PM +0100, Dick Middleton wrote: David Härdeman wrote: On Mon, October 1, 2007 21:16, Dick Middleton wrote: I have a curious effect; sometimes I get an error with luksOpen such as this: Failed to setup dm-crypt key mapping. The first message is usually reported when a module is missing, but then it is curious that it would work later. This is the last of some 5 encrypted partitions that are opened. The main difference is that it's on a different physical device. Oh, I see, then the tests I suggested are not relevant. (please keep the bug report address in the CC by the way) The effect I was getting would recur by doing a sequence of several Open Close cycles in quick succession. From that it doesn't sound like a missing module problem. As a test, could you do the following: Tricky, the first invocation is in initrd. That usually fails though so I need to do some work to prove the point. I've just tried doing this again tonight and I've had no Open failures but I'm still getting the occasional (i.e. doesn't happen every time) temporary file created. There's this error in dmesg: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-7228 Sounds like a race condition in device-mapper, not in cryptsetup. Perhaps the creation of the device-mapper node is noted by something (my guess would be udev, which likes to inspect new device nodes) which open()'s the device node before device-mapper gets to delete it... It sounds very much like this bug: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/105266 Could you please try running crypsetup under strace and capture a failed invocation so that we can compare them? Please scan the strace log to make sure it doesn't include any encryption keys or other sensitive data before posting it. -- David Härdeman
Bug#444914: [Pkg-cryptsetup-devel] Bug#444914: temporary-cryptsetup-$$ files appear in /dev/mapper
On Mon, October 1, 2007 21:16, Dick Middleton wrote: > I have a curious effect; sometimes I get an error with luksOpen such as > this: > > Failed to setup dm-crypt key mapping. > Check kernel for support for the aes-cbc-plain cipher spec and verify that > /dev/mapper/vg02-devil contains at least 261 sectors. > Failed to read from key storage > Command failed: No key available with this passphrase. > > None of these problems exist - it's a perfectly valid luks partition > so the cause remains a mystery for the moment however: > > On a subsequent attempt to luksOpen it will most likely succeed but > there then remains a file /dev/mapper/temporary-cryptsetup-$$ where $$ > is obviously a process number. This file can be removed with a > luksClose. The first message is usually reported when a module is missing, but then it is curious that it would work later. As a test, could you do the following: 1) Before the first invocation, get a list of loaded modules (lsmod > modules.pre) 2) Do the two luksOpen attempts (the one that fails and the one that works) 3) Get a list of loaded modules afterwards (lsmod > modules.post) 4) Compare them (diff -u modules.pre modules.post) 5) If modules have been added, please try adding them to /etc/modules, reboot and try luksOpen again, if it works on the first attempt, something fishy is going on with the auto-module loading (i.e. that the libdevmapper code is being too impatient). -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
