NVIDIA drivers on an Ubuntu GPU server

The short way to install NVIDIA drivers on Ubuntu is sudo ubuntu-drivers install --gpgpu, but on a rented GPU VM you usually do not need it, because the plain GPU VM is the provider's Ubuntu image with NVIDIA drivers and Docker. So the first job is to read which driver is already there, and the second is to decide whether a CUDA requirement really forces a newer one. A driver change ends with a reboot, and a reboot is a risk on a VM that you pay for by the hour. The Ubuntu, NVIDIA and DKMS facts below were checked on 12 November 2026.

Check which NVIDIA driver the VM already runs

nvidia-smi --query-gpu=name,driver_version --format=csv
cat /proc/driver/nvidia/version
dpkg -l | grep -i nvidia
sudo ubuntu-drivers list --gpgpu
hostnamectl

The first command prints the GPU names and the driver version. The plain nvidia-smi header adds a CUDA Version, which NVIDIA's nvidia-smi manual calls the CUDA UMD Version and defines as the latest CUDA version supported by the driver. The second command prints the version of the kernel module that is loaded now, as NVIDIA's post-installation page says. The third lists the NVIDIA packages on the disk, the fourth lists the driver packages Ubuntu offers for this machine, and hostnamectl prints the Ubuntu release. NVIDIA's installation guide covers Ubuntu 22.04, 24.04 and 26.04, and has pages for the other Linux distributions too.

The driver branch is the first number of the version, so 580.65.06 is branch 580, which NVIDIA's release notes call R580. If the loaded version and the package versions differ, you have the NVML version mismatch. If nvidia-smi is missing or cannot reach the driver, start with nvidia-smi: command not found or NVIDIA-SMI has failed. Package names show which route installed the driver. Ubuntu's page uses names such as nvidia-driver-NNN-server, while NVIDIA's own repository uses nvidia-open.

When a newer driver branch is really needed

A newer branch is justified by one thing: the software you want to run needs a newer CUDA than the CUDA Version in the nvidia-smi header. NVIDIA's CUDA release notes, last updated on 5 November 2026, give the driver for each release:

Branch 580 is the one CUDA 13.0 shipped with and the floor for every CUDA 13.x build, and the release notes say the new features of CUDA 13.5 need R620 or later. NVIDIA's compatibility guide says an older driver runs such a build with a limited feature set. A feature that spans the toolkit and the driver can return cudaErrorCallRequiresNewerDriver, and then the driver has to be upgraded. The CUDA version guide shows how to read all three CUDA numbers on a machine.

Blackwell adds a second condition: NVIDIA's README for the open kernel modules says Blackwell and later GPUs are supported only by the open modules, which a section below covers.

Pick a container or a wheel that fits instead

Changing the driver is the heavy option. The light one is to change what you run: choose a CUDA container tag or a PyTorch wheel at or below the CUDA Version you wrote down. A tag newer than the driver supports does not start, and the NVIDIA Container Toolkit guide shows the error and example tags. The PyTorch install guide does the same for wheels.

If the image itself is too old, launch another one. The deploy page pre-selects an OS image with CUDA and Docker, newest CUDA first, and the API takes an os_image_id. Provider images ship different driver branches, so run nvidia-smi on the new VM before you copy data to it. Stopping the old instance refunds the unused seconds of the current hour and deletes the disk, so copy off what you need first, as the stop guide lists.

Install NVIDIA drivers on Ubuntu with ubuntu-drivers

Ubuntu's server documentation, last updated on 26 June 2026, packages two kinds of driver. The Unified Driver Architecture drivers suit desktops, and the Enterprise Ready Drivers suit servers and computing, with a -server suffix on the package name. On a GPU server I use the --gpgpu flag, which the tool describes as installing the drivers for a headless server, with a smaller footprint because it skips the graphical packages. These are the page's steps, with NNN standing for a branch from your own list, because the page uses 535 as its example:

sudo apt update && sudo apt upgrade
sudo ubuntu-drivers list --gpgpu
sudo ubuntu-drivers install --gpgpu
sudo ubuntu-drivers install --gpgpu nvidia:NNN-server
sudo apt install nvidia-utils-NNN-server

The page says to reboot after the first command, so read the reboot rules at the end of this guide before you do. The third line lets the tool pick what it considers the best match for the hardware. The fourth chooses a branch and the fifth adds the utilities the page lists for servers. If another NVIDIA driver conflicts, the page says ubuntu-drivers uninstalls it first. Older guides use sudo ubuntu-drivers autoinstall, and the project's changelog says version 0.6 deprecated that argument in favour of install, so I use install. If apt reports a lock on a new VM, Could not get lock explains why.

A machine with NVSwitch hardware, such as an 8-GPU SXM VM, also needs Fabric Manager, and the page says nvidia-fabricmanager-535 matches the nvidia-driver-535-server package:

sudo apt install nvidia-fabricmanager-NNN libnvidia-nscq-NNN

NVIDIA's Fabric Manager guide adds that before driver release 620 the Fabric Manager version must match the driver version, and that from 620 it is versioned on its own.

Install from NVIDIA's repository

