Hi,
nvidia-smi returns this error:
NVIDIA-SMI has failed because it couldn’t communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.
I’ve installed the drivers 440, on Ubuntu 18.04.4, the PC is dual boot (Windows 10), with Secure Boot Enabled.
No matter what I tried, in Ubuntu Settings… about… graphics uses llvmpipe (LLVMnvidia-bug-report.loggz (123.3 KB) 9.0)
How can I take advantage of the graphic card? Thanks
How did you install the drivers? there are a lot of bad instructions out there on that.
Re: secure boot. Just in case you were thinking of doing it, you shouldn’t have to disable secure boot but you will have to install a key. Ubuntu will walk you through that process.
So, I just looked through my gpu server box’s command history (also 18.04.4) and this is what I did to install the drivers:
sudo apt install nvidia-dkms-435 nvidia-utils-435 nvidia-kernel-common-435
The drivers are now in the default repos so there is no need to add any sources. During the process you should be asked for a password which you should generate and write down. You will be asked for it again on boot. This is to install a key – necessary to avoid disabling secure boot. Once you’re rebooted, you nvidia-smi should work. If you’ve already made changes, you may have to undo them (eg. apt remove any installed packages, remove any sources you added)
So, I did an apt search and some apt show and it turns out you might just be able to do sudo apt install nvidia-driver-435.
It should generate and start the installation of a key for you, but you must enter the password on bios the first time to confirm it’s installation. This confirmation step is a security feature.
Hi mdegans, thanks for the answer.
I just tried to follow your reply (removed the installed drivers through sudo apt-get purge nvidia and sudo apt-get update), but unfortunately those don’t work either. I read during the installation of the 435 drivers that it failed to enroll the key. It asked me twice to choose a password, but after reboot it didn’t ask me anything.
nvidia-bug-report.loggz (133.3 KB)
Huh. If it asked you for the password, it should have prompted you for it on reboot on reboot. It’s possible it’s a bios issue in which case there probably isn’t much you can do (possibly updating your bios might help).
Somebody who knows more about me than secure boot might be able to point you to the location dkms saves the keys so you can attempt to load it manually into the bios (usually under the secure boot configuration screen).
If you look at that link, Method 1 is what should work.
What happens when you run mokutil --list-enrolled ? If the key is enrolled sucessfully (after bios prompt), you should see something like this:
[key 1]
SHA1 Fingerprint: aa:f7:ba:c2:6d:ea:00:9a:73:0f:39:a1:55:e2:ee:2a:d4:e9:44:81
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
c0:92:06:71:1f:9a:e1:72
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=ubuntu Secure Boot Module Signature key
Validity
Not Before: Feb 23 22:46:14 2019 GMT
Not After : Jan 30 22:46:14 2119 GMT
Subject: CN=ubuntu Secure Boot Module Signature key
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:ba:c3:ba:4c:0a:60:06:73:2a:9e:93:96:a4:63:
d7:1c:38:2b:d2:19:25:43:39:fc:f9:54:d1:d1:d9:
4d:f8:bd:64:55:f6:a0:9a:f9:30:d0:2e:53:db:69:
a4:60:8d:8a:69:53:89:1b:0d:9b:17:f4:ea:d0:bc:
6c:50:53:21:0d:e0:ca:c7:5f:99:73:89:ec:82:ff:
6f:e7:99:4a:ea:32:43:6c:62:85:b0:af:ac:4b:2a:
bc:83:18:a4:e5:f8:5c:1e:87:65:45:40:21:cf:99:
3e:6b:83:df:ae:ce:cf:da:2a:73:8a:87:fb:d0:77:
ad:16:70:cc:25:c4:ec:ab:e2:17:d9:b8:82:ed:8e:
61:e7:95:fc:57:91:c8:15:69:47:d1:6f:7c:c7:83:
3d:6a:b4:3d:00:1e:d2:6c:9b:fe:69:85:da:0f:6d:
e5:41:14:c2:73:a0:af:70:8e:58:00:be:2f:be:95:
75:9b:28:0a:95:d3:81:23:56:2f:d7:1d:8f:12:2f:
98:32:96:92:71:d8:d1:f5:72:60:e4:09:ba:a4:21:
8c:b9:5c:f4:f3:c6:88:c1:f0:70:aa:03:24:f6:72:
30:62:10:5e:1c:16:52:fd:3d:d3:1f:60:fd:a0:59:
6e:ce:94:a7:66:2f:d8:8e:24:75:e5:f9:bb:4d:1c:
ed:27
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
76:61:8B:DD:AE:68:B4:A7:EF:9A:D0:92:2A:75:19:27:CC:A2:F1:E3
X509v3 Authority Key Identifier:
keyid:76:61:8B:DD:AE:68:B4:A7:EF:9A:D0:92:2A:75:19:27:CC:A2:F1:E3
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
Code Signing, 1.3.6.1.4.1.2312.16.1.2
Netscape Comment:
OpenSSL Generated Certificate
Signature Algorithm: sha256WithRSAEncryption
b1:ba:02:9f:44:00:8b:16:aa:ce:0c:31:12:96:82:b0:86:00:
b4:38:a2:41:27:04:1b:c7:56:e9:a1:69:f8:55:cc:62:16:e4:
97:cd:90:78:7f:3a:5a:b9:1f:04:26:bf:3b:db:91:ef:b2:07:
72:33:c1:dc:df:eb:ce:ce:15:74:84:d4:d3:42:f0:9e:ec:04:
25:7a:38:ef:b3:fa:a1:47:e6:72:76:ed:f7:f7:1a:08:60:43:
36:10:06:d5:7f:df:34:cf:8e:ff:3d:5d:0a:8b:2e:4e:44:f8:
a2:40:a0:05:e5:a4:aa:12:91:57:5a:7e:d1:28:e1:e6:61:b9:
2e:eb:87:0e:35:f4:48:2c:e6:1c:41:e3:7b:12:a8:62:a8:ff:
df:3d:3d:71:ba:e3:12:21:97:48:19:b2:d8:cc:06:47:ff:67:
95:a2:ea:bc:62:b1:ea:bd:85:12:16:74:da:73:53:42:f1:64:
b3:61:20:70:60:c1:0a:5a:6a:19:ac:48:5c:27:da:a0:a7:13:
15:0b:d1:ac:15:6d:98:14:18:bc:66:12:7c:94:85:26:e3:af:
06:3c:15:33:cf:54:ac:a8:44:f8:dd:d7:fa:95:25:92:cb:3a:
c1:ae:06:e0:e0:e5:59:58:aa:60:3b:4f:be:d2:0f:ae:d8:74:
b0:b1:16:84
If I mokutil --list-enrolled
I get
MokListRT is empty
The motherboard is an ASUS X99 USB Pro 3.1. Isn’t there any way I can enroll a key, say through USB key directly in the BIOS ?
During the apt install step, I belive it prints the location it saves the key. You can try putting that on a usb stick and loading it in the bios, yes.
If not, probably the easiest thing to do is just disable secure boot. It is a security feature and it is important, but if your bios won’t behave there isn’t much of a choice.
Also, Windows won’t like it if you change the secure boot state while it’s installed, so you may want to ensure you have your windows files backed up if you dual boot on the machine.
I finally manage to install the drivers ( I picked the 440, as my ubuntu version is 18.04 LTS).
Thanks mdegans for the insights.
I took inspiration from this post : How to install nvidia driver with secure boot enabled? - Ask UbuntuScreenshot from 2020-03-19 21-53-59|690x458
I downloaded the 440 drivers from the website.
That’s the manual way, yeah, but from what I understand DKMS is supposed to do that for you. It does on my server anyway for various modules, and it rebuilds them on every kernel update.
The problem with doing it manually is the next time you update your kernel, which happens regularly, you’ll have to build sign your modules again before you reboot, or your display manager won’t start.
I haven’t run the manual setup in a while, but it used to get stuck in a loop when it hit the display manager in such cases. If I were you I’d make sure to have ssh access to the machine so if it does happen, you can:
sudo systemctl isolate multi-user.target
to drop to a tty, run setup again with your key like you did in step 10, and reboot. You don’t actually have to drop to a tty, but it’ll stop the display manager making your monitor convulse.
Anyways, if you do want 440, there is a repo with up to date packages you can try. You could give it another shot and see what happens. I believe nvidia-driver-440 is the package you are looking for, and nvidia-headless-440 for a headless server. There is also nvidia-utils-440 that has nvidia-smi but it may be included by the metapackage. I don’t really know since my only linux nvidia x86 box is headless.
You might want to report your bios not prompting to Canonical. It should be working for you.
You were completely right mdegans, first kernel update: infinite login loop …
Luckly I remember your wise advice, and
…and everything was back in place.
My machine is not a server, is a standard desktop computer (with dual boot). So I have access to it.
The problem is that the MoBo ( Asus X99 USB 3.1) has some sort of bug (also) when it comes to key enrollment.
When I’m on ubuntu it always fails to enroll keys (that’s why I’ve to directly point to secret and public key during installation, as I manually installed that very key in the BIOS).
Do you foresee any workaround to install the drivers kernel-update-safe?
Thanks
If there’s only a problem with automatic key-enrollment, you could simply manually import the Ubuntu generated one in /var/lib/shim-signed/mok and then use the Ubuntu driver with dkms and auto-signing.
https://wiki.ubuntu.com/UEFI/SecureBoot/Signing
Yeah, the boot loop was a regular thing for me until dkms was fixed to sign things in Ubuntu 18 (iirc). I would usually fix it via ssh if i forgot to sign it manually before boot. The tty key combo did not work for me. It would keep bringing me back to the display manager.
TFM:
Signing things is complex — you need to create SSL certificates, enroll them in firmware or shim… You need to have a fair amount of prior knowledge of how Secure Boot works, and that the commands to use are. It’s rather obvious that this isn’t at the reach of everybody, and somewhat bad experience in the first place. For that reason, we’re working on making the key creation, enrollment and signatures easier when installing DKMS modules.
Of course, like much of the Ubuntu documentation, that page hasn’t ben updated and the above mentioned work has been integrated. I did a search of my server and found the certificate and private signing key and certificate under /var/lib/shim-signed/mok This location is printed out on driver install, iirc.
To fix your issue, just copy the MOK.der file (the public part) to a usb stick and load it in the bios manually like you did before with the key you made yourself. Then the next time a driver update happens and the module is signed with the private key, the cert will be in bios and the kernel will load the modules.
Normally this happens automatically. On Googling, this seems to be an issue with some Asus boards. A bios update might fix the automatic enrollment, but this manual enrollement should work for you as well (at least until a reinstall, when a new key pair will be generated). I am not sure if you can trigger apt to try again, but you could try sudo mokutil --import /var/lib/shim-signed/mok/MOK.der after a bios update, just to test if the bios updates fixes the enrollment process from the os…
Ninja’d me :)