nvidia-367 with kernel 4.4.0-45-generic won't boot

Bug #1638990 reported by PlantDaddy
92
This bug affects 17 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Incomplete
Low
Unassigned
nvidia-graphics-drivers-367 (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

After I upgraded the nvidia drivers, I could no longer boot via kernel 4.4.0-45-generic.

WORKAROUND: Use nouveau.

WORKAROUND: Boot with already installed kernel 4.4.0-31-generic.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux-image-4.4.0-45-generic 4.4.0-45.66
ProcVersionSignature: Ubuntu 4.4.0-45.66-generic 4.4.21
Uname: Linux 4.4.0-45-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC2: lost 2248 F.... pulseaudio
 /dev/snd/controlC0: lost 2248 F.... pulseaudio
 /dev/snd/controlC1: lost 2248 F.... pulseaudio
CurrentDesktop: XFCE
Date: Thu Nov 3 12:12:55 2016
HibernationDevice: RESUME=UUID=cf59c168-54d0-45b9-b633-240bd76bbaa6
InstallationDate: Installed on 2016-11-01 (1 days ago)
InstallationMedia: Xubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
MachineType: LENOVO 11361Q0
ProcEnviron:
 LANGUAGE=en_US
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB:

ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-45-generic root=/dev/mapper/xubuntu--vg-root ro nomodeset quiet splash
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-45-generic N/A
 linux-backports-modules-4.4.0-45-generic N/A
 linux-firmware 1.157.4
RfKill:

SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/29/2016
dmi.bios.vendor: LENOVO
dmi.bios.version: A3KT57AUS
dmi.board.name: LENOVO
dmi.board.vendor: LENOVO
dmi.board.version: NO DPK
dmi.chassis.asset.tag: 573921
dmi.chassis.type: 7
dmi.chassis.vendor: LENOVO
dmi.chassis.version: NONE
dmi.modalias: dmi:bvnLENOVO:bvrA3KT57AUS:bd09/29/2016:svnLENOVO:pn11361Q0:pvrThinkStationC30:rvnLENOVO:rnLENOVO:rvrNODPK:cvnLENOVO:ct7:cvrNONE:
dmi.product.name: 11361Q0
dmi.product.version: ThinkStation C30
dmi.sys.vendor: LENOVO

Revision history for this message
PlantDaddy (plantdaddy) wrote :
PlantDaddy (plantdaddy)
description: updated
tags: added: 4.4.0-31 4.4.0-31-generic kernel nvidia nvidia-361 nvidia361
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
PlantDaddy (plantdaddy) wrote :

So I was able to get back into a functioning state.

I booted back into the 4.4.0-31-generic kernel, re-installed the nouveau driver via Additional Drivers
Rebooted and chose the 4.4.0-45-generic kernel
Re-install the nvidia 367.57 drivers via Additional Drivers

However, something here seems to clunky if one has to do that to get the drivers to work. Whether that's nvidia related or otherwise.

Revision history for this message
Andrej Kosar (12ado12) wrote :

I am affected by this bug too.

This morning after automatic updates from software updater my nvidia driver was updated to nvidia-367 and after reboot I got login loop where after inserting password I am returned back to login page.

Not working on 14.04 with kernel 4.4.0-45-generic with drivers 367.57.

Drivers are not even working with older kernel version (tried 4.4.0-42 and 4.4.0-38). Method described by Brendad is not working for me neither.

Currently only open source Nouveau driver is working.

Revision history for this message
Alberto Salvia Novella (es20490446e) wrote :

That's why AMD cards are better for gaming in Linux 😛

Changed in linux (Ubuntu):
importance: Undecided → Critical
Revision history for this message
Francois (francoissiocnarf) wrote :

FYI, nvidia-367 works with kernel 4.4.0-43-generic. Might be an acceptable workaround for some people until this bug is fixed.

Rebuilding nvidia-367 using dpkg-reconfigure under kernel 4.4.0-45 didn't work for me. Neither did reinstalling it (probably not much of a different effect).

Also wanted to mention that the initial symptom of this problem in the presence of full-disk encryption is that the boot fails very early, before it even asks for your FDE passphrase. It surprised me to find that the nvidia driver or some part of it is loaded that early. I thought by HDD had failed.

Revision history for this message
Johan Ferner (johan-ferner) wrote :

Another workaround that worked for me is to edit /etc/default/grub like so:
GRUB_CMDLINE_LINUX_DEFAULT="nomodeset"

followed by update-grub2

I am running with full disk encryption.

tags: added: needs-bisect
Revision history for this message
Francois (francoissiocnarf) wrote :

RE comment #8: I tried nomodeset with kernel 4.4.0-47 and it didn't work. It still locked up before the prompt for the full-disk encryption passphrase.

Revision history for this message
append[x] GmbH (x-launchpad-h) wrote :

Can confirm the problem: started to occur after the update to kernel 4.4.0-45 and nvidia 367.57 and it is the combination of kernel version and nvidia-driver that causes the problem. There are no problems when the nvidia-driver is purged and nouveau is used instead. I am using full disk description.

Last working kernel with nvidia 367.57 is 4.4.0-43.

Kernel 4.4.0-47 does not fix the problem.

Symptoms are either a black screen with blinking underline-prompt in the topleft corner (no fde password prompt, no possibility to switch to console) or a low-res graphical screen for fde password entry, but no way to actually type the password.

Setting GRUB_CMDLINE_LINUX_DEFAULT="nomodeset" works for me (it is important to remove "quiet splash" if "nomodeset" is inserted into an existing line) – with this setting, the fde password can be entered in the console and the system boots normally with nvidia 367.57 and kernels 4.4.0-45 and 4.4.-0-47.

Revision history for this message
Francois (francoissiocnarf) wrote :

RE comment #10 and my own comment #9:

I tried again and can confirm that nomodeset works with kernel 4.4.0-47 and nvidia-367.57.

System boots into xorg with the nvidia drivers in use and working completely.

My mistake was that I had left the following line in /etc/default/grub:

GRUB_CMDLINE_LINUX=""

So this is what it needs to look like:

#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
#GRUB_CMDLINE_LINUX=""
GRUB_CMDLINE_LINUX_DEFAULT="nomodeset"

Revision history for this message
Catalin Moldovan (moldovan-catalin) wrote :

I'm having the same problem (Asus G55VW, GTX 660m, Ubuntu 16.04 and nvidia-370.28 drivers). When booting with kernel 4.4.0-31 everything works ok but when booting kernel 4.4.0-45 or 4.4.0-47 it hangs with a prompter in the top left corner and only power button works and triggers shutdown. I've tried "nomodeset" fix in grub, I've tried blacklisting nouveau driver, reinstalling xorg, ubuntu-desktop, pretty much everything I could find on the web and nothing helps.

Revision history for this message
Catalin Moldovan (moldovan-catalin) wrote :

I've forgot to mention that I'm not using disk encryption.

Revision history for this message
Tambellini (william-tambellini) wrote :

confirming same issue on Alienware 17 R4 (GTX1060) with ubuntu 14.04, nvidia 367 & kernel 4.4.0-47.
The gui of "additional drivers" is desperatly kindly stating: "nvidia 367.57 (tested)".

Revision history for this message
Andrej Kosar (12ado12) wrote :

After yesterdays kernel update I tried my luck if something has changed.
And it's working now. Kernel 4.4.0-53-generic and nvidia-367 drivers. Both nvidia performance mode and intel power saving mode are working.

I tried also for the previous kernel version 4.4.0-51-generic and only nvidia performance mode was working.

I hope next updates won't screw this up again.
I am on ubuntu 14.04 and I have nvidia GT 630M and intel HD graphics 4000.

Revision history for this message
Marcello R Duarte (marcelloduarte) wrote :

This issue hit me last night after an update. Ubuntu 16, GTX 980 Kernel 4.4.0-53-generic and nvidia-367 drivers.

Nvidia official drivers are on 375.2. Has anyone tried Kernel 4.4.0-53-generic along with latest nvidia drivers to see if it fixes the issue?

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in nvidia-graphics-drivers-367 (Ubuntu):
status: New → Confirmed
Revision history for this message
penalvch (penalvch) wrote :

Brendan, to clarify, the Bug Description, what version of the nvidia drivers did you update from?

tags: added: bios-outdated-a3kt58aus
removed: 4.4.0-31 4.4.0-31-generic kernel nvidia nvidia-361 nvidia361
description: updated
tags: added: regression-update
Changed in linux (Ubuntu):
importance: Critical → High
status: Confirmed → Incomplete
penalvch (penalvch)
description: updated
Revision history for this message
Alberto Salvia Novella (es20490446e) wrote :

Since this bug renders the system broken, it should have an importance of "critical".

Changed in nvidia-graphics-drivers-367 (Ubuntu):
importance: Undecided → Critical
Changed in linux (Ubuntu):
importance: High → Critical
Revision history for this message
penalvch (penalvch) wrote :

Alberto Salvia Novella, thanks for attending to this. Given this bug has an easy to implement WORKAROUND, Low would be a more appropriate fit here as per https://wiki.ubuntu.com/Bugs/Importance .

Changed in linux (Ubuntu):
importance: Critical → Low
Changed in nvidia-graphics-drivers-367 (Ubuntu):
importance: Critical → Low
description: updated
Revision history for this message
Francois (francoissiocnarf) wrote :

Christopher M. Penalver, I am not so sure the workaround is easy to implement. A regular user is unlikely to find this bug report and would probably not know how to parse any of the comments here even if they did. And this bug was triggered by a system update. Just imagine somebody who can barely edit a text file rebooting into a blank screen.

Revision history for this message
Marcello R Duarte (marcelloduarte) wrote :

This bug renders the system broken for anyone using nvidia drivers + fully updated ubuntu 16.

I agree the work arounds aren't all that easy to implement. Nouveau is not really an option for most people because of poor support and low resolutions.

To get the older kernel to work you have to rebuilt the Nvidia drivers. I had to do this from console because unity refused to log me in.

According to the wiki any bug that affects the system from booting should be classified as critical as well as any bugs affecting large portion of users. https://wiki.ubuntu.com/Bugs/Importance.

I think a lot of users are running into this and just have no clue what's going on. At first I thought it was a HD issue.

Revision history for this message
penalvch (penalvch) wrote :

Francois / Marcello R Duarte, in order to get this issue debugged and upstreamed, it will help immensely if you filed a new report with the Ubuntu repository kernel (not mainline/upstream) via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.

Revision history for this message
Alberto Salvia Novella (es20490446e) wrote :

@ Christopher M. Penalver

I would recommend that the only criteria to take into account when setting bug importances is their impact alone.

If the OS renders their system broken, most people told me that they will simply quit it. Most of them that I have installed Ubuntu don't understand workarounds written in English.

The official documentation is broken and outdated, because one or two people are preventing it from changing.

Revision history for this message
Travisgevans (travisgevans) wrote :

I got hit by this too a while back. I don't expect a simple system upgrade to break my system. I ended up having to continue using an out-of-date kernel for some time as a result.

It's still not fixed with nvidia-367 and 4.4.0-59-generic. But manually editing /etc/default/grub and removing "splash" from the GRUB_CMDLINE_LINUX_DEFAULT options, followed by executing update-grub2, does allow my system to boot with 4.4.0-59 (I didn't have to use "nomodeset"). I consider myself lucky.