NVIDIA's guide says to prefer distribution packages over its distribution-independent installer, which does not update through the package manager. The guide documents branch 620 and was last updated on 9 November 2026. These are its network repository steps for amd64 on Ubuntu 24.04, and the CUDA installation guide gives ubuntu2204 and ubuntu2604 for the other two releases:

sudo apt install linux-headers-$(uname -r)
wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install nvidia-driver-pinning-580
sudo apt install nvidia-open
sudo apt -V install libnvidia-compute nvidia-dkms-open

The pinning line is optional: it keeps the system on branch 580, NVIDIA's example, and NVIDIA recommends installing it before the driver. The nvidia-open line is the full driver, and the last line is the compute-only install without the desktop components, so run one of the two. NVIDIA says to reboot afterwards and check with cat /proc/driver/nvidia/version, and the reboot rules at the end of this guide apply first. Do not mix this route with the one above, because Ubuntu's page warns that drivers from other sources can overwrite the ubuntu-drivers packages and may break Secure Boot.

Update an NVIDIA driver on Ubuntu

apt list --upgradeable 2>/dev/null | grep -i nvidia
sudo apt update && sudo apt upgrade
sudo apt dist-upgrade

The first line shows whether an NVIDIA package is waiting. NVIDIA says a normal package update is enough to upgrade the driver, and that apt dist-upgrade is the command whether you pin a branch or not. To change branch from NVIDIA's repository, install the pinning package for the new one, which NVIDIA's version locking page says is supported from branch 590 on. From Ubuntu's packages, use the ubuntu-drivers install line above. The old kernel module keeps running until the next reboot, so an update you do not finish with one leaves the mismatch from the NVML page, which also shows how to hold the driver against Ubuntu's daily automatic upgrades.

Open or proprietary kernel modules

NVIDIA's driver ships five kernel modules in two flavors. The README for driver 620.70.06 says the proprietary flavor supports Turing, Ampere, Ada and Hopper, that Blackwell and later are supported only by the open modules, and that NVIDIA recommends the open modules on every GPU that supports them. The two cannot be used in the kernel at the same time. The installation guide says in its recent updates that the proprietary modules have been removed and the open modules are now the only flavor it provides. For the cards DeployGPU rents, the README's rule gives this split:

The README gives two ways to see which flavor is loaded:

modinfo nvidia | grep license
cat /proc/driver/nvidia/version

The open flavor prints Dual MIT/GPL and a version line that reads NVIDIA UNIX Open Kernel Module for x86_64. The proprietary flavor prints NVIDIA and NVIDIA UNIX x86_64 Kernel Module. In Ubuntu's list the open packages carry an -open suffix, such as nvidia-driver-535-open.

DKMS, precompiled modules and kernel updates

Ubuntu offers the kernel modules in two ways that exclude each other. The precompiled linux-modules-nvidia packages are built for specific kernels and are signed, so they work with Secure Boot. The DKMS packages build the modules on the machine against the kernel headers, and Ubuntu does not recommend them unless you run a custom kernel that the prebuilt drivers do not support, because they are not signed with Canonical's key. To switch, uninstall the drivers and install again. sudo ubuntu-drivers install --include-dkms makes the tool consider DKMS packages. Before a reboot, check that modules exist for the running kernel:

uname -r
sudo apt-cache policy linux-modules-nvidia-NNN-server-$(uname -r)
dkms status

NVIDIA's FAQ describes the failure after a kernel update: when kernel components change without a reboot, DKMS sometimes does not rebuild the NVIDIA modules for the new kernel. The usual fix is to run DKMS by hand and then reboot, after the reboot rules at the end of this guide. VERSION is the module version from dkms status, which the dkms manual says reports whether each module was added, built or installed, and KERNEL is the new kernel's version.

sudo dkms -m nvidia/VERSION -k KERNEL build
sudo dkms -m nvidia/VERSION -k KERNEL install

Uninstall NVIDIA drivers on Ubuntu

apt-mark showmanual | grep nvidia
sudo apt --purge remove '*nvidia*NNN*'
sudo apt autoremove

These are Ubuntu's commands. The first line lists the packages someone installed on purpose, which shows the branch numbers on the system. The second removes the NVIDIA packages of one branch, and autoremove clears the dependencies, such as 32-bit libraries on amd64. For packages from NVIDIA's repository, its removal page lists an apt remove --autoremove --purge command with 27 package patterns. On a rented VM I uninstall only to switch between the precompiled and DKMS modules. If nothing on the disk is worth keeping, a Stop and a new launch is quicker.

What a driver change means for the reboot rules

Every install and update above ends with a reboot that loads the new kernel modules, and a reboot ends every tmux session and nohup job, as keeping jobs running explains. What is known about an in-guest reboot differs by provider:

The API power cycle is POST /shutdown, a poll of GET /power until it reads stopped, then POST /start, on Verda and Hyperstack only. The NVML page has the script, and it also shows how to unload and load the modules again without a reboot when nothing is using the GPU. Full compute billing continues while the VM is off. A new launch with another OS image avoids the reboot altogether, at the cost of a fresh disk.