Setting up Cinnamon so that the boot disk is encrypted has been a source of frustration for 3 releases now.

Most recently I installed Saucy. As with Roaring it doesn’t seem to be possible to install onto an encrypted root successfully with the desktop installer. Everything seemed to work until it was time to install the boot loader. That seems to have failed and I wasn’t able to get it to work.

Ultimately, I went back to installing the server version, and then doing an apt-get install ubuntu-desktop. Although this seemed to work out of the chute, I had a few issues.

The configuration files for lightdm changed structure, and my “after the reinstall script” which endeavours to restore all the tweaks I have in config files, put a file named /etc/lightdm/lightdm.conf out there, which seemed to croak lightdm. When I moved the file into the new lightdm.conf.d scheme that problem was solved. All that was about getting synergy client running as soon as the display manager comes up.

The more difficult issue came with the first update. After the first new kernel update, the system would drop into busybox. Turns out that somebody decided it would be a good idea not to include the cryptsetup modules in the initramfs. There is a file /etc/initramfs-tools/initramfs.conf which can be told whether or not to include the cryptsetup, by adding CRYPTSETUP=Y and then rebuilding the initramfs with update-initramfs -u -v -k{kernel}.

There is another complexity that bit me in the butt, which I need to record. At the time that the initramfs is built, the contents of /etc/crypttab are used to provide the information for a file passed along to the initramfs image that specifies the boot disk. This leads to the following problem:

a) I rebuild a new version of cinnamon, with a newly encrypted drive containing /boot as well as a vg with  /root &  /swap on, say, /dev/sde. Since it is a “new” encryption, it will have a new UUID.

b) after I get up I run my recover scripts – which restore all the various /home, /root, as well as /etc files that have stuff I have tweaked. Among these is /etc/cryptab which has the information for decrypting various encrypted drives that use a keyfile, but it also has an entry for the previous version of the root: /dev/sde — and most importantly – that entry has the old UUID

c) if I then do something to create a new initramfs, (upgrade to a new kernel) update-initramfs will copy the OLD UUID out of /etc/crypttab, put it into a file cryptroot telling the initramfs image what UUID to decrypt to find the root. But it has the wrong UUID. So when you boot that image it will come up looking for a luks drive that isn’t there. Then cryptsetup will hang there saying : “Cryptsetup: evms_activate is not available”. I think that evms_activate was (is?) a component which would search for a volume. Not sure of this. What I know is that once the /etc/crypttab has the right UUID and initramfs is rebuilt, passing a cryptroot file with the right UUID, the system came up perfectly.

I have to remember to change the /etc/crypttab after creating a new version of cinnamon.