crypttab by-id entries not processed automatically at startup despite upstart files

[Kiri]

Binary package hint: cryptsetup

crypttab entries are not processed at start up.
There are both upstart and SysV init.d entries from the cryptsetup package at
/etc/init/cryptdisks-enable.conf
/etc/init/cryptdisks-udev.conf
/etc/init.d/cryptdisks
/etc/init.d/cryptdisks-early
/etc/init.d/cryptdisks-enable
/etc/init.d/cryptdisks-udev

Here is an example of a crypttab entry which worked in Karmic but does not in Lucid.

SwapSpace /dev/disk/by-id/usb-YourUSBMassStorageHere-0:0-part1 /dev/urandom swap,cipher=anubis,size=320,hash=sha384

running
cryptdisks_start SwapSpace
In this case correctly creates the device.

The mass storage is available by USB. As far as I know, there could be timing problems in it's availability or the constructing of entries under /dev/disk/by-id.

ProblemType: Bug
Architecture: i386
Date: Mon Feb 15 22:09:16 2010
DistroRelease: Ubuntu 10.04
Package: cryptsetup 2:1.1.0~rc2-1ubuntu11
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-13.18-generic
SourcePackage: cryptsetup
Uname: Linux 2.6.32-13-generic i686
crypttab:
 This information should not be put in automatically, I think.

[Kiri (kiri)]

== Regression details ==
Discovered in version: 2:1.1.0~rc2-1ubuntu11
Last known good version: 2:1.0.6+20090405.svn49-1ubuntu7.2

[Kiri (kiri)]

I reinstalled Ubuntu with a later daily image and now the device is created at boot.
This time I installed in non-expert mode. Previously I had installed in expert mode and had selected to create a custom initrd. What is the default initrd type for the non-expert install? If it is the more inclusive 'generic' initrd, that may explain the problem.

[Steve Langasek (vorlon)]

What exactly was the option letting you select a custom initrd? This doesn't seem to be a question that comes from the initramfs-tools package.

After reinstall, did you use the same syntax in /etc/crypttab? I think the issue here is that the cryptdisks-udev job handles UUID=, LABEL=, or /dev/sd* as source devices, but is not configured to handle /dev/disk/by-id. So this device will only be brought up if it's caught by the cryptdisks-enable catch-all job, which is racy.

[Steve Langasek (vorlon)]

(I don't consider this incomplete, the question about initramfs selection is most likely orthogonal to cryptsetup not supporting /dev/disk/by-uuid syntax)

[ubuntu-crypto (davexthc)]

On Sun, 2010-02-21 at 18:55 +0000, Steve Langasek wrote:
> (I don't consider this incomplete, the question about initramfs
> selection is most likely orthogonal to cryptsetup not supporting
> /dev/disk/by-uuid syntax)
>
> ** Changed in: cryptsetup (Ubuntu)
> Status: Incomplete => New
>

http://code.google.com/p/cryptsetup/

The packaged cryptsetup in Lucid is a Release Candidate. (1.1.0-rc2)
Since then rc-3, rc-4 and the final 1.1.0 has been released.
There have been at least a dozen bugs fixed since rc-2. I suggest
upgrading the package to the final stable version. While it may not fix
any of the experienced problems, it can at the very least attempt to
rule out the actual cryptsetup package as the problem. Furthermore it
may also prevent further since that have already been fixed and the
1.1.0 is marked as stable. I would like to see this package updated.
I will be testing cryptsetup for Lucid, however I will be using
non-default modes (aes-xts-benbi). This is off topic but the XTS code
has been in the kernel for a while, and it computes test vectors
correctly. I have used XTS mode with no problems. Switching to something
that is *standardized* rather than just created to counter CBC attacks
(ESSIV) would be preferred. XTS has most likely received more attention.
It is also *standardized* in IEEE P1619. "CBC-HMAC-SHA" is also
standardized in P1619, which is similar to ESSIV algorithm. However the
ESSIV algorithm is more complex, from what i have read simple is good
for an algorithm. AES is a good choice for the default encryption
algorithm, however with the recent AES 192-256 attacks AES128 seems to
be a better choice. AES128 is faster and 128 bits more then enough
security for most peoples needs. I also have a question about the Lucid
defaults. Since hashes besides SHA1 (--hash) are now accepted will
SHA256 be used by default?

My two cents.

[Steve Langasek (vorlon)]

> This is off topic

Your entire follow-up is off-topic, this is a bug related to Ubuntu's cryptsetup upstart jobs.

[Kiri (kiri)]

I re-installed and took a screen shot of the choice about which initrd to make. (generic or custom) I hope to be able to locate it and upload it in the next few days.

The configuration file is identical. I backed it up and restored it after re-install.

My last attempt to retest this in the advanced install was hindered by grub2 bug(s).

From the description of what devices are available at boot, it sounds unfortunately inadequate for the majority of use cases for potential users:
LABEL and UUID are unavailable since they come from the FileSystem, which is still, encrypted.
The /dev/sd* devices can vary in ordering. What is sdb in one boot can be sdc the next.

So even if this bug is invalid due to being about unsupported by-id devices, it sounds like setting status to 'WishList' for support of by-id devices is ... a wish.

As far as I can recall, this always works with the non-advanced install.
I suppose that if I find out how, I can reconfigure my existing system to use a custom initrd and see whether the problem appears.

[Steve Langasek (vorlon)]

> LABEL and UUID are unavailable since they come from the FileSystem, which is still, encrypted.

No, they don't. A LUKS container also has a UUID, and I guess there's some sort of support for setting labels as well.

[Dylan Piergies (dylan-piergies)]

I found adding the line:

start on starting mountall

after the other start line in /etc/init/cryptdisks-enable.conf fixed this.

[Steve Langasek (vorlon)]

I think you probably have a different bug, then.