Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
reassign 409875 libdevmapper1.02 retitle 409875 libdevmapper should provide more helpful error messages severity 409875 minor thanks On Fri, Feb 09, 2007 at 09:44:32PM +0100, Johannes Schlumberger wrote: Thanks, this looks mighty suspicious...it looks like /dev/md0 is mounted as your root partition by the initramfs? Please provide me with "ls -al /dev/root" and "cat /proc/cmdline" as well as the contents of your grub or lilo config file. I am so sorry for stealing yours and other persons time like this. I had root=/dev/md0 in my menu.lst and / as /dev/hdd6 in my fstab. I have to say I am strongly embarassed. No problem, it happends to all of us. There still is a bug here though...the error messages from libdevmapper are obtuse to say the least. libdevmapper explained that /dev/md0 is in use with the message: "Command failed: device-mapper: reload ioctl failed: Invalid argument" That is a bug in my book. I'll reassign this bug to libdevmapper (and retitle it accordingly). I'll also CC all people that I've bugged earlier so that they know that this issue is no more. Thank you a lot for figuring this out and all your patience. That's ok, you just owe me a beer. -- David Härdeman
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Hi, > Thanks, this looks mighty suspicious...it looks like /dev/md0 is mounted > as your root partition by the initramfs? Please provide me with "ls -al > /dev/root" and "cat /proc/cmdline" as well as the contents of your grub > or lilo config file. I am so sorry for stealing yours and other persons time like this. I had root=/dev/md0 in my menu.lst and / as /dev/hdd6 in my fstab. I have to say I am strongly embarassed. Thank you a lot for figuring this out and all your patience. best regards, Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
On Fri, Feb 09, 2007 at 07:35:46PM +0100, Johannes Schlumberger wrote:
Hi,
Meanwhile, could you add the following to the above mentioned debugging
output:
printk("dumping stack for %s:\n", current->comm);
dump_stack();
(right after the above printk in bd_claim())
And then send another dmesg this way...this should tell us which
process/kernel thread it is that locks md0...
As it turns out, dmesg is to small, so i have attached the relevant part of my
syslog file.
Thanks, this looks mighty suspicious...it looks like /dev/md0 is mounted
as your root partition by the initramfs? Please provide me with "ls -al
/dev/root" and "cat /proc/cmdline" as well as the contents of your grub
or lilo config file.
--
David Härdeman
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Hi,
> Meanwhile, could you add the following to the above mentioned debugging
> output:
>
> printk("dumping stack for %s:\n", current->comm);
> dump_stack();
>
> (right after the above printk in bd_claim())
>
> And then send another dmesg this way...this should tell us which
> process/kernel thread it is that locks md0...
As it turns out, dmesg is to small, so i have attached the relevant part of my
syslog file.
regards,
Johannes
Feb 9 19:31:21 asso syslogd 1.4.1#20: restart.
Feb 9 19:31:21 asso kernel: klogd 1.4.1#20, log source = /proc/kmsg started.
Feb 9 19:31:21 asso kernel: dc>] __link_path_walk+0xb1e/0xb40
Feb 9 19:31:21 asso kernel: [] mntput_no_expire+0x11/0x59
Feb 9 19:31:21 asso kernel: [] link_path_walk+0xaf/0xb9
Feb 9 19:31:21 asso kernel: [] extract_entropy+0x4a/0xa6
Feb 9 19:31:21 asso kernel: [] flush_cpu_workqueue+0x6e/0x75
Feb 9 19:31:21 asso kernel: [] do_path_lookup+0x14f/0x16a
Feb 9 19:31:21 asso kernel: [] getname+0x59/0x8f
Feb 9 19:31:21 asso kernel: [] __user_walk_fd+0x3d/0x45
Feb 9 19:31:21 asso kernel: [] sys_faccessat+0x96/0x134
Feb 9 19:31:21 asso kernel: [] extract_entropy+0x4a/0xa6
Feb 9 19:31:21 asso kernel: [] prepare_namespace+0x42/0x15e
Feb 9 19:31:21 asso kernel: [] sys_access+0x1f/0x23
Feb 9 19:31:21 asso kernel: [] init+0x16a/0x237
Feb 9 19:31:21 asso kernel: [] ret_from_fork+0x6/0x1c
Feb 9 19:31:21 asso kernel: [] init+0x0/0x237
Feb 9 19:31:21 asso kernel: [] init+0x0/0x237
Feb 9 19:31:21 asso kernel: [] kernel_thread_helper+0x7/0x10
Feb 9 19:31:21 asso kernel: ===
Feb 9 19:31:21 asso kernel: md: running:
Feb 9 19:31:21 asso kernel: raid1: raid set md0 active with 2 out of 2 mirrors
Feb 9 19:31:21 asso kernel: md: ... autorun DONE.
Feb 9 19:31:21 asso kernel: claim: 9:0 c04be600 -> 0
Feb 9 19:31:21 asso kernel: dumping stack for swapper:
Feb 9 19:31:21 asso kernel: [] bd_claim+0x90/0x98
Feb 9 19:31:21 asso kernel: [] open_bdev_excl+0x50/0x65
Feb 9 19:31:21 asso kernel: [] get_sb_bdev+0x14/0x11c
Feb 9 19:31:21 asso kernel: [] link_path_walk+0xaf/0xb9
Feb 9 19:31:21 asso kernel: [] ramfs_mknod+0x6a/0x8b
Feb 9 19:31:21 asso kernel: [] ext3_get_sb+0x20/0x25
Feb 9 19:31:21 asso kernel: [] ext3_fill_super+0x0/0x133e
Feb 9 19:31:21 asso kernel: [] vfs_kern_mount+0x83/0xf6
Feb 9 19:31:21 asso kernel: [] do_kern_mount+0x2d/0x3e
Feb 9 19:31:21 asso kernel: [] do_mount+0x5bb/0x62e
Feb 9 19:31:21 asso kernel: [] dput+0x1a/0x10b
Feb 9 19:31:21 asso kernel: [] __link_path_walk+0xa6f/0xb40
Feb 9 19:31:21 asso kernel: [] __d_lookup+0x8d/0xc1
Feb 9 19:31:21 asso kernel: [] do_lookup+0x4f/0x140
Feb 9 19:31:21 asso kernel: [] dput+0x1a/0x10b
Feb 9 19:31:21 asso kernel: [] __link_path_walk+0xa6f/0xb40
Feb 9 19:31:21 asso kernel: [] __link_path_walk+0xa6f/0xb40
Feb 9 19:31:21 asso kernel: [] ramfs_mknod+0x6a/0x8b
Feb 9 19:31:21 asso kernel: [] vfs_mknod+0x128/0x136
Feb 9 19:31:21 asso kernel: [] __get_free_pages+0x1a/0x33
Feb 9 19:31:21 asso kernel: [] copy_mount_options+0x26/0x106
Feb 9 19:31:21 asso kernel: [] sys_mount+0x72/0xa9
Feb 9 19:31:21 asso kernel: [] mount_block_root+0xc5/0x210
Feb 9 19:31:21 asso kernel: [] sys_mknod+0x27/0x2b
Feb 9 19:31:21 asso kernel: [] mount_root+0x89/0x9d
Feb 9 19:31:21 asso kernel: [] prepare_namespace+0x118/0x15e
Feb 9 19:31:21 asso kernel: [] sys_access+0x1f/0x23
Feb 9 19:31:21 asso kernel: [] init+0x16a/0x237
Feb 9 19:31:21 asso kernel: [] ret_from_fork+0x6/0x1c
Feb 9 19:31:21 asso kernel: [] init+0x0/0x237
Feb 9 19:31:21 asso kernel: [] init+0x0/0x237
Feb 9 19:31:21 asso kernel: [] kernel_thread_helper+0x7/0x10
Feb 9 19:31:21 asso kernel: ===
Feb 9 19:31:21 asso kernel: kjournald starting. Commit interval 5 seconds
Feb 9 19:31:21 asso kernel: EXT3-fs: mounted filesystem with ordered data mode.
Feb 9 19:31:21 asso kernel: VFS: Mounted root (ext3 filesystem) readonly.
Feb 9 19:31:21 asso kernel: Freeing unused kernel memory: 212k freed
Feb 9 19:31:21 asso kernel: claim: 9:0 f726f520 -> -16
Feb 9 19:31:21 asso kernel: dumping stack for fsck.ext3:
Feb 9 19:31:21 asso kernel: [] bd_claim+0x90/0x98
Feb 9 19:31:21 asso kernel: [] blkdev_open+0x3a/0x4d
Feb 9 19:31:21 asso kernel: [] __dentry_open+0xb7/0x186
Feb 9 19:31:21 asso kernel: [] nameidata_to_filp+0x24/0x33
Feb 9 19:31:21 asso kernel: [] do_filp_open+0x32/0x39
Feb 9 19:31:21 asso kernel: [] do_sys_open+0x42/0xc3
Feb 9 19:31:21 asso kernel: [] sys_open+0x1c/0x1e
Feb 9 19:31:21 asso kernel: [] sysenter_past_esp+0x56/0x79
Feb 9 19:31:21 asso kernel: ===
Feb 9 19:31:21 asso kernel: EXT3 FS on md0, internal journal
Feb 9 19:31:21 asso kernel: claim: 9:0 f75e5aa0 -> -16
Feb 9 19:31:21 asso kernel: dumping stack for mdadm:
Feb 9 19:31:21 asso kernel: [] bd_claim+0x90/0x98
Feb 9 19:31:21 asso kernel: [] blkdev_open+0x3a/0x4d
Feb 9 19:31:21 asso kernel: [] __dentry_open+0xb7/0x186
Feb 9 19:31:21 asso
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
On Fri, February 9, 2007 16:58, Johannes Schlumberger said:
>> Could you please try a new compile, this time, skip the previously
>> mentioned patch and instead do the following changes:
>>
>> In fs/block_dev.c, add the following at the end of the function
>> bd_claim()
>> (just before the return):
>>
>> printk("claim: %d:%d %p -> %d\n",
>>MAJOR(bdev->bd_dev), MINOR(bdev->bd_dev), holder, res);
>>
>> In the same file, add to the end of the function bd_release():
>>
>> printk("release: %d:%d\n",
>>MAJOR(bdev->bd_dev), MINOR(bdev->bd_dev));
>>
>> Recompile, install, reboot, try cryptsetup, and then send me the entire
>> dmesg output
>
> It is attached; the way I see it, 9:0 is claimed during the setup of the
> md-device but never released.
Yes, that indeed seems to be the problem (which is why we tried this
debugging output)...and later device-mapper tries to claim md0 again as it
tries to setup the crypto mapping. Which fails. What bothers me though is
that the previous patch that we tried should have allowed such situations,
I might have to take another look at it.
Meanwhile, could you add the following to the above mentioned debugging
output:
printk("dumping stack for %s:\n", current->comm);
dump_stack();
(right after the above printk in bd_claim())
And then send another dmesg this way...this should tell us which
process/kernel thread it is that locks md0...
--
David Härdeman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
On Fri, February 9, 2007 14:42, Johannes Schlumberger said:
> Hi,
> I just want to point out, so far after each test I brought the system back
> into the beginning state (kernel, dmsetup-package, etc).
Yes, that's good.
Could you please try a new compile, this time, skip the previously
mentioned patch and instead do the following changes:
In fs/block_dev.c, add the following at the end of the function bd_claim()
(just before the return):
printk("claim: %d:%d %p -> %d\n",
MAJOR(bdev->bd_dev), MINOR(bdev->bd_dev), holder, res);
In the same file, add to the end of the function bd_release():
printk("release: %d:%d\n",
MAJOR(bdev->bd_dev), MINOR(bdev->bd_dev));
Recompile, install, reboot, try cryptsetup, and then send me the entire
dmesg output
--
David Härdeman
--
David Härdeman
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Hi,
> > I just want to point out, so far after each test I brought the system back
> > into the beginning state (kernel, dmsetup-package, etc).
>
> Yes, that's good.
I just wanted to make shure, we are stil talking about the same setup :)
> Could you please try a new compile, this time, skip the previously
> mentioned patch and instead do the following changes:
>
> In fs/block_dev.c, add the following at the end of the function bd_claim()
> (just before the return):
>
> printk("claim: %d:%d %p -> %d\n",
>MAJOR(bdev->bd_dev), MINOR(bdev->bd_dev), holder, res);
>
> In the same file, add to the end of the function bd_release():
>
> printk("release: %d:%d\n",
>MAJOR(bdev->bd_dev), MINOR(bdev->bd_dev));
>
> Recompile, install, reboot, try cryptsetup, and then send me the entire
> dmesg output
It is attached; the way I see it, 9:0 is claimed during the setup of the
md-device but never released.
regarrds,
Johannes
.2-asso-50 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian
4.1.1-21)) #3 Fri Feb 9 16:45:38 CET 2007
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820: 0009fc00 - 000a (reserved)
BIOS-e820: 000f - 0010 (reserved)
BIOS-e820: 0010 - 3fffc000 (usable)
BIOS-e820: 3fffc000 - 3000 (ACPI data)
BIOS-e820: 3000 - 4000 (ACPI NVS)
BIOS-e820: fec0 - fec01000 (reserved)
BIOS-e820: fee0 - fee01000 (reserved)
BIOS-e820: - 0001 (reserved)
Warning only 896MB will be used.
Use a HIGHMEM enabled kernel.
896MB LOWMEM available.
Entering add_active_range(0, 0, 229376) 0 entries of 256 used
Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 -> 229376
early_node_map[1] active PFN ranges
0:0 -> 229376
On node 0 totalpages: 229376
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4064 pages, LIFO batch:0
Normal zone: 1760 pages used for memmap
Normal zone: 223520 pages, LIFO batch:31
DMI 2.3 present.
Using APIC driver default
ACPI: RSDP (v000 ASUS ) @ 0x000f6000
ACPI: RSDT (v001 ASUS A7V8X0x42302e31 MSFT 0x31313031) @ 0x3fffc000
ACPI: FADT (v001 ASUS A7V8X0x42302e31 MSFT 0x31313031) @ 0x3fffc0b2
ACPI: BOOT (v001 ASUS A7V8X0x42302e31 MSFT 0x31313031) @ 0x3fffc030
ACPI: MADT (v001 ASUS A7V8X0x42302e31 MSFT 0x31313031) @ 0x3fffc058
ACPI: DSDT (v001 ASUS A7V8X0x1000 MSFT 0x010b) @ 0x
ACPI: PM-Timer IO Port: 0xe408
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 3, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode: Flat. Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 5000 (gap: 4000:bec0)
Detected 2000.256 MHz processor.
Built 1 zonelists. Total pages: 227584
Kernel command line: root=/dev/md0 ro
mapped APIC to d000 (fee0)
mapped IOAPIC to c000 (fec0)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 904272k/917504k available (3128k kernel code, 12756k reserved, 1152k
data, 212k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xfffb6000 - 0xf000 ( 292 kB)
vmalloc : 0xf880 - 0xfffb4000 ( 119 MB)
lowmem : 0xc000 - 0xf800 ( 896 MB)
.init : 0xc0532000 - 0xc0567000 ( 212 kB)
.data : 0xc040e3b6 - 0xc052e454 (1152 kB)
.text : 0xc010 - 0xc040e3b6 (3128 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 4003.60 BogoMIPS (lpj=8007211)
Security Framework v1.0.0 initialized
SELinux: Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0383fbff c1c3fbff
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0383fbff c1c3fbff 0420
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(TM) XP 2400+ stepping 01
Checking 'hlt' ins
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Hi, I just want to point out, so far after each test I brought the system back into the beginning state (kernel, dmsetup-package, etc). regards, Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Hi, > Could you build a new kernel which includes the patch attached to bug > report #304507 and try again? > > http://bugs.debian.org/cgi-bin/bugreport.cgi/2.6-bd-claim.patch?bug=304507;msg=5;att=1 It sems the same to me. This is kernel -asso-50 (I attached the config to the inital bugreport mail) with the above patch applied. [14:36:[EMAIL PROTECTED]:/home/spjsschl]# cryptsetup -c aes -s 256 -d /dev/stdin create root /dev/md0
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
On Thu, February 8, 2007 22:51, Johannes Schlumberger said: > I built the packages and installed them. > The attached file contains the generated stderr stream (which looks a bit > strange to me). Just to make shure, here is also the output generated from > the command without the redirection. Could you build a new kernel which includes the patch attached to bug report #304507 and try again? http://bugs.debian.org/cgi-bin/bugreport.cgi/2.6-bd-claim.patch?bug=304507;msg=5;att=1 -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
On Thu, Feb 08, 2007 at 07:52:53PM +0100, Johannes Schlumberger wrote:
Hi,
> [22:28:[EMAIL PROTECTED]:/tmp]# echo '0 1 crypt aes-cbc-essiv:sha256 \
> 0123456789abcdef0123456789abcdef 0 /dev/md0 0' > map
> [22:28:[EMAIL PROTECTED]:/tmp]# dmsetup create root map
> device-mapper: reload ioctl failed: Invalid argument
> Command failed
Could you try this again with a couple of "-v" arguments added to the
dmsetup command -> "dmsetup -v -v -v -v -v -v -v -v -v -v create root map"
and see if you get some additional output?
[19:51:[EMAIL PROTECTED]:/tmp]# dmsetup -v -v -v -v -v -v -v -v -v -v create
root \
map
dm version OF [16384]
dm create root OF [16384]
dm reload root OF [16384]
device-mapper: reload ioctl failed: Invalid argument
dm remove root OF [16384]
Command failed
[19:51:[EMAIL PROTECTED]:/tmp]# cat map
0 1 crypt aes-cbc-essiv:sha256 0123456789abcdef0123456789abcdef 0 /dev/md0 0
Hmm...do you know how to build debian packages from source?
It would be great if you could download the devmapper source package
("apt-get source libdevmapper1.02"), edit the file
devmapper-1.02.12/lib/ioctl/libdm-iface.c and add the line:
"fwrite(dmi, dmi->data_size, 1, stderr);"
at line 1553 (just before the "log_debug" statement).
Then build it ("dpkg-buildpackage -us -uc -rfakeroot"), install the
generated debs and try to run dmsetup again (without the -v flags).
Capture stderr to a file and mail it to me (it will contain the
passphrase you used, but for this test that would just be the dummy pass
from the map file).
The command to execute would be:
"dmsetup create root map 2> /tmp/dmsetup.stderr"
--
David Härdeman
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Hi, > > [22:28:[EMAIL PROTECTED]:/tmp]# echo '0 1 crypt aes-cbc-essiv:sha256 \ > > 0123456789abcdef0123456789abcdef 0 /dev/md0 0' > map > > [22:28:[EMAIL PROTECTED]:/tmp]# dmsetup create root map > > device-mapper: reload ioctl failed: Invalid argument > > Command failed > > Could you try this again with a couple of "-v" arguments added to the > dmsetup command -> "dmsetup -v -v -v -v -v -v -v -v -v -v create root map" > and see if you get some additional output? [19:51:[EMAIL PROTECTED]:/tmp]# dmsetup -v -v -v -v -v -v -v -v -v -v create root \ map dm version OF [16384] dm create root OF [16384] dm reload root OF [16384] device-mapper: reload ioctl failed: Invalid argument dm remove root OF [16384] Command failed [19:51:[EMAIL PROTECTED]:/tmp]# cat map 0 1 crypt aes-cbc-essiv:sha256 0123456789abcdef0123456789abcdef 0 /dev/md0 0 Sorry for the delay, I was stuck at university and my PC at home was not running. best regards, Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
On Wed, February 7, 2007 22:31, Johannes Schlumberger said: > Hi, >> Ok, could you create a file called e.g. "map" containing the following >> line: >> 0 1 crypt aes-cbc-essiv:sha256 0123456789abcdef0123456789abcdef 0 >> /dev/md0 0 > > shure. > [22:28:[EMAIL PROTECTED]:/tmp]# echo '0 1 crypt aes-cbc-essiv:sha256 \ > 0123456789abcdef0123456789abcdef 0 /dev/md0 0' > map > [22:28:[EMAIL PROTECTED]:/tmp]# dmsetup create root map > device-mapper: reload ioctl failed: Invalid argument > Command failed Could you try this again with a couple of "-v" arguments added to the dmsetup command -> "dmsetup -v -v -v -v -v -v -v -v -v -v create root map" and see if you get some additional output? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Hi, > Ok, one more test...could you deallocate both swap mappings and then try > to setup your root mapping? [01:49:[EMAIL PROTECTED]:/home/spjsschl]# swapoff -a && cryptsetup remove swap1 && cryptsetup remove swap2 && cryptsetup -c aes -s 256 -d /dev/stdin create root /dev/md0
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Ok, one more test...could you deallocate both swap mappings and then try to setup your root mapping? That is, run something like "swapoff -a && cryptsetup remove swap1 && cryptsetup remove swap2" and then try the "cryptsetup create..." invocation -- David Härdeman
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
On Thu, Feb 08, 2007 at 01:49:35AM +0100, David Härdeman wrote: Ok, one more test...could you deallocate both swap mappings and then try to setup your root mapping? That is, run something like "swapoff -a && cryptsetup remove swap1 && cryptsetup remove swap2" and then try the "cryptsetup create..." invocation And while we're at it, "cat /proc/partitions" to make sure that the kernel and fdisk agree on partition sizes. -- David Härdeman
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Hi, > And while we're at it, "cat /proc/partitions" to make sure that the > kernel and fdisk agree on partition sizes. [01:53:[EMAIL PROTECTED]:/home/spjsschl]# cat /proc/partitions major minor #blocks name 22 0 160086528 hdc 22 1 19543041 hdc1 22 29775552 hdc2 22 39775552 hdc3 22 4 1 hdc4 22 5 497983 hdc5 22 6 120487468 hdc6 2264 117220824 hdd 22653229033 hdd1 2266 1 hdd2 2269 20482843 hdd5 2270 93498268 hdd6 9 0 19542976 md0 253 03229033 dm-0 253 1 497983 dm-1 best regards, Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
On Wed, Feb 07, 2007 at 11:26:16PM +0100, Johannes Schlumberger wrote: Hi, This would suggest that the problem is not with cryptsetup at least. Something seems wonky with device-mapper in general. Whom should I be talking to about this? That would be the dmsetup package maintainer, but lets keep at it for a while before we call him in If it tries to setup 253:2, that suggests that there are two other device-mapper devices already setup...what is the output of "ls -al /dev/mapper", "dmsetup table" and "cat /proc/mounts"? Also, are you using udev? That is right, my two encrypted swappartitions. ... [23:24:[EMAIL PROTECTED]:/home/spjsschl]# dmsetup table swap2: 0 995967 crypt aes-cbc-plain 8fd07cf5cecac858cdd2c0ce673449b4c1734cecbe8a24e5be629d542c975cf1 0 22:5 0 swap1: 0 6458067 crypt aes-cbc-plain dde5fec1ee7146100bc83af997171ce196c2d1c453134d21e574f85ccc296588 0 22:65 0 Which devices are 22:5 and 22:65? I'm guessing /dev/hdc5 and /dev/hdd2? Could you provide me with the output from "ls -al /dev/hd*" and "fdisk -l /dev/hd?" (BTW, the above keys are random keys, right?) -- David Härdeman
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
On Wed, Feb 07, 2007 at 11:26:16PM +0100, Johannes Schlumberger wrote: [23:24:[EMAIL PROTECTED]:/home/spjsschl]# cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext3 rw,data=ordered 0 0 Also...which device is / on? I.e. /dev/root is an alias of /dev/hd? -- David Härdeman
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Hi, > >[23:24:[EMAIL PROTECTED]:/home/spjsschl]# dmsetup table > >swap2: 0 995967 crypt aes-cbc-plain > >8fd07cf5cecac858cdd2c0ce673449b4c1734cecbe8a24e5be629d542c975cf1 0 22:5 0 > >swap1: 0 6458067 crypt aes-cbc-plain > >dde5fec1ee7146100bc83af997171ce196c2d1c453134d21e574f85ccc296588 0 22:65 0 > Which devices are 22:5 and 22:65? I'm guessing /dev/hdc5 and /dev/hdd2? hdc5 and hdd1. > Could you provide me with the output from "ls -al /dev/hd*" and "fdisk -l > /dev/hd?" [00:18:[EMAIL PROTECTED]:/home/spjsschl]# ls -al /dev/hd* brw-rw 1 root cdrom 3, 0 2007-02-08 00:21 /dev/hda brw-rw 1 root cdrom 3, 64 2007-02-08 00:21 /dev/hdb brw-rw 1 root disk 22, 0 2007-02-08 00:21 /dev/hdc brw-rw 1 root disk 22, 1 2007-02-08 00:21 /dev/hdc1 brw-rw 1 root disk 22, 2 2007-02-07 23:21 /dev/hdc2 brw-rw 1 root disk 22, 3 2007-02-08 00:21 /dev/hdc3 brw-rw 1 root disk 22, 4 2007-02-08 00:21 /dev/hdc4 brw-rw 1 root disk 22, 5 2007-02-08 00:21 /dev/hdc5 brw-rw 1 root disk 22, 6 2007-02-08 00:21 /dev/hdc6 brw-rw 1 root disk 22, 64 2007-02-08 00:21 /dev/hdd brw-rw 1 root disk 22, 65 2007-02-08 00:21 /dev/hdd1 brw-rw 1 root disk 22, 66 2007-02-08 00:21 /dev/hdd2 brw-rw 1 root disk 22, 69 2007-02-08 00:21 /dev/hdd5 brw-rw 1 root disk 22, 70 2007-02-08 00:21 /dev/hdd6 [00:18:[EMAIL PROTECTED]:/home/spjsschl]# fdisk -l /dev/hd? Disk /dev/hdc: 163.9 GB, 163928604672 bytes 255 heads, 63 sectors/track, 19929 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdc1 1243319543041 fd Linux raid autodetect /dev/hdc224343650 9775552+ 83 Linux /dev/hdc3 *36514867 9775552+ c W95 FAT32 (LBA) /dev/hdc44868 19929 1209855155 Extended /dev/hdc548684929 497983+ 82 Linux swap / Solaris /dev/hdc64930 19929 120487468+ 83 Linux Disk /dev/hdd: 120.0 GB, 120034123776 bytes 255 heads, 63 sectors/track, 14593 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdd1 * 1 402 3229033+ 82 Linux swap / Solaris /dev/hdd2 403 14593 113989207+ f W95 Ext'd (LBA) /dev/hdd5 * 403295220482843+ fd Linux raid autodetect /dev/hdd62953 1459293498268+ 83 Linux > (BTW, the above keys are random keys, right?) Hehe, of course :-) regards, Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Hi, > Also...which device is / on? I.e. /dev/root is an alias of > /dev/hd? It is hdd6 at the moment, i am going to copy it back to md0 once i got the cryptlayer on it working. regards, Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Hi, > This would suggest that the problem is not with cryptsetup at least. > Something seems wonky with device-mapper in general. Whom should I be talking to about this? > Just to make sure, do you think you could install the Debian packaged > kernel, boot it and try to setup the mapping with that kernel? I still get an error. [23:18:[EMAIL PROTECTED]:~]# uname -r 2.6.18-4-486 [23:18:[EMAIL PROTECTED]:~]# apt-cache policy linux-image-2.6.18-4-486 linux-image-2.6.18-4-486: Installed: 2.6.18.dfsg.1-10 Candidate: 2.6.18.dfsg.1-10 Version table: *** 2.6.18.dfsg.1-10 0 500 http://debian.informatik.uni-erlangen.de sid/main Packages 100 /var/lib/dpkg/status [23:19:[EMAIL PROTECTED]:~]# modprobe dm-crypt [23:19:[EMAIL PROTECTED]:~]# lsmod | grep !$ lsmod | grep dm-crypt [23:19:[EMAIL PROTECTED]:~]# lsmod | grep dm_crypt dm_crypt 10888 1 dm_mod 48952 7 dm_crypt,dm_snapshot,dm_mirror [23:19:[EMAIL PROTECTED]:~]# cryptsetup -c aes -s 256 -d /dev/stdin create root /dev/md0 If it tries to setup 253:2, that suggests that there are two other > device-mapper devices already setup...what is the output of "ls -al > /dev/mapper", "dmsetup table" and "cat /proc/mounts"? Also, are you > using udev? That is right, my two encrypted swappartitions. [23:21:[EMAIL PROTECTED]:~]$ ls -al /dev/mapper/ total 0 drwxr-xr-x 2 root root 100 2007-02-07 23:21 . drwxr-xr-x 14 root root4520 2007-02-07 23:21 .. crw-rw 1 root root 10, 63 2007-02-08 00:21 control brw-rw 1 root disk 253, 0 2007-02-07 23:21 swap1 brw-rw 1 root disk 253, 1 2007-02-07 23:21 swap2 [23:23:[EMAIL PROTECTED]:~]$ su Password: [23:24:[EMAIL PROTECTED]:/home/spjsschl]# dmsetup table swap2: 0 995967 crypt aes-cbc-plain 8fd07cf5cecac858cdd2c0ce673449b4c1734cecbe8a24e5be629d542c975cf1 0 22:5 0 swap1: 0 6458067 crypt aes-cbc-plain dde5fec1ee7146100bc83af997171ce196c2d1c453134d21e574f85ccc296588 0 22:65 0 [23:24:[EMAIL PROTECTED]:/home/spjsschl]# cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext3 rw,data=ordered 0 0 tmpfs /lib/init/rw tmpfs rw,nosuid 0 0 proc /proc proc rw,nosuid,nodev,noexec 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0 usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0 /dev/root /dev/.static/dev ext3 rw,data=ordered 0 0 tmpfs /dev tmpfs rw 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,nosuid,noexec 0 0 /dev/hdc6 /home/spjsschl/data-scratch xfs rw 0 0 /dev/hdc3 /home/spjsschl/c vfat rw,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1 0 0 /dev/hdc2 /home/spjsschl/winspace ext3 rw,data=ordered 0 0 none /tmp tmpfs rw 0 0 none /var/tmp tmpfs rw 0 0 none /sys/fs/fuse/connections fusectl rw 0 0 I am using udev. best regards, Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
On Wed, Feb 07, 2007 at 10:31:27PM +0100, Johannes Schlumberger wrote: Hi, Ok, could you create a file called e.g. "map" containing the following line: 0 1 crypt aes-cbc-essiv:sha256 0123456789abcdef0123456789abcdef 0 /dev/md0 0 shure. [22:28:[EMAIL PROTECTED]:/tmp]# echo '0 1 crypt aes-cbc-essiv:sha256 \ 0123456789abcdef0123456789abcdef 0 /dev/md0 0' > map [22:28:[EMAIL PROTECTED]:/tmp]# dmsetup create root map device-mapper: reload ioctl failed: Invalid argument Command failed This would suggest that the problem is not with cryptsetup at least. Something seems wonky with device-mapper in general. I've updated the testing machine I was using so that it has the same package versions as your machine and it still works for me. Just to make sure, do you think you could install the Debian packaged kernel, boot it and try to setup the mapping with that kernel? (but do the things mentioned below first) the dmesg output differs though, its missing one line. [22:28:[EMAIL PROTECTED]:/tmp]# dmesg | tail -n 3 agpgart: Putting AGP V3 device at :01:00.0 into 8x mode device-mapper: table: 253:2: crypt: Device lookup failed device-mapper: ioctl: error adding target to table If it tries to setup 253:2, that suggests that there are two other device-mapper devices already setup...what is the output of "ls -al /dev/mapper", "dmsetup table" and "cat /proc/mounts"? Also, are you using udev? -- David Härdeman
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Hi, > Ok, could you create a file called e.g. "map" containing the following line: > 0 1 crypt aes-cbc-essiv:sha256 0123456789abcdef0123456789abcdef 0 > /dev/md0 0 shure. [22:28:[EMAIL PROTECTED]:/tmp]# echo '0 1 crypt aes-cbc-essiv:sha256 \ 0123456789abcdef0123456789abcdef 0 /dev/md0 0' > map [22:28:[EMAIL PROTECTED]:/tmp]# dmsetup create root map device-mapper: reload ioctl failed: Invalid argument Command failed the dmesg output differs though, its missing one line. [22:28:[EMAIL PROTECTED]:/tmp]# dmesg | tail -n 3 agpgart: Putting AGP V3 device at :01:00.0 into 8x mode device-mapper: table: 253:2: crypt: Device lookup failed device-mapper: ioctl: error adding target to table best regards, Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
On Wed, Feb 07, 2007 at 12:51:52AM +0100, Johannes Schlumberger wrote: Hi, Unfortunately I am not able to reproduce this. Using a qemu machine with two virtual disks in a RAID set, the crypt mapping is setup correctly. If I do make sure that the dm-crypt.ko module is not available, the error messages and strace exactly match yours. What output do you get from "dmsetup targets"? [00:50:[EMAIL PROTECTED]:/home/spjsschl]# dmsetup targets cryptv1.3.0 striped v1.0.2 linear v1.0.2 errorv1.0.1 Ok, could you create a file called e.g. "map" containing the following line: 0 1 crypt aes-cbc-essiv:sha256 0123456789abcdef0123456789abcdef 0 /dev/md0 0 then run "dmsetup create root map" and see if that fails? -- David Härdeman
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
On Tue, Feb 06, 2007 at 11:02:21PM +0100, Johannes Schlumberger wrote: Hi, and thanks for the trace, the problem is indeed here: >ioctl(3, DM_TABLE_LOAD, 0x80a2040) = -1 EINVAL (Invalid argument) that means that "crypt" is not a valid device-mapper target. That in turn means that dm-crypt was not loaded and could not be dynamically loaded by the kernel. As you should be able to observe from my sent kernel config i have built dm_crypt into the kernel, therefore it cannot (and has not to) be loaded as a module. Sorry, I missed the attached kernel config. Unfortunately I am not able to reproduce this. Using a qemu machine with two virtual disks in a RAID set, the crypt mapping is setup correctly. If I do make sure that the dm-crypt.ko module is not available, the error messages and strace exactly match yours. What output do you get from "dmsetup targets"? -- David Härdeman
Bug#409875: [Pkg-cryptsetup-devel] Bug#409875: bug #409875
Hi, > Unfortunately I am not able to reproduce this. Using a qemu machine with > two virtual disks in a RAID set, the crypt mapping is setup correctly. > > If I do make sure that the dm-crypt.ko module is not available, the > error messages and strace exactly match yours. > > What output do you get from "dmsetup targets"? [00:50:[EMAIL PROTECTED]:/home/spjsschl]# dmsetup targets cryptv1.3.0 striped v1.0.2 linear v1.0.2 errorv1.0.1 regards, Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
