4.4.0-36: keyboard dead at boot & full disk encryption prompt for password

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1621367

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

I cannot run apport-collect under the affected kernel since the kernel does not boot beyond full-disk-encryption passphrase.

I'm adding camera shots of both kernels, working (-34) and non-working (-36)
The latter one does not show a newline at the end of the password prompt output!

..and the second one.

Added Screenshots

Hello,
I tried to investigate a bit: So I noticed that the compression method propably changed from gzip to bzip2, didn't it? The size does differ at least, and my GUI tools where not able to uncompress the versions 36 and 38. These are the one that I cannot boot into.

-rw-r--r-- 1 root root 37M Aug 7 17:00 /boot/initrd.img-4.4.0-31-generic
-rw-r--r-- 1 root root 37M Aug 21 16:28 /boot/initrd.img-4.4.0-34-generic
-rw-r--r-- 1 root root 16M Sep 14 20:06 /boot/initrd.img-4.4.0-36-generic
-rw-r--r-- 1 root root 16M Sep 23 01:11 /boot/initrd.img-4.4.0-38-generic

I have bzip2 installed.

But when is the full-disk encryption password prompted for? Within the initrd stage, after that has been loaded or before? So might bzip2 not be available at that time or is initrd loaded, but other changes are the reason for the kernel panik at password promt?

I am willing to investigate, but you'll have to give me some directions / hints.

Okay, first of all: I'm sorry for not reporting back earlier.
Asides that, I still consider this as a bug and bad user experience, as we / the linux community strives to encourage people to secure their systems and encrypt or sign content.

Shortly after I reported in September I had no better solution than to reinstall the whole system, because there was no bootable kernel left in the grub menu.

I've installed the desktop same as before and as advised to the public:
  - full disk encrypted
  - automatic updates enabled

Some time after that I ran into the same problem, but this time I had some time to dig deeper AND I remembered from the installation procedure that there was a message about my enabled Secure Boot flag in the UEFI BIOS.

Given that I found out that there are installed kernel modules from the
  - integrated Intel Graphics
  - nVidia Graphics card
  - Virtual Box Networking Modules
which are signed but not under the new kernel (apt-get dist-upgrade has run).

Temporary solution for me:
I found a guide to sign those modules with a self-signed certificate and enroll this within Secure Boot. Furthermore I hacked a script that looks for the currently installed and other available kernel versions and offers to sign all installed kernel modules ahead of rebooting the new kernel.

Possible solution for everyone affected:
Since my solution involves a manual task and self-signed certificates it is not that suitable to the "faint hearted" masses, that don't even get that close to any other solution than to disable SecureBoot at all (Numerous "hints" in the Ubuntu forums or StackExchange lead people to disable it, although there is a way to make it work.)

- I think a better approach whould be to force creation and presence of self-signed certificates during the installation phase or during kernel upgrades.
- Additionally post-kernel-upgrade installation steps should automatically look for a (default location/filename of) signature certificate and sign remaining kernel modules.

I know this approach might "white-label" kernel modules of unknown source, but I think this is the lesser pain than disabling secure boot at all.

Contrary the current state leaves users of full disk encryption and Secure Boot without any clue on what went wrong since the last shutdown or reboot.

here's the script for signing kernel modules of any existing kernel version

#!/bin/bash
######
# https://github.com/Canonical-kernel/Ubuntu-kernel/blob/master/Documentation/module-signing.txt
######
kernelName=`uname -r`
echo
echo "currently installed kernels:"
ls -d /usr/src/linux-headers-*
echo
echo "currently booted kernel: \"$kernelName\""
echo -n "which kernel to sign? "
read kernelName
echo $kernelName

echo
echo "signing modules for kernel \"$kernelName\" (`mokutil --sb-state`)"
echo

for module in /lib/modules/${kernelName}/updates/dkms/*.ko ; do
 echo -ne "\t-" $module
 tail -n1 $module | grep -aq '~Module signature appended~' > /dev/null
 if [ $? -eq 1 ]; then
  sudo /usr/src/linux-headers-${kernelName}/scripts/sign-file sha256 ./MOK-selfsigned-kernel-module.priv ./MOK-selfsigned-kernel-module.der ${module}
  echo " ... OK"
 else
  echo " ... skipped"
 fi
done

Hi,
I'm affected by this or a similar bug too. Interestingly the keyboard does work in BIOS and GRUB. To my suprise a USB Keyboard from my neighbor worked.

Thank you https://launchpad.net/~nicht-vergessen for investigating this bug!

I've recently installed Ubuntu 14.04 LTS server on two different computers when I ran across this issue. (For legitimate reasons newer versions of Ubuntu was not an option).

One one computer I was able to enter the password and on the other I was not able to enter the password.

The difference is the keyboard and the problem follows the keyboard being used.

When you use a Logitech USB keyboard you'll notice that the USB subsystem only recognizes the "Logitech USB Receiver" but does NOT register the mouse and keyboard. Hence the keyboard is non functional at the "Enter passphrase:" to unlock the encrypted partition. It's surprising because the keyboard will work at the Grub screen.

But using a different brand keyboard it'll get registered as a recognized input device and viola you can enter the password.

Once you enter the password then you can switch back to the Logitech keyboard because it'll eventually get picked up as a valid input device.

A purely speculative assumption:

For some reason, Logitech hardware can immediately go into autosuspend mode.

To prevent this, you can add the following kernel command line parameter:

usbcore.autosuspend=-1

In addition, you should execute the following commands:

tee --append /etc/modprobe.d/usbcore.conf << EOF
options usbcore autosuspend=-1
EOF

update-initramfs -u -k all

Note: It depends on the kernel from where the configuration is read, so it is best to add both the parameter and the config file.

It may also be helpful to use a different USB port.