4.4.0-40-generic no prompts for disk encryption + loops on dots load screen

[Alexandre]

Since the upgrade to Ubuntu's 16.04.1 Linux kernel 4.4.0-40.60, it is impossible to boot my machine with full root encryption.
It will keep loading the purple Ubuntu "dots" loading screen for ages and stay there.

There is no issue rebooting back with kernel 4.4.0-38.57.

I tried recreating the initramfs to no avail:
update-initramfs -d -u -k 4.4.0-40-generic

Hardware is a Dell Laptop: XPS13 9350 16GB/i7/512GB SSD.

[Alexandre (totalworlddomination)]

4.4.0-40.60 seems to have issues with booting for others too (and a Dell too):

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1627670

Not sure if related as I don't see a kernel stack trace at all...

[Joseph Salisbury (jsalisbury)]

I'd like to perform a kernel bisect to figure out which commit caused this regression. We need to identify the earliest kernel that did not exhibit the bug and the first kernel that did exhibit the bug.

Can you test the following upstream kernels and post back?

v4.4.19: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.19
v4.4.20: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.20
v4.4.21: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.21

You don't need to test all of them. Just up to the version that first exhibits the bug.

Thanks in advance!

[Alexandre (totalworlddomination)]

Just tested v4.4.20 and v4.4.21 and both worked by showing the luks password prompted and then booted.
As a result I didn't test .19, should I ?

The luks password prompt might be a different issue than the kernel stack trace one?

[Joseph Salisbury (jsalisbury)]

That fact that 4.4.21 does not have the bug indicates this is a Ubuntu specific bug.

We can bisect between -38 and -40 to find the commit that introduced this.

Can you first test the latest kernel that is in Xenial -proposed? It can be downloaded from:
https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+build/10960867

[Alexandre (totalworlddomination)]

-41 is booting just fine, seems like only -40 is broken.

[Joseph Salisbury (jsalisbury)]

Thanks for testing. That is good news. There was only one commit added to -41 and that seems to be the fix for this bug:

commit e9820e415895bdd9cfd21f87e80e3e0a10f131f0
Author: Kamal Mostafa <email address hidden>
Date: Mon Sep 26 15:29:52 2016 -0700

    UBUNTU: (fix) NVMe: Don't unmap controller registers on reset

[Alexandre (totalworlddomination)]

Ah, that makes sense, NVMe is pretty common on newer (Dell among others) laptops.

Thanks! :)

[kralisec (kralisec)]

Like 1st post, exactly the same for me with new kernel 4.4.0-42.62

Hardware: Dell E5410/4GB i5/512Gb SSD, 16.04.1 LTS 64b full root encryption.

Drop to initramfs without prompting to enter luks password.

Boot back with previous 4.4.0-38.57 is fine, no solution with update-initramfs -u

Can I test something ?

[Alexandre (totalworlddomination)]

As a reference, 4.4.0-42.62 works fine with LUKS on the XPS13 9350 512GB SSD.
Maybe something else than NVMe this time... :/

[kralisec (kralisec)]

Ok, problem solved, nothing related to the kernel, sorry for the post :(

in short: I install new ram the day before, around 15 boot crash with testing,
it he process I lost pam.d/common-auth file and /etc/crypttab ...

This missing file let me think I have the same bug.

Now 4.4.0-42.62 is fine :)