Keyboard not recognized during FDE password entry

[Ian Nicholson]

When I use the default grub boot option, my system presents me with a graphical prompt to enter my disk encryption password, but it doesn't register keypresses from my keyboard. If I use the recovery option in grub though, I'm able to enter my password.

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: linux-image-3.16.0-25-generic 3.16.0-25.33
ProcVersionSignature: Ubuntu 3.16.0-25.33-generic 3.16.7
Uname: Linux 3.16.0-25-generic x86_64
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: ian 3461 F.... pulseaudio
 /dev/snd/controlC0: ian 3461 F.... pulseaudio
CurrentDesktop: Unity
Date: Sat Nov 15 15:29:28 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-02-22 (266 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140221)
MachineType: TOSHIBA Satellite L875D
ProcFB: 0 EFI VGA
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.16.0-25-generic.efi.signed root=/dev/mapper/ubuntu--vg-root ro recovery nomodeset
RelatedPackageVersions:
 linux-restricted-modules-3.16.0-25-generic N/A
 linux-backports-modules-3.16.0-25-generic N/A
 linux-firmware 1.138
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
UpgradeStatus: Upgraded to utopic on 2014-11-05 (10 days ago)
dmi.bios.date: 12/06/2012
dmi.bios.vendor: Insyde Corp.
dmi.bios.version: 6.30
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: PLCSC8
dmi.board.vendor: AMD
dmi.board.version: Base Board Version
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: OEM Chassis Manufacturer
dmi.chassis.version: OEM Chassis Version
dmi.modalias: dmi:bvnInsydeCorp.:bvr6.30:bd12/06/2012:svnTOSHIBA:pnSatelliteL875D:pvrPSKFQU-003034:rvnAMD:rnPLCSC8:rvrBaseBoardVersion:cvnOEMChassisManufacturer:ct10:cvrOEMChassisVersion:
dmi.product.name: Satellite L875D
dmi.product.version: PSKFQU-003034
dmi.sys.vendor: TOSHIBA

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Is this on a VM? It appears similar to bug 1383851

[Ian Nicholson (imnichol)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/17/2014 12:18 PM, Joseph Salisbury wrote:
> Is this on a VM? It appears similar to bug 1383851
>
No, it's a Toshiba Satellite laptop

- --
Ian Nicholson
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUbf7SAAoJEBwDRDHt9Q7mpI4P/jJTciNT4Q0Eo0R3oeC1ZmuY
Qe3ALEMKebU1lzrVEIKcXgEB6fatGNNNkGBKcWiFLn+7/LF+wC1kpfkoY6BAp0wQ
hQn2kRopdhHeLZLK4ibVxfVj3JtE6PAGjvihJJVd1LOwmz4+4xPU37Z5ciKWighc
K7hM4i6r6dWjaTZaxlko4BVv/4RD8MnicYTyCsuaFG4Oc3OcmK7vn/a8E7LgDW29
6/fczZx0ywKtiUzGqN7dAmlr1kDm6FThtsGVIQJ7AiJOjKyJuwTKvxFIReC5pHBN
pGB01ZmpauLE1g+TTynqO86HoYS8g8eZZdLnyhFDeGy6Z3ukUjYzVEGlkNPsVNg/
zmek9LfxOX2cWRh2ehI4ZBsfOIDUzqQT6sZqwYDFHR+wEZMTzPLxoC4zNPj7CUbw
7sfP7JnYg66X+JGqwEGebCzVNF7KtLfpiotipKthH8Gc/0S8hhqurRrPfHsO1Dem
qjAhLaDPkLlXwLCdrGJ4c9ZqlwsTujhz3wbEXw5qqsW09/mhWXxLIeXat0/Ep5PL
2lxBD7VXYro+RNeh6XIoFBUkae7vn1wnbjUwQ4OmtLn3w52pinEen2+o+H7nZOCj
3+D0w2fQGWmDDyJvZY+0KxchIjB99Ixn0cLMilgfSX/1MbfxjHaVgwnrvGMWgJzh
46bOxkjSAQvWy1gSB/8d
=G7iV
-----END PGP SIGNATURE-----

[Ian Nicholson (imnichol)]

I've noticed that my system is exhibiting the following behavior:
In the BIOS, the numlock light turns on, and the capslock/numlock/scrolllock indicators reflect a change in state when I toggle those keys. The keyboard also registers input. In short, everything works fine.
In GRUB, all of the above holds true as well.
Once I'm prompted for my FDE password, any numlock/scrolllock/capslock lights that are on turn off, and cannot be toggled. IF however, I toggle the numlock key after the kernel loads but before I'm prompted for the password, the password prompt will appear, but the cursor will be located in the upper left corner of the screen and my password will appear in plaintext.

Additionally, if I use the recovery mode, I can boot the kernel and I'll be prompted for the password without the graphical interface, from where I can enter it normally and then select "Normal Boot" to continue booting.

Is it possible that this is actually a bug in plymouth or something like that? Otherwise, it does seem to be related to lp://1383851