cryptsetup passphrase prompt at boot not working if waiting too long (w/o usplash)

[jott]

Binary package hint: cryptsetup

I have a LUKS-encrypted /home device (which in turn is a LVM partition). This setup worked very well until updating to 9.10.

When booting, I am prompted for the passphrase (I always boot with the "nosplash" option). This passphrase prompt is soon spoiled by messages "waiting for <some mountpoint>", so the boot seems to continue.

If ignoring these messages and just entering the passphrase (hitting the enter key in the end) works, if I am fast enough(!).

However, waiting for some seconds (maybe 20), it is *not* possible to correctly enter the passphrase any more: hitting the enter key after entering the passphrase does not start a new line or trigger any other notable action from cryptsetup (i.e., I don't get any "command failed" or "key slot xxx unlocked" messages). Hitting the enter key some times more does the job but the passphrase is rejected and asked for again up to three times. However, these new prompts always show the same behavior: hitting the enter key once does not start a new line or trigger the cryptsetup to continue as it should. Only hitting it some more times does but the passpharse is always rejected, even if entered correctly.

It seems that something in the subsequent boot chain partly steals keyboard focus.

Update 1 [see my comment 2 below]: This also affects recovery mode.

Update 2: It is also worth to note that after enetring the wrong password three times, I have no possibility whatsoever to logon, even though this should be possible as only the /home partition is encrypted. I have to reboot and try again until I succeed. *Very* annoying.

Update 3: It seems that specifying the "noearly" option in /etc/crypttab is a workaround for me (not systematically tested though).

[Christoph (christoph-thomas)]

Hi there,
got the same problem here. It seems if you wait for some time the message from mountall get hold of the console. As an (intermediate) solution you can hit enter once after waiting some time and then enter your passphrase and hit enter. This works for me.

Since 9.10 and the new upstart mechanism cryptsetup and mountall do not really work together.

[jott (ottjochen)]

Unfortunately, the solution that you suggest, Christoph, does not work for me: once I have waited too long, none of the three attempts you have to enter the correct passphrase will work.

Another update: this also affects recovery mode. In my case, I was *unable* to start in recovery mode at all (the timing seems to be even worse here). The only solution I had was to edit the grub boot line manually to add something like "init=/bin/bash" to get a recovery console ...

[disz (d-schlabing)]

Same Problem here after upgrading to 9.10.
I get it to accept my password if I first punch the keyboard like a monkey, hit backspace a sufficient number of times, type in my password and then hit enter. But it takes me usually about 3 iterations of that until that works.

[vbargsten (vbargsten)]

Same problem here.

@jott: Concerning

"Update 2: It is also worth to note that after enetring the wrong password three times, I have no possibility whatsoever to logon, even though this should be possible as only the /home partition is encrypted. I have to reboot and try again until I succeed. *Very* annoying."

This behavior can changed by the "retries" option in crypttab.

[jott (ottjochen)]

@vbar:

The problem at startup is not the "three times". This I could change by the option you suggest. The problem is rather that I *never* get a shell, even in "recovery mode". That is, I don't have a working recovery mode, and *that's* what I find annoying.

I also don't see how this bug is a duplocate of 461442. The situation described there is just about some unexpected error messages. My report is about something important actually not working. In the other bug I didn't see any complaint that the passphrase is not accepted. But this happens here.

[vbargsten (vbargsten)]

Actually I see it as duplicate of bug 462224, which itself is set to be duplicate of 461442 (I don't know why)

[Jens Getreu (getreu)]

Same setup as described in "Bug Description". Bug first appeared in 9.10:
I have to enter at least 2 times the passphrase. Sometimes even that does not work.

[Steve Langasek (vorlon)]

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

Do you have usplash installed, and are you booting with a graphical boot splash?

[jott (ottjochen)]

usplash is installed, but disabled due to (unrelated) problems with usplash (it just doesn't work ...).

I myself have now installed karmic from scratch and it works now (with usplash). However, I can still boot the old installation and the problem is still present.

[MetaChrome (imagenesis)]

This bug is still present. It is present not only on crypttab password prompts but also on /ecryptfs password prompts.

Encryption on boot with password is utterly broken because of this, and likely any other input at boot.

1. This issue still absolutely remains with the cryptsetup password prompts.
2. With ecryptfs, even though it appears that nothing has stolen the keyboard focus (ie data does not appear to be printed past the Password: semicolon) the string that is actually sent from the password prompt is incorrect. Pressing the enter key either does not do anything or it sends the enter key as a character in the password prompt.
3. This behavior also quite possibly messes up upstart event loop as evidenced by the following behavior:

If a mount of ecryptfs is after a mount of a swap from a cryptsetup unencrypted /dev/mapper, it specifies that /dev/mapper disk does not exist.

http://askubuntu.com/questions/387529/how-to-enable-crypttab-to-run-at-boot
http://askubuntu.com/questions/387463/how-to-decrypt-encryptfs-at-boot

As specified, when the ecryptfs mount entry in fstab is after the swap mount, it specifies that the disk does not exist and completely skips the ecryptfs mount without prompting for the password or recording said failure in /var/log/boot.log.

This is a critical bug. How has this been festering for 4 years. Does no one mount decrypt at boot?

Utter failure canonical.

[Steve Langasek (vorlon)]

This bug report is about a problem with cryptsetup and usplash. Ubuntu hasn't used usplash for years. This bug is therefore no longer valid. If someone is having problems with cryptsetup and plymouth, please file a new bug report.

And this has nothing to do with ecryptfs.