Password not accepted graphical boot for encrypted root system

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

I have reproduced this problem in local testing, but it was only by accident in a configuration that is not expected to happen on a real system (namely, by manually removing vt.handoff=7 from the kernel command line).

Please run 'apport-collect 1386005' from the affected system, and attach your /etc/default/grub.

It's quite possible that this is a problem specific to your use of uvesafb. This is not a supported or tested configuration in Ubuntu; indeed, nvidia upstream insists that use of framebuffer kernel drivers with their binary driver is unstable and leads to video corruption. If this is only reproducible with uvesafb, it will be a low priority to fix.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Given that you have uvesafb configured, I'm surprised to see that you don't have anything in /proc/fb. I wouldn't expect this to change as a result of booting in recovery mode, since I don't think uvesafb is a KMS driver and is therefore unaffected by the 'nomodeset' boot option. Also, it seems you're passing 'nomodeset' even in your default boot config.

If you disable the use of uvesafb in /etc/default/grub (by setting GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"), do you experience any problems? This is probably the most straightforward workaround for right now. It won't give you a graphical plymouth splash, but it also won't force you to use recovery mode to boot.

I'd like to point out a couple of things that were lost when my bug was merged with this one:

1. This bug happens every time a distribution upgrade of Ubuntu comes out. It's been happening since Warty, and I've had to report the problem and wait a couple of months for a fix every time.

2. Every time this happens you guys are utterly surprised like you've never seen anything like it, and you poke and prod at the people reporting the bug to try a bunch of different configuration changes to see if they can fix the problem themselves. That is not acceptable behavior.

This creates a number of problems:

1. You're treating Ubuntu like it's Joe Distro, your average linux distribution that is thrown together by some bored computer nerd in their basement for fun in between raids in World of Warcraft, or whatever game it is kids are playing these days. But the reality is that Ubuntu ships on hardware from OEMs. Actual, real computers and embedded systems that people buy and expect to work. So when a problem like this happens to the average user who is not technically astute in troubleshooting a complex operating system, this means that a bunch of people are going to restart their computer and go "huh, I can't log in. I enabled encryption and now my computer doesn't work. I don't trust this OEM anymore."

2. This is a repeating, critical problem. This isn't a problem that prevents you from browsing the web or from playing games, it completely disables access not only to your operating system but to all of your files as well. How you guys can see this happen once and not have some process in place to check that it doesn't happen with the next build is beyond me; how you can let it happen every single time there's a new version out is preposterous.

For every Ubuntu user who reports this problem there are hundreds who don't understand what's going on and just think their computer is broken.

How are they even supposed to use ubuntu-bug if their computer won't start?

This should be a P0 bug because anyone who experiences this problem has a critical issue but you're treating it with the same level of importance as a minor inconvenience.

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

Steve,

Removing video=uvesafb from /etc/default/grub does allow me to boot without going to recovery mode. This does confirm an interaction with either v86d or uvesafb with respect to the input problem. I am not sure if my problem is related to Josh's as it is not clear whether he is using uvesafb. I am clearly comfortable modifying the OS boot scripts, etc. and thus I don't consider this a high priority problem. By installing the NVIDIA drivers and uvesafb, I am taking on some of the responsibility for any problems that develop. Thanks for reviewing this.

Hi,

are these the same bug#1386836 and bug#1387107?

Also present with a new installation in Vivid Alpha 1 for Ubuntu Gnome.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1386005

Ron, do you mind if we "commandeer" your bug to handle the latest reported cases? We could open a new one, more specific to the use of uvesafb in your configuration, and making it clear enough in the title that it's unmistakably a different problem than anything else?

Josh, I have no history dealing with you or your bug reports. I'm unaware of any of the previous details, but I also happen to be the person to look at these bug reports now. Let's proceed simply and logically. I will de-duplicate your bugs so I can go through the attachments more easily and threat your bug with the attention it deserves -- however, I like I said above I do not have the previous details. It would be helpful if you could point me to the right previous bugs so I can see what the issue has been in the past and how it was resolved -- please do so in your own bug report, bug 1385027. This could also be a very different problem and thus still require that we get additional data from you; and other bugs may come up with a higher priority that I will need to address first.

Since this bug report has a few instances of being noted in daily iso testing, I'm going to keep it at priority Critical. This could be a High, but the workaround isn't necessarily obvious if the computer you'd use to get to see the workaround appears to not be usable.

Documentation on the workaround still needs to happen in the bug report here; in the description.

This stays at confirmed for now and I will try to reproduce with a daily ISO on a system which would more likely exhibit the issue and push to Triage as necessary, or ask for more information here.

Mathieu,

I have no problem with your commandeering my bug, if that helps getting the
issue resolved. What do you need me to do, if anything?

Ron

Let's just open a new bug report specific to your configuration; something like "[uvesafb] [v86d] prompt input echoed on the side of the screen", along with your /etc/default/grub and other attachments. That way it's clear what the issue is, and also clear that the problem is very specific to uvesafb/v86d; to avoid unrelated me-toos.

OK, however I am not going to be able to create the problem report for a
week or so as I am on the road until then.

Ron

On Mon, Feb 2, 2015, 09:11 Mathieu Trudel-Lapierre <email address hidden>
wrote:

> Let's just open a new bug report specific to your configuration;
> something like "[uvesafb] [v86d] prompt input echoed on the side of the
> screen", along with your /etc/default/grub and other attachments. That
> way it's clear what the issue is, and also clear that the problem is
> very specific to uvesafb/v86d; to avoid unrelated me-toos.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1386005
>
> Title:
> Password not accepted graphical boot for encrypted root system
>
> Status in plymouth package in Ubuntu:
> Confirmed
>
> Bug description:
> After upgrading to 14.10 from 14.04, I am unable to enter my password
> for decypting the root filesystem. The password is echoed in plaintext on
> the graphic boot screen and does not show up in the password entry box on
> the graphic. In order to boot the system, I have to boot in recovery mode
> and enter the password during the text mode boot. This problem was also
> described by another user in problem# 1385027. I did not have a probem in
> 14.04. I am using nvidia drivers. I am set to resolution 1920x1200. I
> am running module uvesafb with changes to /etc/default/grub for the module
> and resolution. I assume this is a plymouth package bug but am not
> positive.
> ---
> ApportVersion: 2.14.7-0ubuntu8
> Architecture: amd64
> CurrentDesktop: Unity
> DefaultPlymouth: /lib/plymouth/themes/ubuntu-logo/ubuntu-logo.plymouth
> DistroRelease: Ubuntu 14.10
> InstallationDate: Installed on 2014-04-21 (189 days ago)
> InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64
> (20140417)
> MachineType: Dell Inc. Latitude E6500
> NonfreeKernelModules: nvidia
> Package: plymouth 0.9.0-0ubuntu7
> PackageArchitecture: amd64
> PccardctlIdent:
> Socket 0:
> no product info available
> PccardctlStatus:
> Socket 0:
> no card
> ProcCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-37-generic
> root=/dev/mapper/hogwarts_vg-root ro recovery nomodeset
> ProcFB: 0 VESA VGA
> ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-37-generic
> root=/dev/mapper/hogwarts_vg-root ro recovery nomodeset
> ProcVersionSignature: Ubuntu 3.13.0-37.64-generic 3.13.11.7
> Tags: utopic
> TextPlymouth: /lib/plymouth/themes/ubuntu-text/ubuntu-text.plymouth
> Uname: Linux 3.13.0-37-generic x86_64
> UpgradeStatus: Upgraded to utopic on 2014-10-23 (4 days ago)
> UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
> _MarkForUpload: True
> dmi.bios.date: 12/06/2011
> dmi.bios.vendor: Dell Inc.
> dmi.bios.version: A27
> dmi.board.name: 0PP476
> dmi.board.vendor: Dell Inc.
> dmi.chassis.type: 8
> dmi.chassis.vendor: Dell Inc.
> dmi.modalias: dmi:bvnDellInc.:bvrA27:bd12/06/2011:svnDellInc.:
> pnLatitudeE6500:pvr:rvnDellInc.:rn0PP476:rvr:cvnDellInc.:ct8:cvr:
> dmi.product.name: Latitude E6500
> dmi.sys.vendor: Dell Inc.
>
> To manage notifications about this bug go to:...

I don't know if this is considered recovery mode but going this route allowed me to workaround it (am running Ubuntu MATE 15.04 Beta 2 in a Virtualbox guest), but of course no longer have a graphical boot..:
http://ubuntuforums.org/showthread.php?t=2251116&p=13158092#post13158092

Martin Wimpress lists what I did as a solution to Virtualbox Guests showing up as 640x480 resolution.
https://ubuntu-mate.org/blog/ubuntu-mate-vivid-beta2/#disqus_thread

I reported this bug too and it was marked as a duplicate. I thought I'd add my description in case it helps. I'm seeing some really strange behavior, not as critical as it not booting at all, but it is counter intuitive. When I boot, the screen appears blank until I press the down arrow key (regular keys don't seem to do anything), at which point the screen shows a command line password box. Pressing the key again shows the regular gui. This affects a fresh install of Ubuntu Mate 14.10. Watch the attached video to see what I have to do each boot.

I don't think that this bug is a duplicate of bug #1359689 because in this bug we can see the right screen asking for the passphrase, but we are unable to write the password in the right place (as you can see in this attachment http://i.imgur.com/x3cPMbk.jpg from bug #1386836, which is correctly marked as a duplicate of this one).
Instead in bug #1359689 there is a graphic problem which doesn't allow to see the right passphrase screen.

@Josh (majik) wrote on 2014-10-28:

+1 Wow I couldn't have said better. I have exactly the same issue over and over again with the new distribution upgrade of Ubuntu. For me also it started since Warty. And every single time I spent days on web to figure out how to fix it. Now I'm searching how to fix it on 15.04. Ubuntu is definitely a toy OS.

I agree with #49 that this is *not* a duplicate of #1359689 for the reasons stated in that comment. Hence un-duping.

This affects me as well. Adding my scenario which is similar.

I'm running Ubuntu 15.04 on a Dell XPS 13. I installed with the encrypted LVM option. Typically, I boot, I get the purple screen asking for my encryption passphrase, I put it in, then it goes to the standard login screen.

Now, I boot, I get that purple screen for the passphrase, but I can't seem to type anything. Even if I type my password and click enter, the screen doesn't change. I hold the power button to shut off and then I boot again. This second boot goes straight into Grub. I choose to boot Ubuntu, and it goes to a purple screen for me to enter my passphrase. This screen seems to be a low quality text screen however. I can type my passphrase just fine on this screen and then it goes to Ubuntu's login screen from there.

Adding onto this bug because I also have the same problem while running Ubuntu 15.04 on a Lenovo T450s.

As with the other users attempting to boot puts you into the decrypt screen with a nice empty password box, but keyboard strokes do not appear to register, as if the decryption password had not been selected. The keyboard does recognize ctrl+alt+delete, which reboots into grub and hence into the same text-based decryption window that lets you enter your password.

This is a recent problem for me. I upgraded to 15.04 some time ago, but the problem only really appeared within the last week, possibly due to a dist-upgrade to linux-image-3.19.0-28 or linux-image-3.19.0-30. Unfortunately I'm not sure which upgrade I did when, and what else came in at the same time (I let my laptop sit a little too long without rebooting).

re Matthew Norman:
I have also had an issue going from linux-image-3.19.0-28 to linux-image-3.19.0-30 and am tracking it via https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1504763

Facing same problem on Ubuntu 15.10

I also experienced the same problem, after installing the proprietary Nvidia drivers and following the instructions at http://www.webupd8.org/2010/03/how-to-get-plymouth-working-with-nvidia.html to re-enable plymouth on my proprietary Nvidia driver.

Right now, I'm undoing the graphical plymouth fix so I can boot by entering my encrypted password, but all I get is a text-mode plymouth.

Before I forget, I'm also using Ubuntu 15.10

Adding GRUB_GFXPAYLOAD_LINUX=auto to the grub config solved the issue for me. However, as soon as I install any fglrx driver (which worked on Trusty), X crashes ... (https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1493888)

I am also experiencing the same problem on 15.04. It use to work and then after one of those software update (I don't remember which one) it would now not let me type my password for decrypting the hdd. I would have to power off and power on again, see grub choose Ubuntu and then it would go into the non graphical prompt (still purple) which would allow me to enter the password and proceed to the normal log in screen.

Same experience here. Now the fglrx drivers work again (fix in proposed) but, the previous grub workaround doesn't. So far, the only option was to remove "splash" :-(

I've also encountered this bug on 15.04, and am currently suffering from it. I upgraded to linux-image-3.19.0-30 and this problem manifested itself, and then when -31 came out shortly after I held out hope for a fix, but thus far have had no joy. I've yet to try any of the workarounds in the bug, though, and just been booting into -28 to bypass the issue.

I am also experiencing the same problem on 15.04. Same symptoms: works fine with linux-image-3.19.0-28, but not with -30 and -31.

I've just upgraded my 15.04 machine to kernel 3.19.0-32, and I continue to experience this bug, as I did with -30 and -31. The suggestion in comment #32 above (https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1386005/comments/32), which is to set GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" in /etc/default/grub, does not change things for me.

After upgrading to 15.10. my problem seems to have resolved and I'm now able to enter my decrypt password.

I have the same problem - and it's not the first time, either. Even though I didn't report a bug, before (just worked around it), I agree with Josh: [K]Ubuntu does not seem to have the QA it should do!

I encounter the same problem again and again on different computers (not sure anymore, but probably all of them using an NVidia card) for quite a few versions/years, already (I think the first time was 10.04 or 12.04, but I'm not sure anymore).

Here's my current scenario:

First the relevant output of lspci:
01:00.0 VGA compatible controller: NVIDIA Corporation GK107 [GeForce GT 740] (rev a1)

And here's what I did:
I installed Kubuntu 15.10 from scratch (no upgrade) with full system encryption. On this machine, I don't use LVM (because I have plenty of RAM and don't need swap), but I encountered the same problem before with the automatic "guided partitioning" setting up LVM in an encrypted container. Thus, LVM has obviously no effect - the problem seems to be related to encryption + graphics card only. On this machine, the root fs (/) lies directly in a LUKS container located on sdc3 (as said: no LVM).

After the fresh installation, which uses the nouveau driver, my screen is entirely blank when booting. Only after I press ESC (grub or plymouth or whatever is in charge seems to switch from graphical to text mode) I see a password prompt. When I press ESC again, it switches back to the graphical mode and I can enter the password there, too (both text + graphical mode work - but only after pressing ESC at least once).

Unfortunately, my system froze far too often. This problem happens with Kubuntu 15.04 too (located on sda), but only once in a week or so. With Kubuntu 15.10 it froze multiple times daily.

Since I suspected the graphics being the cause of the trouble, I wanted to give the binary nvidia driver a try. Thus, I switched to the proprietary driver using the KDE graphical driver manager. AFAIK it does nothing else than installing nvidia-352 and a few other nvidia-* packages.

I then rebooted and the graphical password prompt appeared - but I could not enter anything. I still tried to enter my password + press enter thinking that only the feedback is broken, but no: it does not work at all. Thus, I booted choosing the recovery mode and then selecting "resume".

Btw. in contrast to the nouveau driver, ESC has no effect when booting with the proprietary driver: The system seems completely frozen asking for the disk password during boot.

I'm on Xubuntu 15.10 (fresh install) and this bug affects me too.
I can provide any logs/information if necessary.

Same problem on fresh install of encrypted lvm root with lvm swap of ubuntu 15.10 with amd graphics using open source amd. Work around seems to be revise /etc/default/grub to:
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="quiet splash"
followed by "sudo update-grub2" and "sudo update-initramfs -u" and "sudo grub-install /dev/sda"

This causes /boot/grub/grub.cfg to change the linux line to end in quiet splash

linux /vmlinuz-4.2.0-22-generic.efi.signed root=/dev/mapper/vg-root ro quiet splash

I wonder if the normal line ending of $vt_handoff may be the problem. I don't know what causes $vt_handoff to appear or even how to permanently remove it.

hth

See https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1500751 comment #68 for apparently working solution.

Workaround from https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1500751 comment #68 confirmed correct and working. Also, bug not present in Ubuntu Wiy for 4.2.x kernels due to i915 driver being in an appropriate directory. However, intel_pstate driver in Wily AFU'd, so you still have to apply the fix and run an old kernel if you actually want a working computer.

Also affected wily with stock kernel 4.2.0-26. If I change GRUB_CMDLINE_LINUX_DEFAULT to "quiet nosplash" I can type characters in and unlock.

@jaywink: I don't yet see a 4.2.0-26 release for Wily. If you gzip -d and cpio t your initrd, does it contain an i915 module?

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 configuration:
Ubuntu 15.10

Driver selection
----------------
You can either go with the open nouveau driver which is installed by
default, or use the proprietary 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!

Switch to console
----------------
With the nouveau driver, it is easily possible to switch to the console
(CT...

@Shevek,

> I don't yet see a 4.2.0-26 release for Wily. If you gzip -d and cpio t your initrd, does it contain an i915 module?

Now on 4.2.0-27-generic at least.

What exactly should I do, I'm not sure what you mean with the gzip and cpio, can you clarify with a more exact command? :)

I'm getting this with 15.10 and 16.04 (post update). I've had it happen on two separate machines with a fresh install of 15.10, one of which had an NVidia 870, but the other did not (older Dell XPS 15). After reading a few related bugs, I'm abale to work around this without going into recovery mode by removing "quiet splash" from the boot but I'd prefer to have the splash screen shown.

The NVidia machine does not specify uvesafb as was mentioned above. It does use vesafb. It also had vga16fb which I removed to no avail, other than having a much more readable text boot.

Sorry, I should also mention that all of these installs were Kubuntu, AMD64

I have the same issue on a desktop
Intel i5 4th gen
NVidia GTX970

I have a fresh Install Ubuntu with encryption. By default it uses Nouveau Driver

From the driver UI, I switch to nvidia, then I reboot and the problem appear.

Scenarios

1. default kernel loading
It prompt with a low res screen and the disk decryption password doesn't work.
When I type nothing is shown. If I switch terminal with CTRL+ALT+F6 then CTRL+ALT+F7, I can see the password in clear Text and it doesn’t reload the UI

2. Most Recent kernel with (Upstart)
same as default

3. Most Recent kernel Recovery
Enter password in text mode
When Prompt, select "Resume normal boot"
Works fine

4. Previous Kernel (default)
Ask GUI disk password and work fine

5. Previous Kernel Upstart
Ask disk password and hangs there

6. Pervious Kernel Recovery
same as 3 but stock in 1024x768 res

I made the following changes :
GRUB_GFXMODE=2560x1440
GRUB_GFXPAYLOAD_LINUX=keep
GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash noplymouth”

Something additional I should probably add...

On ubuntu-16.04 desktop installation cd (uefi mode), after installation, when asked to press enter to reboot, nothing happens except to echo the action on the terminal as indicated above. The only way to reboot the system is to do a force reboot.

I just upgraded from 14.04 to 16.04, and now I'm experiencing exactly the same symptoms. Full disk encryption (including root parition) was working just fine under 14.04 before the upgrade. Post upgrade, under 16.04, I'm unable to enter my root partition password. I type, and nothing shows up in the text entry box. I hit enter, and it just sits there as if the keyboard weren't attached. I can only boot by disabling the splash screen by adding "nosplash" to the kernel command line, then entering my password on the text boot screen.

Ubuntu 16.04 newest nVidia drivers version 367.35. Same problem as everyone in here. Unable to enter password after installing the nVidia driver. Screen stays frozen with no input.

Well, what's worked for me as a workaround is to change: GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash” in the /etc/default/grub to GRUB_CMDLINE_LINUX_DEFAULT=”” and then run sudo grub-update. It gives me the old style scrolling text login where I have an option to enter my filesystem decryption password. – ksclarke

I did that and it works but it is now the old plain login text you get from a distro without an user interface. Really ugly and not user friendly.

Same issue when upgrading from Ubuntu 14.04 to 16.04. Note - using LUKS encryption and have nVidia video.

Did a fresh install of Ubuntu 16.04 using LUKS encryption which installed 4.4.0-21 and login worked until I ran upgrades (which installed 4.4.0-34). Now have the cannot type characters into the box to unlock the disk problem again.

Notes:

* If I boot in recovery mode I can enter password, just not with a normal boot.
* If a change my /etc/grub/default to be "quite nosplash", I can enter password in text mode.

System info:
* System76 Leopard Extreme
* 1 GB nVidia GeForce GTX 750

Same as David (#76),
I'm running Arch Linux, with the latest kernel (4.7.0-rc6-mainline)

Apparently Plymouth and crypt can't cooperate: I have to switch to text login (nosplash option) to decrypt my LUKS Harddisk - obviously setting nosplash stops Plymouth from running and therefore I haven't any boot screen.

When using the graphical login Plymouth displays the "Password request" interface, but when something is entered the text is shown in cleartext on the top left corner. Pressing ENTER after inserting a correct password won't work.
Changing theme doesn't affect the behavior, it only affects (obviously) the graphics.

There isn't any dot in the password box while typing, entering a bad password behaves as same as entering a valid password: the text is displayed in cleartext and it's like writing in a shell, with no output

I have a macbook pro retina 11,3 with GeForce GT 750M Mac Edition. With ubuntu 14.04 everything worked fine with nvidia drivers and disk encryption. After upgrading to 16.04, I was unable enter the encryption key on the splash page, and the keyboard was unresponsive. Rebooting and using recover image worked, as does GRUB_CMDLINE_LINUX_DEFAULT=”quiet nosplash”. Also, using the Nouveau drivers works, but Nouveau can't control screen brightness, so I need the nvidia drivers. For now I will live without the splash page, but it seems like this has been narrowed down sufficiently that a bug fix should be forthcoming.

Same problem here on Linux Mint after upgrading from 17.3 to 18.

Heeeeeeey it's been two years and this show stopper bug still hasn't been fixed.

Remember folks, for every 1 person who reports the problem there are 100 who don't, which means this bug affects at least 5,000 people affected by this bug.

Come on guys, get it together. This needs fixing.

This really needs to be fixed. I mean really. Come on.

I suddenly suffered from this bug after installing Intel Graphic Drivers installer.
When I try to type LUKS password the characters just gets printed on the screen overwritting th purple background, intead in the edit box.
The only thing that worked for me is to remove quiet splash.
This is an embarrassing bug.

Sorry, my system is:
Ubuntu 16.04 with Linux 4.4.0-47-generic
Asus Taichi 21, and bug begun after installing intel-graphics-update-tool_2.0.2_amd64.deb
from: intel-graphics-update-tool_2.0.2_amd64.deb

I am running Ubuntu 16.04 LTS on a Dell I5555 with a radeon card. This started happening after a few successful boots in graphics mode. I suspect, although I am not sure, that it started after I needed to install an extra library for a package that I had installed. But BEFORE that, in order for the system to boot at all, I had to enter the "nomodeset" option in /etc/default/grub . Without that it did not let me get past the point where it complained about the lack of UMS support on my radeon graphics module. Removing the "splash" option helped me to then enter the encryption password and boot in text mode. The extra installations that I needed to do, which may have broken the boot [i.e., my ability to enter the encryption key password in graphics mode] are: the libicu52 library, which, in turn, required xcb - and that then wanted xcb-proto . It may be worth checking what these graphics libraries do to influence a boot in graphics mode.

I'm running Xerus. Routine upgrades upgraded the kernel from 4.4.0-45 to 4.4.0-47. The next time I booted (because plasmashell refused to start, a probably unrelated bug), the "kubuntu" splash screen was about twice as wide as normal. It showed the disk password prompt, but I couldn't get it to work. After I fiddled around with recovery, and still couldn't enter the disk password, I got the Xubuntu splash screen, I have no idea why. It appeared to be asking for the root password and the disk password at the same time. I ran memtest to see if there's a memory problem (there wasn't). Then I thought, maybe something's wrong with the kernel. I booted the previous kernel and successfully entered the disk password. sddm didn't show anything, but I got around that by stopping sddm and running lightdm instead.

I had the same problem here as I just upgraded desktops. My old system was working fine, installed kde neon with an ubuntu base, and got the same where I can't access the password entry focus in ubuntu. As mentioned, this seems to occur *every* time I upgrade, whether ubuntu to ubuntu, or anything dependent on it like neon I'm attempting to fix a buggy kde environment with.

I really wish canonical people would actually consider luks as something more than some tinfoil hat extremity no one really uses. Encfs was always a basketcase for me attempting to use, luks was a sane option and preferred for the full disk and fs. It *is* embarrassing, even as a user every time I run into this, which is at least 4-5 times over the past 10 years.

I am affected by the very same bug in 16.10. I have hybrid virtual/dulaboot system - a physical encrypted partition + dedicated ESP that is bootable on bare metal from UEFI and able to load either Ubuntu or Windows; or bootable via VirtualBox using dedicated ESP and UEFI boot.

- In case of bare metal everything boots properly and password can be entered

- In case of booting in virtualbox boot stucks in LUKS password phase. Any attempt to type is immediately echoed in text-mode over Plymouth graphical screen (top left corner) and submit with enter doesn't work. If I edit kernel GRUB's Ubuntu entry and remove these specific lines:

load_video
gfxmode ...

and remove following from kernel commandline: splash $vt.handoff

it boots in text mode, I am able to enter keyphrase and it boots just fine.

To add one more data point, I hit the same problem when upgrading from Kubuntu 14.04 to 16.04.

Ondrej's workaround is also effective for my setup. In the end, the upgraded system was unusable for other problems as well so I did a fresh install. However, I kept the lvm volume group on luks device as my /home is there as well and I wanted to keep that.

After installation from the Kubunut desktop disc (via usb flash drive) and setting up crypttab manually I still had the same problem: Entering the password via the graphical boot ignores the input. Hitting Alt-Cursor right and Alt-Cursor left I get a text screen with the password I entered.

It's working in text mode thought.

I had 16.04 for 2 weeks on my newly built pc. The OS was running great until today when I restarted my pc and wasn't able to type in my password as I usually would. Instead popped up in the top left of the screen. Confused I start fiddling with everything I could and for the next 3-4hrs nothing. At that rate I got desperate. Began asking around due to not finding this similar problem anywhere and people began to say I had ransomware. I questioned this greatly but panicked at the same time. Then learned I could gain access through recovery mode. Though why should I go through all this trouble to gain access to my pc? I then resorted to wiping the ssd and restoring my files on a newly installed 16.04 ubuntu OS.This time without the encryption on boot up. Seems to do some sort of low quality box shaped circles now on boot up but have usual access to the pc now. In all honesty I want the extra encryption but hate that this glitch is such a thing. Was then told that this has been a ongoing issue for YEARS now. To think that such an issue like this is still not fixed is insane. Hope though maybe soon this will finally get fixed.

i dont was reading all the comentaries (becouse tomor i work, but i was reading half).

I get the same problem, ubuntu 14.04 and 16.10.

What I was thinking, after all this big bug i want to start my linux in recovery mode, and then i was searching google how to start in command line and i get this: http://ubuntuhandbook.org/index.php/2014/01/boot-into-text-console-ubuntu-linux-14-04/

so I tryed on my Ubuntu 16.10,and work, now i start in command line, something what give me the chance to type my mda5-crypt password :D

for make this change you can acces the website from up or to do this.

To get started, press Ctrl+Alt+T to open terminal. When it opens, follow the below steps:
sudo gedit /etc/default/grub

Search this
GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash”
change to
#GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash”

GRUB_CMDLINE_LINUX=”"
change to
GRUB_CMDLINE_LINUX=”text”

#GRUB_TERMINAL=console
change to
GRUB_TERMINAL=console

save the file and type [b] sudo update-grub [/b]

For me is ok.

Ubuntu 16-04.2 LTS, FDE install then switched to Nvidia driver in additional drivers, reboot unable to enter password to unlock disk

#87 worked for me by editing boot options
>I already have 'nosplash noplymouth', removing the follwing
load_video
gfxmode
splash $vt.handoff

But I had no success by editing grub mentioned in #90, seems like a bug https://bugs.mageia.org/show_bug.cgi?id=15673
getting ubuntu 16.04 - error: invalid video mode specification 'text' . Booting in blind mode

So how can I update grub to remove 'load_video' and 'gfxmode'?

[This](https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1386005/comments/87) or recovery mode made it possible to boot. However, networking (both wired and wireless) is now unavailable.

Easier workaround (which also avoids the network problems at least I had): Choose an earlier kernel from the boot menu.

I have been hit by this bug after transforming Ubuntu 16.10 into Kubuntu 16.10 trough tasksel utility. I removed ubuntu-desktop and ubuntu-usb. Then installed kubuntu-desktop.

Fuck you. More than 2 years after and still you haven't fixed it. I have spent already a day with this shit.

Its not the first time LUKS is problematic at boot. Long time ago I reported a bug which needed to incorporate decryption modules in the initramfs. It was AESNI module.

Now this, with a lot of reports and still is not fixed.

Well, this bug is irritating, but swearing at the team won't help.

Nearly years since this was first reported. Hmmm.

This answer seems to provide a workaround:
https://askubuntu.com/questions/854388/ubuntu-16-04-cannot-enter-password-at-disk-decryption-splash-screen

Same problem for me when doing a fresh install of 16.04 LTS and 17.04.

This bug also affects HP Zbook 15 G3 with nVidia drivers Ubuntu 16.04.2 + nVidia-375
The splash screen with the passphrase prompt is displayed but the keyboard doesn't work.

Removing 'splash' from the grub command line to boot into text mode works around the issue but for our users the UX with the text mode boot is not acceptable.

I wanted to report that this is also happening to me.

Computer model: Dell Precision 7520
GPU: Nvidia Quadro M2200
OS: Ubuntu GNOME 17.04 amd64

I'm happy to provide any additional specs that would be useful.

... with the Nvidia proprietary drivers, that is. Everything works fine with nouveau.

I see this has been open for a few years now. Is there anything we can do to help speed it along? I'm open to sponsoring it, testing new code, whatever.

This happened to me again today, after I did an apt update. The problem is, the kernel modules (or something) changed, but not the kernel version, so I don't have a backup kernel configuration that I can boot from. This makes it literally impossible for me to boot my machine.

This is still present in zesty :( what makes it worse is that nouveau crashes my computer from time to time.

Also text boot is not as good. I have 2 partitions with the same password and graphical boot asks for password only once. With text boot i have to enter the password twice.

is there at least a way to make it ask the password once in text/nosplash mode?

Have same Problem. With the Nvidia proprietary drivers, can't type password. Everything works fine with nouveau.
Is a workaround available with Nvidia proprietary driver?

I have the same problem on the proprietary nvidia driver.

Problem confirmed on NVIDIA GTX 1080 running proprietary drivers 387.12.

This does not happen with Nouveau.

Ubuntu 16.04 LTS with kernel 4.10.0-35-generic. Plymouth version is being reported as 0.9.2-3ubuntu13.

Same bug on ubuntu 16.04 LTS with kernel 4.10 with Optimus (intel/nvidia) if you select in bios use only nvidia and no bug if you select intel or hybrid. So it's definitely nvidia proprietary driver bug.

Same problem with Linux Mint 18.3

Installed Linux Mint with Noveau drivers (default). I got some problems and switched to nvidia proprietary drivers and then I cannot enter luks decryption at first attempt.

After rebooting I get text screen for password, which works well.

Driver version: 384

Um, it looks like you guys got hacked...

Is anyone still having this issue?

I'm unsure if this is exactly the same issue, but, yes I still have the issue that my password is not accepted if I just enter it on the password prompt and press Enter. What I figured out so far is that the problem seems to arise from the fact that my password starts with a capital letter. During Ubuntu installation the installer happily did accept the password, though and didn't complain that a password must not start with a capital letter or anything.

Now, when the system boots, I see the graphical plymouth password prompt. As soon as I press the shift key to enter the first capital letter of my password, plymouth disappears :-( And, weirdly, even though I pressed only the shift key, 4 letters already appear behind the text password prompt that I didn't type!? Because they are asterisks I don't know what letters they are. If I backspace them and enter my password, the system boots. If I just enter my password without backspacing, then the password is not accepted. Probably because it's prefixed by those 4 mystery letters that have been typed automatically.

Another workaround is to first type a lower case letter while the graphical screen is still on. Then backspace that and enter the real password. This will keep the graphical bootscreen.

Only problem: This is quite difficult to explain to some family members who get very easily confused by this... :-/