Comment 2 for bug 1258900

>What are you expecting this to do? crypto_LUKS is not a filesystem. There's no way this is going to do anything meaningful.

crypto_LUKS is a mount extension provided by libpam-mount and its functionality does not fail outside of the scope of the specified behavior.

that is the package specified as provided by `apt-cache show cryptsetup`.

http://pastebin.com/G5Ynhtix

This package is possibly relevant because crypt_LUKS probably functions along the lines of being a script that does:

losetup
cryptsetup
mount

>cryptsetup does not at boot prompt for passphrases in Ubuntu. It communicates with plymouth for prompting. Please provide >information about the plymouth configuration on your machine (including /proc/cmdline).

plymouth version information: http://pastebin.com/zCLrGUms

>ecryptfs is designed for cases where an encrypted filesystem is *not* mounted at boot, but instead mounted at user login (and >unmounted at user logout). I have no idea what the behavior is of ecryptfs if used from /etc/fstab. How is ecryptfs prompting >for a passphrase? If it is bypassing plymouth, then this is a bug in ecryptfs-utils, and the error you're experiencing is because >it's fighting plymouth for the console. Plymouth owns the console exclusively at boot.

1. Considering that the issues are quite similar on 2 different password prompts, please consider the possibility that this behavior is caused outside the scope ecryptfs despite the possibility of a lack of explicit support for mounting at boot.
2. Please consider whether there is an explicit expectation of the specified failure.

Please consider whether there is no implicit support for mount at boot or implicit interaction with the plymouth package. I don't know the abstractions provided by boot/plymouth, but would not a generic prompt for input, be correctly handled at boot, without the need for interfacing with plymouth, facilitating an implicit expectation of functionality at boot?