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.
Continue reading Boot Disk Encryption, Cryptsetup and Initramfs →

I had trouble booting the last few kernels that came out in 11.10 (3.0.0-16 and 17), and alas the same trouble with booting 12.04 which I installed today.

My root filesystem is encrypted, and I expect during the boot process to get a prompt for the encryption password. This doesn’t happen, and instead the boot drops into busybox. I was able to just keep using 3.0.0-15 under 11.10 but now that 12.04 is installed I can’t do that anymore. Actually have to try to track this down. .

After a lot of digging around, I haven’t completely got it figured out, but I did find some hints in this tread: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/874774 which gave me a start, and at least enabled me to boot. The thread describes a mixup in matching device names from udev to names in /etc/crypttab. If a match isn’t found, you don’t get a prompt for a password, the device doesn’t get luksOpened, and the boot fails waiting for it. So, the trick is to ensure the matching logic finds a match between the udev devname and the entry in /etc/crypttab. I actually didn’t even have an entry in /etc/crypttab for the root device. Silly me. I had entries for a couple of other encrypted devices. I would love to report that all I had to do was put in an entry in /etc/crypttab and it all worked. I alas not – I haven’t yet managed to get the problem solved. But I now know where to look, and more importantly reading the thread mentioned did make clear the short term workaround, which may be clear to everyone but me: it didn’t occur to me that once I dropped into busybox, I could just do cryptsetup luksOpen /dev/sde3 sde3_crypt, type in the correct password, and then exit busybox. The boot process resumes and is successful.

Update: In the normal course of Ubuntu updates I got 3.2.24 and the problem spontaneously healied itself. Now upon boot, I get an early prompt for the root password. Bob’s your uncle.