Password not accepted graphical boot for encrypted root system

Bug #1386005 reported by Ron Rusnak on 2014-10-26
454
This bug affects 92 people
Affects Status Importance Assigned to Milestone
Linux Mint
Undecided
Unassigned
NVIDIA Drivers Ubuntu
Undecided
Unassigned
plymouth (Arch Linux)
New
Undecided
Unassigned
plymouth (Ubuntu)
Critical
Unassigned
Nominated for Utopic by Alberto Salvia Novella
Nominated for Vivid by Alberto Salvia Novella

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.

Launchpad Janitor (janitor) wrote :

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

Changed in plymouth (Ubuntu):
status: New → Confirmed
1 comments hidden view all 106 comments
Steve Langasek (vorlon) wrote :

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.

Changed in plymouth (Ubuntu):
status: Confirmed → Incomplete
tags: added: apport-collected utopic
15 comments hidden view all 106 comments

apport information

description: updated

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Steve Langasek (vorlon) wrote :

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.

Changed in plymouth (Ubuntu):
status: Incomplete → New
Josh (majik) wrote :

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.

Launchpad Janitor (janitor) wrote :

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

Changed in plymouth (Ubuntu):
status: New → Confirmed
Ron Rusnak (rjrusnak) wrote :

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?

Changed in plymouth (Ubuntu):
importance: Undecided → Critical
Bruce Pieterse (octoquad) wrote :

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

tags: added: vivid
Ubuntu QA Website (ubuntuqa) wrote :

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

tags: added: iso-testing

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

Changed in plymouth (Ubuntu):
status: Confirmed → Triaged
Jonathan Riddell (jr) on 2015-03-27
tags: added: kubuntu
Changed in plymouth (Ubuntu):
milestone: none → ubuntu-15.04
Changed in plymouth (Ubuntu):
milestone: ubuntu-15.04 → none
Jason Robinson (jaywink) on 2016-01-21
tags: added: wily
26 comments hidden view all 106 comments

@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?

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

Read more...

Jason Robinson (jaywink) wrote :

@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? :)

Nerdfest (nerdfest) wrote :

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.

Nerdfest (nerdfest) wrote :

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

FrancisL (francislav) wrote :

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”

Noorez (noorez-kassam) wrote :

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.

Carl Miller (chaz-q) wrote :

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.

Jonas (teazulo195) wrote :

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.

David Salmen (dsalmen-j) wrote :

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

Denys Vitali (denys-u) wrote :

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

Joe Arnold (jarnold-fuse) wrote :

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.

AsciiWolf (asciiwolf) wrote :

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

AsciiWolf (asciiwolf) on 2016-09-30
tags: added: xenial
Josh (majik) wrote :

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.

Kris (k-k-jacewicz) wrote :

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.

Kris (k-k-jacewicz) wrote :

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

emdee (4ltf) wrote :

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.

Pierre Abbat (phma-a) wrote :

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.

Mike Butash (michael-butash) wrote :

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.

Ondrej Balaz (blami) wrote :

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.

Torsten Landschoff (torsten) wrote :

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.

Scott Tawse (unluckyjoker) wrote :

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'?

Jonas Olson (jolson) wrote :

[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.

Jonas Olson (jolson) wrote :

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

Raúl Vidal (raulvior-bcn) wrote :

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.

RickB (rick-777) wrote :

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

Kyoku (kyoku) wrote :

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.

Liftoff (liftoff) wrote :

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.

Liftoff (liftoff) wrote :

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

Liftoff (liftoff) wrote :

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.

roman roh (svejkovo) on 2017-06-29
Changed in plymouth (Ubuntu):
status: Triaged → Incomplete
Steve Langasek (vorlon) on 2017-06-29
Changed in plymouth (Ubuntu):
status: Incomplete → Triaged
Chris Schadl (cschadl) wrote :

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.

dimovnike (dimovnike) wrote :

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?

sven (romanticdancer) wrote :

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?

FliXis (flixis24) wrote :

I have the same problem on the proprietary nvidia driver.

Kaz Wolfe (kazwolfe) wrote :

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.

Zed (darkbroodzed) wrote :

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.

Displaying first 40 and last 40 comments. View all 106 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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