If this really affects *everyone* who simply uses the official Nvidia drivers, then I'm tempted to feel that these updates are not being tested adequately before release. I really hope that this testing will improve once this gets fixed, because things like this encourage users to leave their systems out of date and possibly risk security issues just to ensure that they at least *work*. It certainly doesn't encourage *me* to update my system very often (and I'm bad enough about that as it is).

Revision history for this message
demaniak (hendrikc) wrote :

Kernel 4.4.0-66
Nvidia 375
Xubuntu 16.04.2
GTX965M

Long ago removed splash screens etc during boot, so after the upgrade of kernel and graphics driver, I could see that the "Nvidia peristence deamon" was failing to start. It gets retried a couple of times, but after it fails for the final time, the boot process is dead. And the system is then hung.

Manually adding nomodeset to the grub boot options (from boot loader menu) at least gets me back into a desktop, BUT the nvidia driver is not working properly at that point (nvidia settings for example does not register the graphics card at all).

Before this upgrade today, everything was fine. I am now forced back to the open source drivers.

Revision history for this message
Namey Herey (spright) wrote :

Linux 4.10.0-21-generic #23-Ubuntu SMP Fri Apr 28 16:14:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 17.04
NVIDIA binary driver 375.66 from nvidia-375
Nvidia GTX 770
Using disk encryption

I cannot believe this is still an issue after a year! During this time I have had to manually fix and purge the Nvidia drivers multiple times (at various different installs onto my PC where I was hoping this issue had been resolved). There is no way any normal person would have been able to recover their device.

It was difficult enough to even find this bug report.

Someone reported "Also wanted to mention that the initial symptom of this problem in the presence of full-disk encryption is that the boot fails very early, before it even asks for your FDE passphrase.". However that is not the case for me, in this case I enter the passphrase but the next stage is a black screen with a single "_" character in the top-left corner, with nothing happening.

Revision history for this message
penalvch (penalvch) wrote :

Namey Herey, it will help immensely if you use the computer the problem is reproducible with, work around the issue as you noted, and file a new report with Ubuntu via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

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

Other bug subscribers

Remote bug watches

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