fails to setup dm-crypt key mapping. (2:1.0.4+svn26-1ubuntu1~edgy1)

I can confirm the problem. After the upgrade to 1.0.4+svn26, my crypt partition stopped working.
When doing a "ls /dev/mapper", the crypt device was not listed any more.

Finally, I downgraded to 1.0.3, which resolved the issue.

IMO, this is a highly critical issue, since is rleaves whole partitions unfunctional.

Problem resolved by downgrading as well. It did not work imidiatly but after rebooting it seems to work now.

I also had the same problem but fixed it by adding to rc.local:
   cryptsetup -d /etc/keys/home create home /dev/hdb1
   mount /home

i can confirm this as a critical bug.

it is a shame these crap-versions get released. this is not the first problem with cryptsetup and it took me over an hour to correct it. after downgrading to 1.0.3 i can mount my crypted home again, but only manually, i also get the message crypt-key corrupt or something...

this is very annoying

I know of at least one user where the package works. any idea why it works for some users but not for others?

As reported, the update to 1.0.4 broke my setup.

I'd like to give some more information, maybe that helps.

I had dist-upgraded my dapper system, including the crypt devices, by using Ubuntu's update-manager.

After that, I struggled with Bug 62571 (https://launchpad.net/upstart/+bug/62751), which basically had the effect that cryptsetup did not prompt for the passphrase at system boot.
As a workaround, I implemented a fix to /lib/cryptsetup/cryptdisks.functions, as suggested in comments 18 and 21 (https://launchpad.net/upstart/+bug/62751/comments/18).

After that, my crypt device setup worked just like before the dist-upgrade.

With the update to 1.0.4 it broke again.

out of the blue, is cryptsetup working for you again if you guys type this:

# sudo modprobe aes dm-crypt dm_mod

(if yes, then this bug is a dupe of bug #64625)

I have it working by entering the commands for cryptsetup and mount in
rc.local without doing a modprobe. I did a lsmod before doing this and
saw dm_crypt and dm_mod loaded. Checking now aes is also loaded without
doing a modprobe. Note that I use -d /etc/keys to load the key rather
than entering a passphrase from the console.
> out of the blue, is cryptsetup working for you again if you guys type
> this:
>
> # sudo modprobe aes dm-crypt dm_mod
>
> (if yes, then this bug is a dupe of bug #64625)
>
>

> is cryptsetup working for you again if you guys type this:
> # sudo modprobe aes dm-crypt dm_mod

That doesn't fix the issue for me.
I've included these modules in /etc/modules, so they are loaded at system boot.

Same for me. Plus i do load aes-i586 in /etc/modules, but i don't think it causes any problems.
dm-cypt and dm_mod are not loaded from /etc/modules but they are there anyway.

hmm. do I see it right that all people having a problem are using a keyfile instead of a passphrase?

> hmm. do I see it right that all people having a problem are using a keyfile
> instead of a passphrase?

No. I'm using a passphrase, not a key file.

I guess this bug will be hard to fix, since it might overlap with other bugs (https://launchpad.net/bugs/62751, maybe), and people have different setups. I will try to do some more investigation.

Maybe that's a stupid question, but which log files am I supposed to have a look on?

My crypt partition is mapped and mounted at bootup, but I can't find any detailed information in dmesg, syslog, or /var/log/boot on what happens whatsoever.

Does anyone know if this problem also affects feisty? Or Debian etch?

The backport works fine here. I upgraded because I was unable to enter a passphrase on boot with the version in edgy. This issue was solved with the backport.

Anyway... I wonder why people upgrading to a backport when the original package from edgy works fine on their systems...

I'm having the same problem in feisty.

What I did and the error message:

> cryptsetup luksFormat /dev/sda2

WARNING!
========
Daten auf /dev/sda2 werden unwiderruflich überschrieben.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/sda2 contains at least 133 sectors.
Failed to write to key storage.
Aufruf fehlgeschlagen.

All modules are loaded, like aes, dm_crypt and dm_mod.

The funny thing is that yesterday I had the same problem when trying to mount a crypt-formatted USB disk. Yesterday it didn't work, today it did! Now my USB disk is mounted, but I am not able to cryptsetup luksFormat an internal HD partition....

syslog says:

Mar 31 16:01:02 hpsupercompi kernel: [ 8515.140000] device-mapper: table: 254:1: crypt: Device lookup failed
Mar 31 16:01:02 hpsupercompi kernel: [ 8515.140000] device-mapper: ioctl: error adding target to table
Mar 31 16:01:02 hpsupercompi kernel: [ 8515.144000] device-mapper: ioctl: device doesn't appear to be in the dev hash table.

My version is the same as stated in the title, but without the "~edgy1" at the end. (it's in feisty, universe/admin)

This seems to be the only show-stopper for using feisty as productive version..... (which is not recommended, I know, but I love some of the new features, that's why I'm trying...)

CORRECTION OF THE ABOVE
*blush* My fault..... in feisty I don't have any errors anymore, I just thought it was an error, but everything works fine (uhm, I used the wrong partition...)

I guess I thought it was an error because actually I _did_ have that external disk error yesterday, but it's really fixed today.

(comments can't be edited or removed, can they!?)

I switched to feisty now and the problem is gone. (same crypted drive etc) So it really seems to be edgy + the backport package.

which is pretty surprising, since the feisty package and the one from edgy-backports are built from exactly the same source. (only difference is debian/changelog)

Not sure if that is the same bug.

I currently run feisty (kernel 2.6.20-14) and try to setup dm-crypt / LUKS

So far I did jitter my harddisk with sudo dd if=/dev/urandom of=/dev/hda

Then I did install cryptsetup --> sudo apt-get install cryptsetup hashalot

Then I created a 160 GB partition: cfdisk /dev/hda

Then I loaded the kernel modules:
sudo modprobe aes dm-crypt dm_mod

Then I tried to setup LUKS

cryptsetup --verbose --verify-passphrase luksFormat /dev/hda1

but I only get this output:

hyper@xubi:/dev$ sudo cryptsetup --verbose --verify-passphrase luksFormat /dev/hda1

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

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Command failed: Passphrases do not match
hyper@xubi:/dev$ sudo cryptsetup --verbose --verify-passphrase luksFormat /dev/hda1

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

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
Verify passphrase:
Rendezvous with udev timed out for 'temporary-cryptsetup-6024'; stat failed: No such file or directory
Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/hda1 contains at least 133 sectors.
Failed to write to key storage.
Command failed.
hyper@xubi:/dev$

I even loaded the ase-i586 module but that didn't change anything...

I'm not sure if this belongs in here also.

Addon:

hyper@xubi:/dev$ cryptsetup --version
cryptsetup-luks 1.0.5

Just had to reinstall feisty. Used a herd 5 CD and installed cryptsetup. Had a similar problem directly after installing cryptsetup but now after loading the modules listed above it's gone. But i am pretty sure that i had the modules loaded in edgy as well as i said above. So i'd say different bug from bug #64625

I have Feisty and cryptsetup-luks 1.0.5.

I can mount encrypted USB through Gnome (Gnome displays "enter password" pop-up window), but when I type:

cryptsetup luksAddKey /dev/sdc3

I get:
  Enter any LUKS passphrase:
  Failed to setup dm-crypt key mapping.
  Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/sdc3 contains at least 133 sectors.
  Failed to read from key storage
  No key available with this passphrase.
  Command failed.

The problem is, this is already mounted partition so the password is correct. I also have loaded the following modules: dm-crypt, dm-mod, aes, sha256.

OK, this is a usability and lack of documetation problem.

You need to run **sudo** cryptsetup luksAddKey /dev/sdc3 and now it works fine...

For me, loading the module sha1 solved the problem completely.
Maybe anyone else can confirm that

I can confirm that modprobe sha1 fixed the problem for me on feisty. However, my problem was that I couldn't *add* a key with luksAddKey - the luksFormat worked fine

Further to above, creating the device with "--hash sha256" works too - a variant on the above problem. Curiously, a luksDump still shows "Hash spec: sha1" though I don't know if it's related.

I was wrong: sha1 didn't solved it really. I now have all modules loaded that i need (new ones loop, cbc and blkcipher) were missing and now it works one day and the other day not.
Seems to me like some kind of race condition between loading the modules and crytosetups try to open the device. If i wait long enough before entering the password for the root partition it always works, if i am to fast most of the time it does not.
I checked the code in my initrd and there is a call to udevsettle to wait until everything is ready, shouldn't it wait for loaded modules, too?

cryptsetup (2:1.0.4+svn29-1ubuntu2) gutsy; urgency=low

  * modprobe dm-mod from cryptsetup.functions. (LP: #64625, #91405)

 -- Reinhard Tartler <email address hidden> Tue, 29 May 2007 13:31:39 +0200