Arch Linux

Try disabling hal and/or dbus before attempting to run cryptsetup. This might solve your problem.

Heres some debug output:

[root@arch bernhard]# cryptsetup -c aes-xts-plain -s 512 luksFormat /dev/md0 --debug
# cryptsetup 1.2.0 processing "cryptsetup -c aes-xts-plain -s 512 luksFormat /dev/md0 --debug"
# Locking memory.

WARNING!
========
This will overwrite data on /dev/md0 irrevocably.

Are you sure? (Type uppercase yes): YES
# Allocating crypt device /dev/md0 context.
# Trying to open and read device /dev/md0.
# Initialising device-mapper backend, UDEV is enabled.
# Detected dm-crypt target of version 1.7.0.
# Password verification enabled.
# Timeout set to 0 miliseconds.
# Iteration time set to 1000 miliseconds.
Enter LUKS passphrase:
Verify passphrase:
# Formatting device /dev/md0 as type (none).
# Initializing crypto backend (using secure memory).
# Topology: IO (524288/1048576), offset = 0; Required alignment is 1048576 bytes.
# Generating LUKS header version 1 using hash sha1, aes, xts-plain, MK 64 bytes
# PBKDF2: 330397 iterations per second using hash sha1.
# Data offset 4096, UUID 3c031b43-db76-4b22-8d95-fc7f3cd25ce2, digest iterations 40250
# Updating LUKS header of size 1024 on device /dev/md0
# Reading LUKS header of size 1024 from device /dev/md0
# Adding new keyslot -1 using volume key.
# Calculating data for key slot 0
# Key slot 0 use 161326 password iterations.
# Using hash sha1 for AF in key slot 0, 4000 stripes
# Updating key slot 0 [0x1000] area on device /dev/md0.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-9075
# Udev cookie 0xd4d880d (semid 2523141) created
# Udev cookie 0xd4d880d (semid 2523141) incremented
# Udev cookie 0xd4d880d (semid 2523141) incremented
# Udev cookie 0xd4d880d (semid 2523141) assigned to dm_task type 0 with flags 0xe
# dm create temporary-cryptsetup-9075 CRYPT-TEMP-temporary-cryptsetup-9075 OF [16384]
# temporary-cryptsetup-9075: Stacking NODE_ADD (253,0) 0:0 0600
# dm reload temporary-cryptsetup-9075 OF [16384]
# dm resume temporary-cryptsetup-9075 OF [16384]
# Udev cookie 0xd4d880d (semid 2523141) decremented
# temporary-cryptsetup-9075: Stacking NODE_READ_AHEAD 4096 (flags=1)
# Udev cookie 0xd4d880d (semid 2523141) decremented
# Udev cookie 0xd4d880d (semid 2523141): Waiting for zero
# Udev cookie 0xd4d880d (semid 2523141) destroyed
# /dev/mapper/temporary-cryptsetup-9075 not set up by udev: Falling back to direct node creation.
# Created /dev/mapper/temporary-cryptsetup-9075
# temporary-cryptsetup-9075: read ahead is 256
# temporary-cryptsetup-9075: Setting read ahead to 4096
# Udev cookie 0xd4d8c2c (semid 2555909) created
# Udev cookie 0xd4d8c2c (semid 2555909) incremented
# Udev cookie 0xd4d8c2c (semid 2555909) incremented
# Udev cookie 0xd4d8c2c (semid 2555909) assigned to dm_task type 2 with flags 0x0
# dm remove temporary-cryptsetup-9075 OF [16384]
# Udev cookie 0xd4d8c2c (semid 2555909) decremented
# temporary-cryptsetup-9075: Stacking NODE_DEL (replaces other stacked ops)
semid 2555909: semop failed for cookie 0xd4d8c2c: incorrect semaphore state
Failed to set a proper state for notification semaphore identified by cookie value 223185964 (0xd4d8c2c) to initialize waiting for incoming notifications.
# Udev cookie 0xd4d8c2c (semid 2555909) destroyed
# Key slot 0 was enabled in LUKS header.
# Updating LUKS header of size 1024 on device /dev/md0
# Reading LUKS header of size 1024 from device /dev/md0
# Releasing crypt device /dev/md0 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command successful.

Stopping dbus and executing it worked, Im kinda curious though why i have to that though. Id like to unlock my device when my xserver runs.

Can't reproduce this on a loop device. This must have something to do with the md-device, but I do not have any md-Setup to test this.

Can you try the 2.02.81 from core or 2.02.82 from testing? This problem should be fixed according to the cryptsetup maintainer.

I think, it's not a problem of the device-mapper. I have installed version 2.02.81-1.

I think, it's a problem with cryptsetup. Version 1.1.3-1 is working, but not 1.2.0-1.

Can you also paste the debug log from the working 1.1.3 version?

