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

Bug #1621367 reported by nicht-vergessen
This bug affects 3 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Marcelo Cerri

Bug Description

After updating to kernel 4.4.0-36.55, I cannot enter the password for the full disk encrypted drive, that contains the ubuntu installation.
Keyboard is totally dead. Nothing else than hardware reset is possible.

This bug affects normal, upstart and recovery boot.

I don't know whether that is a kernel panik (no led is blinking) or the driver for keyboard is failing. boot.log looks normal to me.

Last and working kernel version before the update, was "Ubuntu 4.4.0-34.53-generic 4.4.15".

I cannot report "ubuntu-bug linux", because I cannot enter the system.
I am willing to investigate, but please give me hints.

Revision history for this message
nicht-vergessen (nicht-vergessen) wrote :
Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

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.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
nicht-vergessen (nicht-vergessen) wrote :

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!

Revision history for this message
nicht-vergessen (nicht-vergessen) wrote :

..and the second one.

Revision history for this message
nicht-vergessen (nicht-vergessen) wrote :

Added Screenshots

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Changed in linux (Ubuntu):
importance: Undecided → Critical
Revision history for this message
nicht-vergessen (nicht-vergessen) wrote :

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.

Changed in linux (Ubuntu):
assignee: nobody → Thadeu Lima de Souza Cascardo (cascardo)
Revision history for this message
nicht-vergessen (nicht-vergessen) wrote :

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.

Revision history for this message
nicht-vergessen (nicht-vergessen) wrote :

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

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

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

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"
  echo " ... skipped"

Changed in linux (Ubuntu):
assignee: Thadeu Lima de Souza Cascardo (cascardo) → Marcelo Cerri (mhcerri)
Revision history for this message
CaptainPlanet (captainplanet) wrote :

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!

Brad Figg (brad-figg)
tags: added: cscc
Revision history for this message
anon697725 (anon697725) wrote :

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.

Revision history for this message
Matthias Kruzenski (m4dm4x1337) wrote :

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:


In addition, you should execute the following commands:

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

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.