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

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... :-/