keyfile doesn't work in initramfs

[0] nokile:~$ dpkg -s cryptsetup | grep Version
Version: 2:1.0.5-2ubuntu12

Can you please clarify on your setup?
 - do you use LVM?
 - please attach your /etc/crypttab file

I am not using LVM. crypttab is attached.

Note: sda5_crypt is root, sda6_crypt is /home and sda7_crypt is swap.

well, wait a minute. After rereading the bug description, I come to the following conclusion:

- you have an encrypted root and want to use a keyfile instead of a password.
- In your /etc/crypttab you put the keyfile in /etc/luks_passwd.
- the initramfs has no possibility to decrypt the key in /etc/luks_passwd because it would need to have that key in advance
- the message is warning exactly because of this issue.

If you want to get the keyfile from a removable device, please about the passdev script from the cryptsetup package in intrepid in /usr/share/doc/cryptsetup/README.initramfs.gz

No, you confused the root and swap fs. I want to use a keyfile for the *swap* partition.

Ah, okay, my bad.

I just tried to reproduce this issue with the cryptsetup package in intrepid but failed to do so. The volume does come up pretty well.

Could you perhaps fetch the source from intrepid, compile the source on your hardy package and retry? there has been a few changes to cryptdisks, which is used by /etc/init.d/cryptdisks.

Oh yes, please attach the output of that init script to this bug. Does it contain useful information what's going wrong?

I compiled and installed cryptsetup from intrepid in Hardy. Unfortunately it only leaves my system onbootable, the boot hangs after the "Waiting for root filesystem" message from the initramdisk.

Hm. in my tests with kvm the system came up as expected. Can you try to
boot without usplash and watch if there are more 'interesting' boot
messages? If you use a serial console you can save the boot messages to
a file and attach that to this bug.

Ok, after I recovered my system, the intrepid cryptsetup works partially. Unfortunately I can't really tell what the important change was. I booted from a rescue system, reinstalled the hardy cryptsetup, used the opportunity to change some of my device labels and cleaned up /etc/fstab, /etc/cryptsetup and /etc/initramfs-tools/conf.d/resume.

What happens now is that I can boot my system normally with intrepid cryptsetup using a keyfile for all partitions except /. However, I am unable to resume. If I hibernate the system, then afterwards it starts up normally and only brings up the swap device together with the other partitions later in the boot process instead of right after the root fs in the initramdisk. The hibernation works fine though, when the swap is activated I get a warning that it contains a valid resume signature.

I also still get the same warning:

[1] nokile:~$ sudo update-initramfs -k all -c
[sudo] password for nikratio:
update-initramfs: Generating /boot/initrd.img-2.6.24-19-386
cryptsetup: WARNING: target luks_swap uses a key file, skipped
[0] nokile:~$ sudo cryptsetup --version
cryptsetup 1.0.6

so essentially I am now having the same problems with intrepid cryptsetup as I had with hardy cryptsetup.

Okay, now things become clearer.

As explained before, you cannot expect to use a keyfile for the root file system, because the keyfile would have to be in either at some unencrypted place (/boot or initramfs) which defeats the purpose of using a keyfile. The very same reasons apply to using a keyfile for encrypting swap space from which you want to resume from. Where should the key for unencrypting the device come from?

the only "solution" to this issue is to use the "passdev" mechanism introduced with the cryptsetup in intrepid to fetch the key from some removable media.

Btw, the warning 'cryptsetup: WARNING: target luks_swap uses a key file, skipped' is perfectly valid and intended to make you aware of this issue.

For this reason, I'm converting your bug report to a support ticket, because that's what you're actually requesting. There is nothing wrong in the cryptsetup package in this point and the package is behaving exactly as I would expect it to do.

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

1. So how comes that "use a keyfile for the root file system" feature used to work fine for me in 12.04 for example?
2. What is that so bad about keeping key files on /boot physically detachable media taking in view the fact that bootloader NEVER gets encrypted and vulnerable for "evil maid" attack (considering this the idea of keeping bootloader and keys altogether is not that bad)?
3. Why /boot can't be removable media?

I didn't like an idea of reviving such things, but i've spent two days on freenode and oftc dealing with similar (as i see it) thing described here on 13.04, that's why i took all my courage and revived the bug report and linked it to this discussion.

P.S. Sorry if i'm doing wrong stuff due to my inability to see things i could probably miss (in advance) and for my english if it sounds frustratung at some point.

n0PxN0p:
2. Would make sense in my opinion
3. This is potentially difficult. What happens when you try to install updates and /boot is not mounted ?