Karmic boot doesn't wait for encrypted disc passphrase

[Tony Green]

After installing Karmic today and rebooting, I didn't get the opportunity to enter the passphrase for my LUKS encrypted home partition. This meant that not only didn't I have a usable home partition but also (because they're in /etc/crypttab after the home partition) I didn't have a /tmp filesystem or any swap. It also messes up my NFS mounts, as some of them are mounted in my home directory.

This seems to be a serious design fault in upstart (or at least the way it's working with encrypted filesystems) and rendered by computer unusable.

Unfortunately I won't be able to provide any extra diagnostics, as this has forced me to restore my system from backups.

[flocci (dohashi)]

I have a similar issue, although I am mounting my encrypted home drive via pam_mount, so those seem ok. However I have an encrypted tmp and swap configured using crypttab.

# <target name> <source device> <key file> <options>
cryptohome /dev/md0 none noauto,luks
cryptoswap /dev/sdd2 /dev/urandom cipher=aes-cbc-essiv:sha256,size=256,hash=256,swap
cryptotmp /dev/sdd3 /dev/urandom tmp

I get a couple warnings about /dev/mapper/cryptotab not being ready during the boot. Once gdm comes up I can't log in, I get kicked back to the gdm window. I can log in via a virtual terminal. From there I can see that /tmp is not mounted. If I manually mount it (/dev/mapper/cryptotmp is ready by then), then everything seems to work fine.

cryptoswap seems to be mounted ok.

[Pac Shady (pacshady)]

I think I have the same issue. I have two random key encrypted drives, /tmp and swap, but the problem (so far) only seems to happen with /tmp. The problem seems to be intermittent, but still happens on maybe 50% or more of boots. I can't get a boot log because upstart doesn't appear to use them. I've tried to get around the problem by forcibly mounting /tmp in the init script for GDM with a sleep interval of 5 seconds (as well as changing ownerships on the directory which, due to the drive being wiped on every boot aren't being saved), which so far seems to have stopped the gconf-sanity-check-2 error 256 happening and lets GDM work fine, but every couple of boots I get thrown back to a recovery console because /tmp failed to mount. After checking the boot messages without splash it seems it's trying to mount before the encryption is fully active.

cat /etc/crypttab
sda4_crypt /dev/disk/by-uuid/d8ae7e62-57ba-4742-8121-179394693901 none luks
sda5_crypt /dev/sda5 /dev/urandom cipher=aes-cbc-essiv:sha256,size=128,swap
sda6_crypt /dev/sda6 /dev/urandom cipher=aes-cbc-essiv:sha256,size=128,tmp

[Pac Shady (pacshady)]

OK, turns out the additions I made to the GDM init script still don't fix the gconf-sanity-check-2 error. It still happens, but it appears to be random. In fact, everything about these problems appears to be random. The synchronous nature of Upstart seems to make the boot process unpredictable, and when some programs look for things that SHOULD have been done before they started, but haven't because Upstart wants to do them all at once, things get messy. Besides, I thought Upstart was supposed to streamline the boot process and make it faster, but Karmic's boot process seems to be twice as long as any previous version.

[LMN (laurent-pulsic)]

I'm also having a similar issue, although only my home area is encrypted (no encrypted swap or tmp). Last week I have been able to somehow interrupt the boot process at a place where it was asking for the pass phrase to unlock the encrypted partition and was able to boot up normally after that. But today I had to reboot my laptop and hit the same problem again. I've had no luck trying to reproduce the sequence of actions I used the first time around. The bottom line is that I am unable to complete the boot process and get the gdm login window anymore. Quite stuck, then: please help!

[flocci (dohashi)]

I just noticed that I made a typo in my above posting, it is /dev/mapper/cryptotmp that is not ready on boot, and thus does not get mounted properly.

[Taz (an-hofmeister)]

I have the same issue, with my /home partition.

[Taz (an-hofmeister)]

Update. This problem is a result from updating Ubuntu. I have install Ubuntu new, everything works fine. But after installing updates, Ubuntu cant mount the encrypted devices.

[Steve Langasek (vorlon)]

Thank you for taking the time to report this problem and help to improve Ubuntu.

The issue with tmp and swap cryptdisks is known and is tracked as bug #475936.

Tony, as the original submitter of this bug, can you please attach your /etc/crypttab and /etc/fstab?

[Malinger_now (rory-stubble)]

Lots of good info and stuff to try out. As with Taz, I might have done an upgrade (in my case, from within running sys using Aptitude) and/or an install of Ristretto WITHOUT rebooting before further activity. Not sure that I was this careless but the newly-installed Ristretto which went wild before the lockup, seems to be responsible for the inability to mount filesystems from that point forward.

[Launchpad Janitor (janitor)]

[Expired for cryptsetup (Ubuntu) because there has been no activity for 60 days.]