I’ve upgraded some of my systems to Ubuntu 15.04 and found that some system didn’t boot due to poorly documented interactions between Systemd and /etc/crypttab.

The major bug is around keyscripts, Debian and Ubuntu have for a long time supported using a binary or script to provide a password for encrypted devices, from the Debian crypttab man page:

keyscript= The executable at the indicated path is executed with the key file from the third field of the crypttab as its only argument and the output is used as the key.

People have used this for all sorts of creative ways of getting passwords from TPM chips, cryptocards etc.

The root of the problem is that systemd doesn’t support keyscripts at all, and in fact doesn’t even parse /etc/crypttab on boot.

I have worked round this bug by moving all my keyscript dependant volumes to start post system boot. The command cryptdisks_start still uses /etc/crypttab and keyscripts correctly, so I have added either nofail or noauto options to the devices in /etc/fstab and /etc/crypttab to allow the system to boot.

Another minor bug I encountered was caused by using the system UUID as a simple password for my backup disk. While this isn’t the worlds most secure key it is unique to my laptop and accessible to the system without any user interaction.

I did this by setting keyfile in /etc/crypttab to /sys/class/dmi/id/product_uuid. The bug is that systemd interprets the /sys path and for reasons I’ve not looked at in depth doesn’t start the LUKS device. The simple fix is to change the keyfile path and symlink the /sys file to the new location ie:

 sudo ln -s /sys/class/dmi/id/product_uuid /boot/uuid