Comment 29 for bug 473615

I am seeing very similar, frustrating behaviour, with a brand new install of 9.10 (amd64), which I then updated meaning I have cryptsetup 2:1.0.6+20090405.svn49-1ubuntu7.2 and mountall 1.0, watershed 4, etc.. No 'essential' mount points are encrypted (which I believe is a factor), only swap and 'data', although 'data' does include, among other things, /home.

If I don't have 'bootwait', gdm starts, but my encrypted partition isn't mounted (and switching back to tty1 there is no sign of a prompt for the passphrase).

If I do set 'bootwait' for the partition, the boot stops when mounting fails. A few hits of return sometimes gives a passphrase prompt, which doesn't work, saying the passphrase is wrong, as if it's only seeing the 'return', and not any other keystrokes. After a mixture of repeated attempts (so cryptsetup fails?) or waiting for mountall to timeout (I'm guessing), I eventually managed to get a maintenance prompt, so that I could remove the 'bootwait', and at least get back in to a state where the machine booted. (trying to boot in to single user mode to remove the 'bootwait' didn't work, because it still hit the failing mount).

Comment #27 suggests it now 'only works with usplash' (which seems a bit dangerous - what if something else causes usplash to not appear/exit early, or if you have some other reason why you don't want it?). I too had become used to booting without 'splash' whilst investigating this - when I tried putting 'splash' back, I got the message about hitting ESC for a recovery console, but *no* keyboard input did anything, the boot had completely hung. Interestingly (worryingly) even my usual Alt+SysRQ+S/U/S/B (sync/unmount/sync/boot) did nothing!

My most recent boot was without splash, with bootwait on my 'data' partition. This time I needed to input the passphrase three times, one time resulted in the passphrase being printed on the console after I'd hit return. If I switch back to tty1, it's still there, in plain sight. It did, however, result in the crypt-partition being unlocked.

/etc/crypttab:
# <target name> <source device> <key file> <options>
data /dev/sda6 none luks
cswap /dev/sda5 /dev/urandom swap

/etc/fstab:
/dev/mapper/data /mnt/data ext3 defaults,relatime 1 2
/dev/mapper/cswap none swap sw 0 0

(sometimes with, sometimes without bootwait on the options)

cswap appears to work *sometimes*, but usually only after a huge delay. It appears to have work this time, after my eventual successful unlocking of 'data', but dmesg for previous boots has shown me that it's come up after between 2000-8000 seconds.

Cheers,
--Dave