Okay, that's strange. Now, both Versions of cryptsetup are working if i unlock the partitions manually, it doesn't fail any more due to unknown semaphore state. BUT: when trying to unlock while booting using crypttab, cryptsetup version 1.2.0-1 doesn't work. Booting fails (Filesystem check failed. Please repair manually and reboot), but not with cryptsetup version 1.1.3-1.

So: maybe it was due to the device-mapper. And: did anything change in the crypttab syntax?!

Plus, it doesn't seem to be related to the md-raid. It's the same issue with /dev/sda4

Here are the debug logs from 1.1.3 and 1.2.0:

----------------------------------------------------------------------------------------

root@demon ~ # cryptsetup luksOpen /dev/sda4 home --debug
# cryptsetup 1.1.3 processing "cryptsetup luksOpen /dev/sda4 home --debug"
# Locking memory.
# Allocating crypt device /dev/sda4 context.
# Trying to open and read device /dev/sda4.
# Initialising device-mapper backend, UDEV is enabled.
# Detected dm-crypt target of version 1.7.0.
# Timeout set to 0 miliseconds.
# Password retry count set to 3.
# Iteration time set to 1000 miliseconds.
# Password verification disabled.
# Trying to load LUKS1 crypt type from device /dev/sda4.
# Initializing crypto backend (using secure memory).
# Reading LUKS header of size 1024 from device /dev/sda4
# Activating volume home [keyslot -1] using [none] passphrase.
# dm status home OF [16384]
Geben Sie den Passsatz für /dev/sda4 ein:
# Trying to open key slot 0 [3].
# Reading key slot 0 area.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-2064
# Udev cookie 0xd4de449 (semid 0) created
# Udev cookie 0xd4de449 (semid 0) incremented
# Udev cookie 0xd4de449 (semid 0) incremented
# Udev cookie 0xd4de449 (semid 0) assigned to dm_task type 0 with flags 0xe
# dm create temporary-cryptsetup-2064 CRYPT-TEMP-temporary-cryptsetup-2064 OF [16384]
# temporary-cryptsetup-2064: Stacking NODE_ADD (253,0) 0:0 0600
# dm reload temporary-cryptsetup-2064 OF [16384]
# dm resume temporary-cryptsetup-2064 OF [16384]
# temporary-cryptsetup-2064: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4de449 (semid 0) decremented
# Udev cookie 0xd4de449 (semid 0): Waiting for zero
# Udev cookie 0xd4de449 (semid 0) destroyed
# temporary-cryptsetup-2064: read ahead is 256
# temporary-cryptsetup-2064: Setting read ahead to 256
# Udev cookie 0xd4dd715 (semid 32768) created
# Udev cookie 0xd4dd715 (semid 32768) incremented
# Udev cookie 0xd4dd715 (semid 32768) incremented
# Udev cookie 0xd4dd715 (semid 32768) assigned to dm_task type 2 with flags 0x0
# dm remove temporary-cryptsetup-2064 OF [16384]
# temporary-cryptsetup-2064: Stacking NODE_DEL (replaces other stacked ops)
# Udev cookie 0xd4dd715 (semid 32768) decremented
# Udev cookie 0xd4dd715 (semid 32768): Waiting for zero
# Udev cookie 0xd4dd715 (semid 32768) destroyed
Schlüsselfach 0 entsperrt.
# Calculated device size is 47162800 sectors (RW), offset 4040.
# DM-UUID is CRYPT-LUKS1-83c0874ce9d24657bfd95a0f478ebc63-home
# Udev cookie 0xd4da669 (semid 65536) created
# Udev cookie 0xd4da669 (semid 65536) incremented
# Udev cookie 0xd4da669 (semid 65536) incremented
# Udev cookie 0xd4da669 (semid 65536) assigned to dm_task type 0 with flags 0x0
# dm create home CRYPT-LUKS1-83c0874ce9d24657bfd95a0f478ebc63-home OF [16384]
# home: Stacking NODE_ADD (253,0) 0:0 0600
# dm reload home OF [16384]
# dm resume home OF [16384]
# home: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4da669 (semid 65536) decremented
# Udev cookie 0xd4da669 (semid 65536): Waiting for zero
# Udev cookie 0xd4da669 (semid 65536) destroyed
# home: read ahead is 256
# home: Setting read ahead to 256
# Releasing crypt device /dev/sda4 context.
# Releasing device-mapper backend.
# Unlocking memory.
Befehl erfolgreich.

----------------------------------------------------------------------------------------

