[SOLVED] Can't startx after installing non-free nvidia drivers.

AndrewMartin · 02-28-2021, 05:57 AM

I just tried this:

Exit X.
Make the nvidia installer executable.
Disabled nouveau with a modprobe blacklist.
Set the multi-user as the default target (to avoid starting X automatically) (sudo systemctl set-default multi-user.target)
Rebooted
Ran the installer as root. (Installing NVIDIA driver version 460.56.)
Said yes to the questions...
-> Would you like to register the kernel module sources with DKMS? This will allow DKMS to automatically build a new module, if you install a different kernel later. (Answer: Yes)
-> Install NVIDIA's 32-bit compatibility libraries? (Answer: Yes)

At this point I encountered the error "ERROR: Unable to load the 'nvidia-drm' kernel module."

Code:

-> Driver file installation is complete.
-> Installing DKMS kernel module:
-> done.
ERROR: Unable to load the 'nvidia-drm' kernel module.
ERROR: Installation has failed.  Please see the file '/var/log/nvidia-installer.log' for details.  You may find suggestions on fixing installation problems in the README available on the Linux driver download page at www.nvidia.com.

The log (attached as nvidia-installer.log) also includes some warnings, but they sound harmless. It appears to be refusing to install libglvnd because it's already installed, there's also the line "Found non-libglvnd libraries:", but I suspect that's also harmless.

I also attach my Xorg.0.log, which shows a similar error, it fails to load DRM and then falls back to a different module "fbdevhw", and then fails to open that in framebuffer mode.

Code:

[    17.752] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
[    17.874] (EE) [drm] Failed to open DRM device for pci:0000:01:00.0: -19
[    17.874] (EE) open /dev/dri/card0: No such file or directory
[    17.874] (WW) Falling back to old probe method for modesetting
[    17.874] (EE) open /dev/dri/card0: No such file or directory
[    17.874] (II) Loading sub module "fbdevhw"

I'm quite keen to solve this now, as purging *nvidia* and 'unblacklisting' nouveau isn't enough to get X, xinit, or startx to work again.

Do I need to change "secure boot" or "UEFI" in my BIOS?

Brains · 02-28-2021, 06:03 AM

Quote:

[ 0.000000] secureboot: Secure boot enabled
[ 0.000000] Kernel is locked down from EFI secure boot; see https://wiki.debian.org/SecureBoot

This is likely the problem. When secure boot is enabled, you need to sign the nvidia module. If you disable secure boot, your Debian binary nvidia-driver will work.
However, you can create your own signing key for modules and add its certificate to the trusted list using MOK.

Brains · 02-28-2021, 06:11 AM

Not sure about your setup, but my Debian created two entries in the EFI boot menu, one to be used without secure boot enabled, the other with secure boot.

AndrewMartin · 02-28-2021, 06:19 AM

Quote:

Originally Posted by Brains

This is likely the problem. When secure boot is enabled, you need to sign the nvidia module. If you disable secure boot, your Debian binary nvidia-driver will work.
However, you can create your own signing key for modules and add its certificate to the trusted list using MOK.

Yep, I'm in and I've got a glmark2 score of around 7000. Nothing much for gamers these days, but a definite step up from the 200 I was getting.

So, to confirm, I rebooted, disabled secure boot in the BIOS, logged in and re-ran the NVIDIA installer (from the nvidia website).

That completed perfectly, I rebooted and startx loaded my desktop environment correctly.

I assume it was the same thing that was stopping the Debian repo 'nvidia-drivers' from loading correctly.

Thanks for your help everyone.

If there's something I can add to help any people from the future with the same problem, then let me know and I'll do it.

Cheers,

Andrew

computersavvy · 02-28-2021, 02:09 PM

One thing that has not been mentioned.
Are you using gnome?
If so, are you using wayland or xorg?

Nvidia cannot be used with wayland and the frame buffer errors seem to imply that may be the issue.

You might look at /etc/gdm/custom.conf and uncomment the line #WaylandEnable=false if that is the case.

I see you got it fixed, but this is still pertinent for many.