cryptsetup can't get input at boot.

[Stephen Day]

Binary package hint: cryptsetup

The karmic startup scripts run cryptsetup in parallel with other scripts and/or getty. The effect is that user input doesn't get delivered to cryptsetup making it impossible to enter a passphrase to decrypt the disks mentioned in /etc/crypttab at boot time. This can also result in the passphrase being echoed to the screen.

This errant behavior appears both on encrypted disks devices and encrypted md devices. This was not the case with the last release of ubuntu.

I have only tested with luks encryption. This does not affect encrypted root disks which are setup by initfs.

[Stephen Day (sd)]

Please note this is not the same, but does appear to be related to 445888 ( X starts at the same time as cryptsetup. )

[Michael Evans (mjevans1983)]

I noticed this regression after re-installing 9.10 and performing normal system updates. I was backing out of a full Lucid install to dual 9.10 / lucid installs.

I can enter the passwords for / and swap correctly within the initrd.
Then fsck is run on /boot (/dev/sda3) and / (lvm).

Next a second round of cryptsetup runs, indicating that the devices that had been started are running, and starting that it is about to try starting lin-home_crypt ; which is when it then displays a message:

One or more of the mounts listed in /etc/fstab cannot yet be mounted:
(ESC for recovery shell)
/home: waiting for /dev/mapper/lin-home_crypt

No input displays on the screen, but I am unable to enter the password to unlock exactly what it needs.

A workaround of appending break=bottom and manually running cryptsetup luksOpen src destname allows me to unlock the device before this race condition occurs.