root@demon ~ # cryptsetup luksOpen /dev/sda4 home --debug
# cryptsetup 1.2.0 processing "cryptsetup luksOpen /dev/sda4 home --debug"
# Locking memory.
# Allocating crypt device /dev/sda4 context.
# Trying to open and read device /dev/sda4.
# Initialising device-mapper backend, UDEV is enabled.
# Detected dm-crypt target of version 1.7.0.
# Trying to load LUKS1 crypt type from device /dev/sda4.
# Initializing crypto backend (using secure memory).
# Reading LUKS header of size 1024 from device /dev/sda4
# Timeout set to 0 miliseconds.
# Password retry count set to 3.
# Iteration time set to 1000 miliseconds.
# Activating volume home [keyslot -1] using [none] passphrase.
# dm status home OF [16384]
Geben Sie den Passsatz für /dev/sda4 ein:
# Trying to open key slot 0 [3].
# Reading key slot 0 area.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-2062
# Udev cookie 0xd4da3e0 (semid 0) created
# Udev cookie 0xd4da3e0 (semid 0) incremented
# Udev cookie 0xd4da3e0 (semid 0) incremented
# Udev cookie 0xd4da3e0 (semid 0) assigned to dm_task type 0 with flags 0xe
# dm create temporary-cryptsetup-2062 CRYPT-TEMP-temporary-cryptsetup-2062 OF [16384]
# temporary-cryptsetup-2062: Stacking NODE_ADD (253,0) 0:0 0600
# dm reload temporary-cryptsetup-2062 OF [16384]
# dm resume temporary-cryptsetup-2062 OF [16384]
# temporary-cryptsetup-2062: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4da3e0 (semid 0) decremented
# Udev cookie 0xd4da3e0 (semid 0): Waiting for zero
# Udev cookie 0xd4da3e0 (semid 0) destroyed
# temporary-cryptsetup-2062: read ahead is 256
# temporary-cryptsetup-2062: Setting read ahead to 256
# Udev cookie 0xd4da962 (semid 32768) created
# Udev cookie 0xd4da962 (semid 32768) incremented
# Udev cookie 0xd4da962 (semid 32768) incremented
# Udev cookie 0xd4da962 (semid 32768) assigned to dm_task type 2 with flags 0x0
# dm remove temporary-cryptsetup-2062 OF [16384]
# temporary-cryptsetup-2062: Stacking NODE_DEL (replaces other stacked ops)
# Udev cookie 0xd4da962 (semid 32768) decremented
# Udev cookie 0xd4da962 (semid 32768): Waiting for zero
# Udev cookie 0xd4da962 (semid 32768) destroyed
Schlüsselfach 0 entsperrt.
# Calculated device size is 47162800 sectors (RW), offset 4040.
# DM-UUID is CRYPT-LUKS1-83c0874ce9d24657bfd95a0f478ebc63-home
# Udev cookie 0xd4dec9d (semid 65536) created
# Udev cookie 0xd4dec9d (semid 65536) incremented
# Udev cookie 0xd4dec9d (semid 65536) incremented
# Udev cookie 0xd4dec9d (semid 65536) assigned to dm_task type 0 with flags 0x0
# dm create home CRYPT-LUKS1-83c0874ce9d24657bfd95a0f478ebc63-home OF [16384]
# home: Stacking NODE_ADD (253,0) 0:0 0600
# dm reload home OF [16384]
# dm resume home OF [16384]
# home: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4dec9d (semid 65536) decremented
# Udev cookie 0xd4dec9d (semid 65536): Waiting for zero
# Udev cookie 0xd4dec9d (semid 65536) destroyed
# home: read ahead is 256
# home: Setting read ahead to 256
# Releasing crypt device /dev/sda4 context.
# Releasing device-mapper backend.
# Unlocking memory.
Befehl erfolgreich.

SOLVED! The crypttab syntax has changed. After removing the options in crypttab, cryptsetup 1.2.0-1 works again.


Old crypttab file:
# NAME SOURCE DEVICE PASSWORD OPTIONS
#home /dev/sda4 ASK -c aes-xts-plain -s 512
#data /dev/md0 ASK -c aes-xts-plain -s 512

New crypttab file:
# NAME SOURCE DEVICE PASSWORD OPTIONS
home /dev/sda4 ASK
data /dev/md0 ASK

1) Do you have initscripts from testing? If that is the case, you might be interested in https://mailman.archlinux.org/pipermail/arch-general/2011-January/018247.html The syntax did not change intentionally.

2) Do you use the -c and -s options in combination with LUKS? This is not intended and those should be ignored by cryptsetup.

3) In any case, this error should not occur.

1) I'm still using the initscripts from core: 2010.07-2. It's working fine, so I'd like to stay with this version. [I can test it within the next weeks, when I have more free time left]

2) Yes, i'm using LUKS. I didn't know, that crypttab-options shouldn't be used with LUKS. So, v1.2.0-1 doesn't ignore it anymore.

3) According to 2), it seems that misconfiguration in crypttab isn't ignored anymore - so there's no bug. Right?

Whatever. Anyway, there is no bug here (at least not anymore).