Cryptsetup Keyboard not working on Xubuntu 3.19.0-30

Bug #1500751 reported by rolfinator on 2015-09-29
324
This bug affects 60 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Medium
Unassigned
Trusty
Undecided
Unassigned
Vivid
Undecided
Unassigned
initramfs-tools (Ubuntu)
High
Timo Aaltonen
Trusty
High
Brian Murray
Vivid
High
Unassigned

Bug Description

I am running Xubuntu 15.04 and just upgraded to the latest kernel (3.19.0-30).
After upgrading the boot time is longer (what is negligible) but the more severe error is, that I cannot enter my passphrase when I see the crypt dialog.
I just see the dialog to enter my passphrase, but when I try to enter it, nothing appears in the textfield. I tried with the builtin laptop keyboard but also with an external USB keyboard.

I thought about supplying more information, but things like the syslog are not helping apparently (I was not able to boot until the syslog would capture information...). If you need anything I can provide, I gladly help.

[Test case]
1. On an affected system boot into kernel 3.19.0-30

[Solution]
The "solution" for now is booting the older Kernel 3.19.0-28 (which isn't a real solution).

PS.: Bugs like the following are either not applicable or the solution is not working for me:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/229732
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1359689
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1238194

rolfinator (seb2) on 2015-09-29
affects: gnome-icon-theme (Ubuntu) → cryptsetup (Ubuntu)
description: updated

Same Problem here,

Ubuntu 15.04 / 3.19.0-30

rolfinator (seb2) on 2015-09-29
tags: added: 15.04 cryptsetup ubuntu vivid xubuntu
rolfinator (seb2) wrote :

Ah, great to see, that it's not only my configuration of the system, but affects more people...

There is another thing I experienced: The first time I boot, I cannot enter the passphrase as stated above. When I kill the laptop with the power button and boot again in the 3.19.0-30 kernel, I get a blackscreen. Strange.

@rolfinator (seb2) :

If you enter your password 10 seconds after the blackscreen, the boot will sucessfully continue.

rolfinator (seb2) wrote :

@himrenya (himrenya):

srsly, what the fu**
It worked like you said. There seems to be something fu**ed up with the graphics. After I entered the passphrase correctly, I saw a few lines running over the screen, I normally do not see (if everything works correctly).

Thanks though!

rolfinator (seb2) wrote :

So, I have a "fix" now in place, that is awful, but at least I do not have to boot, kill and boot again...
I edited /etc/default/grub and made the following changes:

I commented out the timeout for grub, in case I need to make some changes on the fly.
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=false

But the more important line is this:
GRUB_CMDLINE_LINUX_DEFAULT=""

So I removed the "quiet splash". This causes no Crypt screen to appear, but to go directly into "blackscreen-state" and therefore enables me to enter my passphrase (although, I don't see if/what I am typing). If the entered passphrase is correct, I see the OS.

nasos (nasos-i) wrote :

This affects two identical laptops of ours. We can only log on only if we pick the 3.19.0-28-generic at boot. Hope it is fixed soon.

Steve Langasek (vorlon) wrote :

If this problem is reproducible with the new kernel but not the old, then this is evidently a kernel bug. Reassigning.

affects: plymouth → linux (Ubuntu)
tags: added: regression-update
rolfinator (seb2) wrote :

You are probably right, Steve. Thanks for moving (however I tried to find the right project/audience in the first place)

Changed in linux (Ubuntu):
status: New → Triaged
Joseph Salisbury (jsalisbury) wrote :

I'd like to perform a bisect to figure out which commit introduced this regression. It would be very helpful to know the last good kernel and the first bad kernel.

Can you test the following kernels and report back? We are looking for the earliest kernel version that doesn't have this bug:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19.8-ckt5-vivid/
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19.8-ckt6-vivid/
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19.8-ckt7-vivid/

You don't have to test every kernel, just up until the first kernel that exhibits the bug.

Thanks in advance!

Changed in linux (Ubuntu):
importance: Undecided → Medium
tags: added: performing-bisect
Changed in linux (Ubuntu):
status: Triaged → Confirmed
John Rosauer (john-rosauer) wrote :

I have the same problem, too, on a Dell XPS 13 laptop. I had to go back to the previous kerb version.

John Rosauer (john-rosauer) wrote :

With respect to my last comment, i meant kernel version 3.19.0-28 works.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cryptsetup (Ubuntu):
status: New → Confirmed
rolfinator (seb2) wrote :

Same here on HP 820 G2. None of the kernels seem to have the issue.
If you follow my suggested solution from post #5, you won't have a graphical interface, but a text console to enter the key.

Changed in cryptsetup (Ubuntu):
importance: Undecided → Medium
Joseph Salisbury (jsalisbury) wrote :

This bug and bug 1501205 may be duplicates.

It sounds like this could be related to a SAUCE patch. Would it be possible for you to test this latest kernel and post back if it resolves this bug?
See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed.

Thank you in advance!

Changed in linux (Ubuntu):
importance: Medium → High
John Rosauer (john-rosauer) wrote :

Bug 1501497 is a duplicate of this one.

rp (rene-so36) wrote :

Same Problem to me.
tried enabling vivid-proposed - but vivid-proposed does not offer a kernel newer than 3.19.0-30.33
perhaps i missed something here...

Joseph Salisbury (jsalisbury) wrote :

I started a kernel bisect between Ubuntu-3.19.0-28 and Ubuntu-3.19.0-30. The kernel bisect will require testing of about 7 test kernels.

I built the first test kernel, up to the following commit:
2286f1ed6dab9794a72e7f246eafef7cfe637147

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1500751

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Changed in linux (Ubuntu):
assignee: nobody → Joseph Salisbury (jsalisbury)
status: Confirmed → In Progress
rp (rene-so36) wrote :

same thing, - no text accepted in the crypto-passphrase field with your provided 3.19.0-29.31.
but i have to admit that i dont feel confident with my judgement.

perhaps somebody else should report as well.... just to be sure...

anyway - thanks.

I'm confirming rp's experenence in comment 19: The bisected linux-image-3.19.0-29-generic version 3.19.0-29.31~lp1500751Commit2286f1ed still contains the bug, using that kernel I cannot enter the passsphrase.

Joseph, thank's for the deb:s of bisect builds! Let's try another one. :)

BTW, as I've mentioned in bug both of the following kernels works for me:

1. linux-image-3.19.8-031908ckt7-generic
2. linux-image-3.19.8-992-generic

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1501205/comments/8

Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
50031c9d633345cd2d5353fcd1ef954a0766026c

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1500751

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Tested version 3.19.0-29.31~lp1500751Commit50031c9d and it also/still has the bug.

This time it was slightly different compared to how I recall it from the
original case. I still cannot enter text in the cryptsetup area, but rather
than emitting the password at the upper left corner of the same virtual console,
the text appears in another virtual console - the same where the systemd
version is printed.

Sean Sosik-Hamor (sciri) wrote :

You can add one more XPS 13 to the list of affected systems. I'm about to EOD but can also test additional kernels starting on Monday. All my system info attached to duplicate LP Bug #1502171.

rolfinator (seb2) wrote :

@Fredrik Jonson (fredrik-jonson):
Yes, in the original bug I reported, there was no input possible at all

John Rosauer (john-rosauer) wrote :

@Fredrik Jonson (fredrik-jonson), @Sean Sosik-Hamor (sciri) :

In the original bad kernel, 3.19.0-30.33, if I typed many characters (maybe 30) and some carriage returns. the text did show up as described by @Fredrik Jonson (fredrik-jonson)

With 3.19.0-30, I am able to enter the passphrase if and only if I remove "splash" from the kernel command line arguments when booting. 3.19.0-28 works normally.

description: updated
Changed in cryptsetup (Ubuntu):
status: Confirmed → Invalid
rolfinator (seb2) on 2015-10-05
Changed in linux (Ubuntu):
status: In Progress → Confirmed
status: Confirmed → In Progress
Forest (foresto) wrote :

The Acer Aspire E5-571-53S1 (E 15) is also affected.

John Rosauer (john-rosauer) wrote :

This might not be a problem with the kernel, rather with grub. I assume it's grub setting up the splash screen GUI, not the kernel.

Just a thought.

Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
4b630e4e471c138161ab053471d97b0cdd367a31

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1500751

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Luke Faraone (lfaraone) wrote :

I am able to enter my passphrase (asterisks appear, boot continues on "enter") on 3.19.0-29-generic #31~lp1500751Commit4b630e4e on my Dell Latitude E7250.

Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
884feaefcd5a4b2a8ef10436f74077cef1330f6b

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1500751

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Tested linux-image-3.19.0-29-generic version 3.19.0-29.31~lp1500751Commit884feaefc and it also/still has the bug.

BTW, the latest release kernel, version 3.19.0-30.34, which showed up with regular updates on my laptop today, also has the bug.

Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
a036f6b179825b14ea0f8cd2e6333f8689930c6e

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1500751

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Thomas SIMON (dev.uhuru) wrote :

Same issue with the kernel aforementioned (3.19.0-30-generic) on Ubuntu GNOME 15.04.

Oddly booting with that kernel in recovery mode gets the keyboard to work (tried to fix dpkg from there but it can't download package, although it seemed there was one package missing).

Blindly entering the password doesn't work. I need to boot on 3.19.0-28 for being able to enter passphrase.

Tested linux-image-3.19.0-29-generic version 3.19.0-29.31~lp1500751Commita036f6b1 and it still has the bug.

Piotr Piwonski (bbrowaros) wrote :

Just to let you know I'm still on Ubuntu Kernel version: 3.19.0-30-generic and I'm experiencing this issue. However removing quiet splash from grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

allows me to boot to this Kernel version. The text version of the splash screen asking for password is working.
I've not tested any other Kernel versions so far.
Also on bug which I've created for this I was requested to update the BIOS, this was not done yet.

Regards,
Peter

Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
0ed67cf18a94983cea82a011df3c4f9f8314796b

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1500751

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

I've tested linux-image-3.19.0-29-generic version 3.19.0-29.31~lp1500751Commit0ed67cf1 and it has the bug too.

Guy Taylor (thebiggerguy) wrote :

I have just marked my issue as a duplicate of this (https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1504763).

A summary of my findings:
* Using kernel 3.19.0.28 works with graphical plymouth
* Using kernel 3.19.0.31 does not work with graphical plymouth
* Using kernel 3.19.0.31 does work without graphical plymouth
* Using 3.19.8-031908ckt7-generic works with graphical plymouth

So I am using http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19.8-ckt7-vivid/linux-image-3.19.8-031908ckt7-generic_3.19.8-031908ckt7.201509251130_amd64.deb without any issues.

This suggests the issue is with a local Ubuntu patch or it was fixed upstream.

Sebastian Gebhard (sege) wrote :

I have had the same problems on my machine.

For me kernel 3.19.8-031908ckt7-generic works and fixes the issue (as proposed by Guy Taylor).

Christian George (radu-j) wrote :

Any news about this at all, or any idea when the fix is going to be pushed in the repository ? It's very frustrating that we can't input the password on all our machines, or we have to use workarounds ..

Joseph Salisbury (jsalisbury) wrote :

I built the next test kernel, up to the following commit:
90dcba7eec2702302f06308e5140458cf840fa3b

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1500751

Can you test that kernel and report back if it has the bug or not? I will build the next test kernel based on your test results.

Thanks in advance

Luke Faraone (lfaraone) wrote :

Works for me on:

Linux calcium 3.19.0-29-generic #31~lp1500751Commit90dcba7ee SMP Fri Oct 9 14:19:00 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Morten Clausen (morten-c) wrote :

I can confirm comment #44.

Running 3.19.0-29-generic #31~lp1500751Commit90dcba7ee works fine for me on Thinkpad T450s.

Joseph Salisbury (jsalisbury) wrote :

The bisect reported 0ed67cf18 as the first bad commit. However, this also requires that I revert commit 53dfa1d. I built a Vivid test kernel with a revert of these commits. Can folks affected by this bug see if this test kernel resolves this bug and/or if it introduces any new issues?

The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1500751

Morten Clausen (morten-c) wrote :

The kernel from comment #46 didn't resolves the bug. The issue remains and even the reboot-workaround don't do the trick. When I disable splash then I can enter the passphrase, but afterwards the boot hangs with the kernel-log repeatedly stating

[drm:gen8_irq_handler [i915_bpo]] *ERROR* The master control interrupt lied (SDE)!

So it's almost the same behaviour as with the 3.19.0-30 kernel.

Thanks for your work so far and if you need any further information please let me know.

rolfinator (seb2) wrote :

@Morten Clausen (morten-c):
Same here. But just a question:
Did you have the same issues with the initial kernel I stated in the bug report here?
Ever since I updated to 3.19.0-30, the boot as well as shutdown messages are full of

[16925.079865] [drm:gen8_irq_handler [i915_bpo]] *ERROR* The master control interrupt lied (SDE)!

as well as the syslog.

Joseph Salisbury (jsalisbury) wrote :

I created a V2 test kernel since reverting only 0ed67cf and 53dfa1d still exhibits the bug. The V2 test kernel has the following four commits reverted:

86ad82b UBUNTU: SAUCE: i915_bpo: drm/i915: Split atomic wm update to pre and post variants
059c4a4 UBUNTU: SAUCE: Migrate Broadwell to i915_bpo.
53dfa1d UBUNTU: SAUCE: i915_bpo: Set ddi_pll_sel in DP MST path
0ed67cf UBUNTU: SAUCE: i915_bpo: drm/i915: Don't use link_bw for PLL setup

This test kernel can be downloaded from:

http://kernel.ubuntu.com/~jsalisbury/lp1500751

Luke Faraone (lfaraone) wrote :

V2 works for me. Confirmed V1 exhibits the bug.

Morten Clausen (morten-c) wrote :

I can confirm that 3.19.0-31-generic #36~RevertsV2 works without any of the issues.

@rolfinator (seb2): Yes I have the same issues with the 3.19.0-30 kernel stated in the initial post (plus some random system freezes, except the workaround "boot -> wait for dm-crypt passphrase, which can't be entered --> reboot --> enter passphrase" works on 3.19.0-30, but system freezes remain afterwards).

crt (crt-mori) wrote :

I can also confirm 3.19.0-31-generic V2 works without any dmesg bloat.

I can also confirm that 3.19.0-31.36~RevertsV2 works, it resolves the issue on a Dell XPS13 2015.

I noticed that the issue isn't resolved if I only install the linux-image package, it is only when I also install linux-image-extra-3.19.0-31-generic_3.19.0-31.36~RevertsV2 the issue is resolved. I wasn't aware that installing the extra package was a requirement.

The previous version, 3.19.0-31.36~lp1500751Reverts, still exhibit the bug, regardless if I have linux-image-extra for that kernel installed or not.

Timo Aaltonen (tjaalton) wrote :

The proper fix seems to be to add 'copy_modules_dir kernel/ubuntu/i915' to /usr/share/initramfs-tools/hooks/framebuffer, then run 'update-initramfs -k all -u'. Could you try that and boot stock -31 kernel?

Timo Aaltonen (tjaalton) wrote :

(for the record, Skylake and Braswell are affected too, they all use i915_bpo backport module which isn't included in the vivid initramfs)

Timo's suggestion in comment 54 resolves the issue with default ubuntu kernel:

 linux-image-3.19.0-30-generic 3.19.0-30.34
 linux-image-extra-3.19.0-30-generic 3.19.0-30.34

I applied the following change:

--- /usr/share/initramfs-tools/hooks/framebuffer.orig 2015-10-20 10:49:27.894272802 +0200
+++ /usr/share/initramfs-tools/hooks/framebuffer 2015-10-20 10:34:22.515012294 +0200
@@ -20,6 +20,7 @@

 copy_modules_dir kernel/drivers/char/agp
 copy_modules_dir kernel/drivers/gpu
+copy_modules_dir kernel/ubuntu/i915

 manual_add_modules fbcon
 manual_add_modules vesafb

And ran the command

 update-initramfs -k all -u

I have a Dell XPS 13 2015.

vmuzikar (vasam) wrote :

I can confirm that Timo's solution actually works!

Timo Aaltonen (tjaalton) on 2015-10-20
affects: linux (Ubuntu) → initramfs-tools (Ubuntu)
Changed in initramfs-tools (Ubuntu):
assignee: Joseph Salisbury (jsalisbury) → Timo Aaltonen (tjaalton)
Morten Clausen (morten-c) wrote :

I can confirm that the solution from #56 solves the problem with the dm-crypt password on boot, but there seem to be issues left. Still a lot of

[drm:gen8_irq_handler [i915_bpo]] *ERROR* The master control interrupt lied (SDE)!

in the kernel log. No system freezes so far, but I've only tested this for a few minutes. Should I open a new bug for this or should we extend this bug?

I can also confirm that the patch in #54/#56 works. I'm on a Lenovo ThinkPad X250.

Maciej Michno (radar) wrote :

Confirming too, works for me. I updated to the latest kernel, linux-image-3.19.0-31-generic and applied the fix.

Question: does this affect 15.10? Can I safely upgrade to 15.10 or should I wait?

Kyle Boone (kyboone) wrote :

I was experiencing this bug on 15.04, and just upgraded to Ubuntu-GNOME 15.10 (kernel 4.2.0-16-generic). The problem with the dm-crypt password on boot is gone, and I am able to boot successfully without patching anything. I do still get a lot of

[drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)!

messages in the kernel log though.

rolfinator (seb2) wrote :

@Morten Clausen (morten-c)

Imho it's better to open a separate bug. Extending this one doesn't make sense, since the problem may lay in another package and therefore will need another responsible person to take care of.
Anyway, I experience the same thing as you and @Kyle Boone (kyboone) ([drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)!)

Christian George (radu-j) wrote :

Please accept my apologies, re-tested and apparently it works well with kernel 4.2.0-16-generic . Seems like the bug is fixed with 15.10 .

Morten Clausen (morten-c) wrote :

Seems like there is already a bug filed for the

[drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)!

kernel message: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1488719

rolfinator (seb2) wrote :

@Morten Clausen (morten-c):

Thanks for bringing that up. Hopefully this bug will also be resolved soon...

Martin Mulazzani (mmulazzani) wrote :

Can confirm, not an issue on 15.10

Timo Aaltonen (tjaalton) on 2015-10-27
Changed in cryptsetup (Ubuntu Vivid):
status: New → Invalid
tiredpixel (tiredpixel) wrote :

I confirm that this issue has been experienced on Dell XPS 13 (9343), Ubuntu 15.04, not working with kernels `3.19.0-30-generic` and `3.19.0-31-generic`, but working with kernel `3.19.0-28-generic`, and that the `copy_modules_dir kernel/ubuntu/i915` described in #54 sorts the issue for kernel `3.19.0-31-generic`. Thank you, all! :) Peace, tiredpixel

Timo Aaltonen (tjaalton) wrote :

No need to me-too, it's well known by now.

This is actually a regression, since the 3.13 based kernel on 14.04 uses i915_bdw backport module for Broadwell, and it worked just fine with just the fallback framebuffer driver being available on the initrd. So if someone feels like doing a rough bisect, boot mainline kernel builds with 'nomodeset' boot option added starting from 3.14 and up, until it breaks.

Timo Aaltonen (tjaalton) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in initramfs-tools (Ubuntu Vivid):
status: New → Confirmed
Sean Sosik-Hamor (sciri) wrote :

Confirming fixed on linux-image-4.2.0-18-generic, however it took about 5 seconds before the password-entry screen would take any input from the keyboard.

andi_ (neelab) wrote :

same Problem here Ubuntu 15.04
testing now 15.10...

Changed in initramfs-tools (Ubuntu Vivid):
status: Confirmed → Fix Released
Changed in initramfs-tools (Ubuntu):
status: In Progress → Confirmed
status: Confirmed → Fix Released
Timo Aaltonen (tjaalton) wrote :

dirk-vdbiest: please don't mess with bug statuses

Changed in initramfs-tools (Ubuntu Vivid):
status: Fix Released → Confirmed
Changed in initramfs-tools (Ubuntu):
status: Fix Released → In Progress
Steve Langasek (vorlon) wrote :

This bug will also impact trusty by way of the hwe kernel stacks.

Changed in cryptsetup (Ubuntu Trusty):
status: New → Invalid
Changed in initramfs-tools (Ubuntu Trusty):
importance: Undecided → High
status: New → Triaged
Changed in initramfs-tools (Ubuntu Vivid):
status: Confirmed → Triaged
importance: Undecided → High
masand (markus-sand) wrote :
Download full text (3.7 KiB)

After searching and trying for a long, long time, I finally found a
solution which is acceptable for me. The situation is rather complex, so I
try to describe it as structured as possible.

Configuration
-------------
Hardware configuration:
DH87RL board
i7-4771 CPU
GeForce GTX 970

Software configuartion:
Ubuntu 15.10

Driver selection
----------------
You can either go with the open nouveau driver which is installed by
default, or use the proprieatary nvidia driver. Next, the "plymouth" package
which enables you to configure the graphical boot up, is strongly involved.
Using the nvidia driver together with plymouth does not work for me, but for
all other 3 possible combinations, the solution is described below.

There are 2 issues here closely connected, one is being able to enter the
password for encrypted hard disks during boot, and the other is being able
to switch to the console when X is up and running. Both issues are described
below.

Being able to enter the password for encrypted hard disks during boot
---------------------------------------------------------------------
Nouveau driver with plymouth:
The Nouveau driver works "ok" - this means I have to press the down arrow on the
keyboard while booting so the text mode appears. There, the password is
asked. (Some stars may already be displayed - delete them before entering the
password...)

This solution was ok, but I needed the nvidia driver to work, because with
nouveau, for example, I had no proper 3D acceleration inside virtualbox.

Nvidia driver without plymouth:
The nvidia driver I use is nvidia-352 currently. I installed it via apt-get.
So I did not download and install the driver from the nvidia.com site
directly, but used the distribution (in my case: Ubuntu 15.10) package for
the nvidia driver instead.

For the nvidia driver to work, I had to disable plymouth. This can be done
for example by passing the "noplymouth" option to the kernel parameters.

--- /etc/default/grub (example) ---
[...]
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noplymouth"
[...]

--- update-grub ---
Afterwards, execute update-grub from the command line:
# update-grub

With that changes, I can see the screen flicker shortly during the graphical
boot (obviously the password prompt appearing for a fraction of a second,
and then disappearing again). But now I know that the password
prompt is there, and I can start to type the password. The prompt will
reappear with the first character typed, having recognized the typed
character already.
If insecure whether the password prompt is ready or not, I can still press
the down arrow as described above.

Yes, that´s not a perfect solution - but after searching and trying for such
a long, long time: At least it is working - and you can get used to it.

Just out of curiosity, I also tried the nouveau driver with plymouth disabled:
In that case it works much smoother, as the password prompt really appears
and stays on the screen.

So it seems the free nouveau driver is doing something better than the
nvidia driver. I guess NVIDIA has some homework to do here!

Swith to console
----------------
With the nouveau driver, it is easily possible to switch to the co...

Read more...

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools - 0.122ubuntu6

---------------
initramfs-tools (0.122ubuntu6) xenial; urgency=medium

  [ Andy Whitcroft ]
  * uuids: only apply case mapping to RFC#4122 format uuids (LP: #1553107,
    #1548120)

  [ Timo Aaltonen ]
  * hooks/framebuffer: Copy kernel/ubuntu/i915 backport driver too. (LP:
    #1500751)

initramfs-tools (0.122ubuntu5) xenial; urgency=medium

  [ Andy Whitcroft ]
  * uuids: busybox tr does not support symbolic ranges expand manually
    (LP: #1548120)

  [ Martin Pitt ]
  * wait-for-root.c: Drop check if device is queued in udev (LP: #1539195)

initramfs-tools (0.122ubuntu4) xenial; urgency=medium

  [ Manoj Iyer ]
  * Add support for uppercase and lowercase uuids. (LP: #1548120)

 -- Andy Whitcroft <email address hidden> Fri, 04 Mar 2016 10:12:42 +0000

Changed in initramfs-tools (Ubuntu):
status: In Progress → Fix Released
Timo Aaltonen (tjaalton) wrote :

the vivid task can be dropped by now

Changed in initramfs-tools (Ubuntu Vivid):
status: Triaged → Won't Fix
Cindy Quach (cindyq) wrote :

Is there a reason why this wasn't backported to Trusty initramfs-tools? We just saw an incident of this with 4.2.0.36 on Trusty

Changed in initramfs-tools (Ubuntu Trusty):
milestone: none → trusty-updates
Changed in initramfs-tools (Ubuntu Trusty):
assignee: nobody → Brian Murray (brian-murray)

Hello rolfinator, or anyone else affected,

Accepted initramfs-tools into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/initramfs-tools/0.103ubuntu4.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in initramfs-tools (Ubuntu Trusty):
status: Triaged → Fix Committed
tags: added: verification-needed
Justin King-Lacroix (justinkl) wrote :

i915 drivers are now in the initramfs, as required.

tags: added: verification-done
Justin King-Lacroix (justinkl) wrote :

Any idea when this will be released to Trusty?

Brian Murray (brian-murray) wrote :

The Stable Release Update process requires a waiting period of 7 days so that we can watch for regressions. That means it'll first be eligible for publication on the 14th.

tags: removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package initramfs-tools - 0.103ubuntu4.5

---------------
initramfs-tools (0.103ubuntu4.5) trusty; urgency=medium

  [ Timo Aaltonen ]
  * hooks/framebuffer: Copy kernel/ubuntu/i915 backport driver too.
    (LP: #1500751)

 -- Brian Murray <email address hidden> Wed, 07 Dec 2016 01:27:28 -0800

Changed in initramfs-tools (Ubuntu Trusty):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for initramfs-tools has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

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

Other bug subscribers