KDE Neon 20.04, Plasma 5.20.5, Kernel 5.4.0.59 - NVIDIA Driver update to 455.45.01 bricked my OS

I am running KDE Neon 20.04 with plasma 5.20.5. Yesterday driver 455.45.01 became available in my distro. I was running 455.38 previously without any issues. The upgrade to 455.45.01 bricked my OS. I couldn’t even boot into it in recovery mode. I’d select the os in Grub, it would then show my computer’s manufacturer logo, and then it would just show a black screen. I couldn’t get into another tty with Ctrl+Alt+F(1-6). There was no way to get to a terminal of any kind. So I reinstalled my OS, let it do its updates, and then had it install the nvidia driver. Same thing. So I tried doing it all over again on Kernel 5.9 instead of the default 5.4.0.59 since 455.45.01 says it has 5.9 support. Same thing happened there. Then I tried installing 455.38 that was working previously - but had no luck getting it to work outside of my distro package manager (I installed it from the download on nvidia.com). The only way for me to get nvidia drivers working now is to use 450 from my package manager. That is outdated, and the OS doesn’t display correctly - lots of scaling issues.

Does anyone have any suggestions on what is going wrong with the 455.45.01 update? Any help would be greatly appreciated.

Sounds like there’s some general problem with your setup.
Please run nvidia-bug-report.sh as root and attach the resulting nvidia-bug-report.log.gz file to your post.

Attached is the bug report. Thanks!

nvidia-bug-report.log.gz (265.5 KB)

Unfortunately, it seems you have reinstalled so there’s no trace of the 455/460 drivers issues. Can you ssh into the box when using the broken drivers?

nvidia-bug-report.log.gz (88.8 KB)

I am unable to ssh into, or open a tty, or boot into recovery mode. Haven’t been able to get to any kind of terminal.

I did just install the 460 driver, and generated the newly attached bug report before rebooting. I’m not sure if that will be helpful at all since I wasn’t able to actually run the bug report while booted up on the 460 driver, but the bug report does mention the 460 driver so hopefully there’s something in here that indicates what went wrong.

Note that I have tried the 455.45 driver and the 460 driver in the default 5.4.0.60 kernel, 5.9.16, and 5.10.5 (or whatever the most recent 5.10 release was)

All 6 combinations result in the same issue.

Thanks again for your help.

With that method, the nvidia driver is installed but never loaded, so nothing to see in the logs but it installs fine. Since you can’t even ssh in, sounds like a hard kernel freeze.
Please try this: install the latest 460 driver but before rebooting, disable the Xserver by running
sudo systemctl disable display-manager
You should then be able to log in on text console after reboot. Then create a new bug-report.log. (If frozen, then there’s already something wrong at kernel driver level)
Afterwards, try to start the Xserver
sudo systemctl start gdm
If it then freezes, reboot and after reboot you should be able to log in on text console (if it didn’t freeze at the first step already) and create a second nvidia-bug-report.log.

After installing 460 and disabling the Xserver, I rebooted and the same thing happened - just froze on a black screen. No text console, couldn’t use ctrl+alt+F(1-6), no recovery booting, etc.

Doesn’t sound good. Can you boot when you append

modprobe.blacklist=nvidia

to the kernel command line in grub menu?

No, it still just goes to a black screen. Not sure if that means the blacklist fails, or that the driver installation has caused a problem in the kernel

Do you have any older kernel for which the nvidia driver is not installed available in the grub menu?

That’s another strange thing about this… Each time I’ve installed the 455.45 or 460 driver, all kernel entries stop booting. I’ve had 5.4.0.58, 5.4.0.59 and 5.4.0.60, install the driver against .60 and then all 3 will freeze on the black screen while booting

Under normal circumstances, the kernel headers necessary for compiling the driver are only installed for the latest kernel. So this is really odd. Are you booting using efi or csm boot?

It is efi