plymouth ask-for-password doesn't register all of my keypresses when typing passphrase

[Steve Langasek]

Binary package hint: plymouth

When using plymouth ask-for-password to prompt for a luks passphrase, I have to type slowly and verify each keypress is registered on the screen before continuing, because around 30% of my keypresses are not registered at all by plymouth.

ProblemType: Bug
Architecture: amd64
Date: Tue Dec 15 11:08:52 2009
DistroRelease: Ubuntu 10.04
Package: plymouth 0.8.0~-5
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-8.12-generic
SourcePackage: plymouth
Tags: lucid
Uname: Linux 2.6.32-8-generic x86_64

[Scott James Remnant (Canonical) (canonical-scott)]

Which keys did you press (in order), and which did it recognise and which didn't it?

[Steve Langasek (vorlon)]

It's not consistent across attempts. On a crypted disk set up for testing with a passphrase of 'meep', on one occasion I had to type 'mmeeepp<enter><enter>' to get the passphrase fully entered. On another occasion, 'meeep<enter>' was sufficient. The backspace key is also affected.

On another disk with a more secure passphrase, a wider range of lower case letters and the spacebar showed the problem. I don't recall if the problem manifested for upper case letters, punctuation, or numbers.

[Steve Langasek (vorlon)]

After a few more reboots, my impression is that this is a timing thing: if I type more slowly, plymouth's success rate increases. It looks like maybe plymouth ignores any keypresses that happen while it's still processing the preceding one?

[Scott James Remnant (Canonical) (canonical-scott)]

If you run plymouth under X (plymouthd ; plymouth --show-splash) and use the plymouth to put up a passphrase prompt, does it work?

ie. is this just a console thing; if so could be another symptom of bug #496784

[Steve Langasek (vorlon)]

Running plymouth under X, this problem does not appear to be reproducible for me.

[Scott James Remnant (Canonical) (canonical-scott)]

My working hypothesis is that because plymouth is not quite on vt1 or vt7, key presses go to one or the other, and some get missed

[Luke (lukekuhn)]

  I had to remove printf '\033[?25l' > /dev/tty7" from /usr/share/initramfs/scripts/init-top/plymouth as part of my edits to that script to get plymouth to work. It worked everywhere BUT in the initramfs, leaving that script as the culprit.

This presumably forces Plymouth to stay on vt1, I have no problem with passphrase keypresses being missed, though I get no feedback in the box(another bug). If you have only one encrypted device, this might be an acceptable workaround.

[Launchpad Janitor (janitor)]

This bug was fixed in the package plymouth - 0.8.0~-7

---------------
plymouth (0.8.0~-7) lucid; urgency=low

  * Fixed a bug where we couldn't load the script plugin if it were
    compiled without optimisations.
  * Attempt to work around issues with VT switching and fbcon reasserting
    over our output. LP: #496784, #497115.
  * Don't attach to the session for now, this code path doesn't work with
    the current console/VT code. LP: #502494.
 -- Scott James Remnant <email address hidden> Mon, 11 Jan 2010 13:47:36 +0000

[Steve Langasek (vorlon)]

I'm afraid this problem is still reproducible for me. My setup matches Luke's, in that plymouth starts (and prompts for a passphrase) in the initramfs.

I haven't tried the proposed change to drop the printf line from the initramfs script.

[Steve Langasek (vorlon)]

After a kernel upgrade this does seem to be solved; closing again.

[Luke (lukekuhn)]

  This but is BACK with newer versions of Plymouth on the MSI Wind U100 netbook, but NOT on my AMD

[Luke (lukekuhn)]

 My last comment get involuntarily saved too soon-here is is in full.

  This bug is back with newer versions of Plymouth(0.8.0~-10, 0.8.0~-12) on the MSI Wind U100 netbook, but NOT on my AMD Phenom II x4 desktop. I saw it for the first time with the same updates that fixed the "no message or cryptsetup prompts" bugs, having never had this problem before.

 I've simply lived with this, and suspect it is related to processor speed and capability.The Intel Atom is relatively slow, and the the Phenom II very fast. Strangely, the problem on the netbook varies from boot to boot, sometimes taking every keypress, sometimes so bad only power cycling (for another try giving different results) will allow booting with a long, high-security passphrase.

[Dirschl Andreas (dirschl-andreas)]

This problem is not solved already. It happens since yesterday. I reopen the bug.
Running lucid beta1 with latest updates amd64.
plymouth 0.8.1-1ubuntu1
acer aspire 5740G
fglrx
I had no problems with the plymouth text splash. Now I have the graphical splash and it behaves like Steve described.
It seems to randomly don't recognise keyhits when I type my LUKS pathphrase. It seems that more Uppercase letters and numbers are affected, than lowercase letters. But I'm not shure, could be randomly also.

[Steve Langasek (vorlon)]

Please open a separate bug report for your issue.

[Swâmi Petaramesh (swami-petaramesh)]

Isn't bug #537793 a duplicate of the present one ? They really look the same.

Either way, I suffer from both (and none is solved) Plymouth 0.8.1-1ubuntu3 ;-)

Plymouth definitely misses keypresses here when running from initramfs to unlock an encrypted root fs.

I've seen the bug with all Plymouth versions since Lucid Beta so far.

I would describe it this way : On Plymouth passphrase dialog, I have to type SLOWLY and keep keys pressed firmly and long enough and check that a "bullet" is displayed for every key I press. If I type "normally fast", Plymouth misses 10-20% of the keys pressed.

Of course my machine's keyboard works perfectly once machine is booted...

[Steve Langasek (vorlon)]

Don't reopen this bug, the submitter says it's fixed.