NVIDIA, with the rise in popularity of Large Language Models (LLMs), has firmly secured its position as the leader in the GPU market, leaving AMD GPUs far behind. However, for Linux users, installing NVIDIA GPU's drivers is still troublesome. In this article, I’ll cover key concepts about NVIDIA drivers and will show an easy way to install them on Debian OS. This article is a long-read, however, understanding how driver-related things work on Linux will make your user experience much better.

Speaking about LLMs, other AI models, neural networks, etc. - if you're here because your final goal is to run them on your GPU, you're on the right track. Installing the NVIDIA drivers is the FIRST STEP toward enabling your algorithms to run on your NVIDIA GPU.

BUT. It’s only the step 1/2. The next essential step is installing the CUDA Toolkit. Don’t be misled: just having the drivers installed is not enough to actually use your GPU with Compute Unified Device Architecture (CUDA).

The confusion often comes from NVIDIA’s own documentation. Sometimes docs refer to the drivers as "CUDA" something - for example, just try to make sense of the first three compatibility tables here). Also, after successfully installing the NVIDIA drivers when you run nvidia-smi and see a "CUDA Version: 1y.x" there, it’s easy to think "cool, it’s all set up—2-in-1, done!" But nope - that’s just the CUDA "user-space" driver. It’s not the actual CUDA toolkit your algorithms need to perform GPU-based computations.

Here’s the roadmap of this article:

1 Linux kernel & Co .ko: Understanding what are the drivers on Debian OS and how they are related to Linux kernel.

• 1.1 Drivers = Kernel Modules
• 1.2 NVIDIA drivers ≈ nvidia*.ko + libcuda.so; libcuda.so != CUDA Toolkit!

2 NVIDIA documentation & NVIDIA recommended drivers

• 2.1 NVIDIA OpenED Source of their Drivers? O_o

3 NVIDIA drivers installation: "Debian" way:

• 3.1 Installation Step 1: Add the contrib and non-free repository components to the list of sources for apt
• 3.2 Installation Step 2: Check if your OS is booted with Secure Boot
• 3.3 Installation Step 3: Check if your system uses dracut
• 3.4 Installation Step 4: Choose a flavour - "proprietary" vs "open"
• 3.5 DKMS is your bro when it comes to drivers
• 3.6 About Linux Headers
• 3.7 nvidia-kernel-dkms OR nvidia-open-kernel-dkms <-- install kernel space components of NVIDIA drivers; libcuda1 and other libraries (lib*) <-- install user-space components of NVIDIA drivers, a.k.a CUDA drivers

4 How and when to update NVIDIA drivers

My GPU model: NVIDIA Corporation GA106 [GeForce RTX 3060 Lite Hash Rate]

UPD: Added a section about NVIDIA drivers installation on Debian Trixie (testing) and about newest NVIDIA drivers installation following the NVIDIA guide (with precaution measures)

1. Linux kernel & Co .ko

When you first install an OS using a graphical installer, you might notice the graphics of Installer look a bit rough or stretched, kind of like this:

After installation is finished and you boot for the first time, everything usually looks fine in terms of resolution. That’s because, during the installation of Debian or any other OS, the Linux Kernel with default drivers (including drivers for Graphical Output) are installed.

You boot from a pen drive with .iso installer to install Debian OS →
at the early stages of installation the Linux kernel is getting installed (as no OS can operate without it) →
the Kernel doesn’t come alone - it has kernel modules, which are essentially the Linux drivers for your PC's hardware pieces.

During installation, the installer doesn’t connect to the Linux kernel source repository (upstream, containing the most recent existing version of Linux kernel) to fetch the kernel for your system; instead, it connects to its own repository, where the Linux kernel is packed, optimised, and tuned to work harmoniously with the system. In case of Debian:

The kernels in Debian are distributed in binary form, built from the Debian kernel source. It is important to recognize that Debian kernel source may be (and in most cases is) different from the upstream (or "pristine") kernel source, distributed from www.kernel.org and its mirrors. Due to licensing restrictions, unclear license information, or failure to comply with the Debian Free Software Guidelines (DFSG), parts of the kernel are removed in order to distribute the source in the main section of the Debian archive. (Source)

Key takeaway:

Your OS's kernel has kernel modules and they are providing your OS with possibility to use various hardware components of your PC, because drivers per se are kernel modules.

1.1 Drivers = Kernel Modules

You can explore the drivers available on your system by running ls /lib/modules/$(uname -r)/kernel/drivers/ ($(uname -r) part retrieves the exact version of the kernel currently in use by your system; there might be multiple kernel versions installed, especially if you regularly update your system packages (some updates bring also new version of Linux Kernel).

When I run lspci -k | grep -A 3 NVIDIA, I can see that currently for my NVIDIA video card, the kernel driver in use is Nouveau. By default, Debian provides Nouveau drivers for NVIDIA graphics cards because they are open-source and non-proprietary, unlike NVIDIA’s official drivers.

Is it because Debian devs are obsessed with some anti-capitalist or whatsoever views so they pack their system only with open source "free" software? Nope. The point in sticking to open source software is that open source software can be tested and integrated to an OS much easier than closed-source software. Its behaviour, impact on other OS’s components is much more predictable because source code is open.

I mentioned that Debian "provides" Nouveau drivers (not only them, ofc), and I’d like to elaborate on word "provide". On Debian, the Linux kernel is not just a standalone "file/object" pulled during installation - it is a package. This package is called linux-image-*, where the asterisk represents a specific target architecture build of the kernel package, such as cloud, amd64, rt, and the version of this package. This kernel package linux-image-*brings with itself default kernel modules, like the Nouveau driver (nouveau kernel module), to ensure hardware compatibility out of the box. You can actually check which package provides a specific kernel module with dpkg-query command. In case of nouveau driver for NVIDIA video card the command will be:
dpkg-query -S /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/nouveau/nouveau.ko

Even though there’s nothing wrong with Nouveau drivers for NVIDIA GPU — you can use them and enjoy very good performance (many Linux users prefer them over NVIDIA’s proprietary drivers). However, if you plan to use your NVIDIA GPU for AI, machine learning, or LLMs, you will absolutely need NVIDIA’s proprietary drivers.

1.2 NVIDIA drivers ≈ nvidia*.ko + libcuda.so

As I mentioned above, the NVIDIA drivers are kind of the foundation on top of which the CUDA Toolkit will sit. The CUDA Toolkit is what actually provides your algorithms with access to GPU-based computations. However, installing the CUDA Toolkit is the next step—it comes AFTER installing the NVIDIA drivers.

This section is dedicated to kernel modules; when it comes to installing drivers for something on Linux, it’s technically about installing (a.k.a building) kernel modules. You can even "physically" find them on your system. They have the .ko extension (.ko stands for Kernel Object) and live in the kernel-related directories, typically under /lib/modules/$(uname -r)/ (remember, uname -r displays your system's kernel version).

However, in the case of NVIDIA driver installation, it’s not just about installing the nvidia*.ko modules (yep, there’s more than one). There’s another important piece that works closely with those NVIDIA kernel modules: the user-space libraries (NB! it is not about users of PC, it is about stuff outside kernel-space). The most important one is libcuda.so (.so stands for Shared Object). And again—please don’t get confused. Yes, it’s called "CUDA", but it’s not the CUDA Toolkit.

The key takeaway here is that NVIDIA driver installation should be done sensibly - you want the NVIDIA .ko kernel modules and the NVIDIA .so libraries to communicate properly. If you install the drivers in a messed up way - like making multiple installation attempts without properly cleaning up after failed ones - things can easily get twisted and broken.

NVIDIA drivers ≈ nvidia*.ko + libcuda.so
BUT!
libcuda.so != CUDA Toolkit

2. NVIDIA documentation & NVIDIA recommended drivers

In my experience, when it comes to installing NVIDIA drivers, the most common approach people take is going straight to the official NVIDIA website, finding the driver that matches their GPU model, downloading SOMETHING (it is never a kernel module, driver file or something close - it is usually an installer script, file with extension .run), and then trying to execute downloaded file to install drivers.

And it’s usually at that step the frustration starts. Even though the installer provides a TUI (text-based user interface) and tries to guide you through, it starts throwing all kinds of technical prompts you have to manage. If you don’t fully understand what the installer is actually asking, it can be devastating. Don't worry I got you covered.

If you go to the official NVIDIA site on the Download The Official NVIDIA Drivers | NVIDIA page, you’ll be prompted to manually enter your NVIDIA device model. Here’s what’s suggested for my NVIDIA GeForce video card:

Let’s say I just pick the first one in the list, which has a nice description:

What is an NVIDIA Recommended Driver?
This driver meets the quality levels applied to Windows drivers that pass testing in Windows Hardware Quality Labs (WHQL), therefore providing the same attention to driver reliability, robustness, and performance for non-Windows operating systems (e.g., Linux).

Well that's nice that it was tested in some Windows Hardware Quality Labs, but I am searching for Linux drivers...well...whatever. If I click on the View button, I’m redirected to the Download page. There, you’ll see three tabs—click on Additional Information, and that’s where the installation instructions are hiding!

Installation instructions: Once you have downloaded the driver, change to the directory containing the driver package and install the driver by running, as root, sh ./NVIDIA-Linux-x86_64-570.133.07.run

Seems very easy-peasy-lemon-squisy. But what is that .run stuff?

NVIDIA describes its .run installation file as a helper script for installation of NVIDIA drivers, as it can help you to select the correct driver version:

If you are not sure, NVIDIA provides a new detection helper script to help guide you on which driver to pick. For more information, see the Using the installation helper script section later in this post. (Source)

On Linux systems, a .run file is typically either a single binary executable or a shell script that includes a binary blob that can be installed (source). Essentially, any .run file acts as an installer script that will make system-wide changes, since it specifies that it should be executed with root permissions. As I mentioned earlier, drivers are kernel modules, so this installer will build an additional kernel module for your OS. But how exactly will be built this new kernel module(s?) - it will be just binaries, or DKMS will build a new kernel module for my system following the instructions? (If you do not understand the difference, don't worry I will cover it later in this article)

Anyway, if you don’t have a clear answer to question above, that's reason enough NOT to execute this .run file on your Debian system with root privileges without a second thought.

This isn’t about the security risks with NVIDIA drivers or the possibility of some embedded nasty stuff—it’s about your Debian stability + the future maintenance of installed drivers. Plus, it will be much more difficult to debug/uninstall this stuff if something goes wrong.

Moreover, a first paragraph of "Additional information" section on the Driver download page states this:

Note that many Linux distributions provide their own packages of the NVIDIA Linux Graphics Driver in the distribution's native package management format. This may interact better with the rest of your distribution's framework, and you may want to use this rather than NVIDIA's official package. (Source: NVIDIA driver details)

And as you can guess, in this article I will show how to install drivers as Debian's native package. However, I have added a bonus section at the end of this article where I show how I install drivers with precaution measures using NVIDIA installer .run script.

2.1 NVIDIA OpenED Source of their Drivers? O_o

For a long time, NVIDIA drivers were renown for their very close-source-ness and even their license states clearly:

You may not reverse engineer, decompile, or disassemble the SOFTWARE provided in binary form, nor attempt in any other manner to obtain source code of such SOFTWARE.

However, there’s an interesting thing — in July 2024, NVIDIA published an article on their site titled "NVIDIA Transitions Fully Towards Open-Source GPU Kernel Modules".

Apparently, this transition didn’t just start in 2024 — they actually began it back in 2022. Here’s the link to the article.

At first glance, you might think: "Wow, cool — now it must be easier to install drivers, as Linux OS can integrated them easier to their codebase".

However, it seems that it’s not like NVIDIA published the source code of their proprietary kernel modules (NVIDIA drivers) — at least from what I understand. Instead, they created a separate open-source development driver branch, where the community can contribute and all that. Here is the GitHub repository: NVIDIA/open-gpu-kernel-modules.

As I mentioned, as a bonus section to this article I will show you the process of NVIDIA drivers installation following NVIDIA documentation. However, luckily, there is much easier and more "comprehensible" way to install NVIDIA drivers - Debian way.

3. NVIDIA drivers installation: "Debian" way

The procedure for installing NVIDIA drivers is covered in detail in NvidiaGraphicsDrivers - Debian Wiki. I mentioned the "Debian way" of drivers installation, and actually it is a broad term related not only to drivers installation, and if you’re using a Debian distro, I recommend familiarizing yourself with this term. You can find many details here.

In the documentation, the section you need is "Debian 12 Bookworm" (I’m assuming you’re using this version of Debian, the latest stable one). The version of the NVIDIA drivers installed by following that guide will be 535.183.01. Yes, this version is older than the "official" driver available on NVIDIA’s website (currently, it is 570.x.x), which I mentioned earlier. However, this is a trade-off: you sacrifice a bit in terms of the driver’s newness, but you gain system stability and ease of installation.

The "Debian way" of installing NVIDIA drivers is about installing them as a couple of packages using apt package manager. However, as I mentioned, NVIDIA’s software is proprietary and historically close-source, so Debian keeps this type of third-party software in a separate component of its package repositories.

If you’re unfamiliar with how Debian packages its software, apt for you is a sort of "black box", and the sources.list file seems completely incomprehensible, I highly recommend checking out these articles before proceeding: about Debian releases, about Debian software installation - repositories and repository components.

The package(s) containing the NVIDIA drivers is located in the "non-free" component of Debian’s package repositories. The term "non-free" doesn’t mean you need to pay to use the packages found there; rather, it refers to the nature of the software, as it includes closed-source code that isn’t publicly accessible. By default, "non-free" component is excluded from the list of sources that apt uses to fetch and install packages onto your system.

Debian Way Installation Step 1: Add the contrib and non-free repository components to the list of sources for apt:

$ sudo vim /etc/apt/sources.list
#add contrib and non-free components and check that non-free-firmware is also listed:
deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
#this step is important: you have to make apt aware of changes made to this file:
$ sudo apt update

NB! If you have your kernel package linux-image-* installed not from Debian _bookworm repo but from Debian backports repo, you will need to install NVIDIA drivers also from there! This is due to the various dependencies linked to kernel and its version of NVIDIA drivers package!_.

Debian Way Installation Step 2: Check if your OS is booted with Secure Boot.

Rule of the thumb - if you use a Dual Boot with Windows 11, high chances is that Secure Boot is enabled!. To be sure, run sudo mokutil --sb-state. If you see this:

$ sudo mokutil --sb-state
SecureBoot enabled

If you do not understand what the Secure Boot is about, you will need to study it. I wrote the detailed article about Secure Boot and Debian, specifically from the perspective of how it impacts kernel modules and NVIDIA drivers. As an alternative, you always can find all answers in Debian Documentation - SecureBoot - Debian Wiki.

NB! If you have Secure Boot enabled and proceed with the following steps, your installed NVIDIA drivers will NEVER load until you have them signed. The process of kernel modules signing for Secure Boot setups is out of the scope for this article!

If you don’t know how to sign kernel modules for UEFI, I strongly recommend reading the Debian documentation or the article I mentioned. Once you’ve learned how to handle Secure Boot and have new kernel modules signed, you can return here to continue with the installation steps. FYI, in this article, I am installing drivers on my system that has Secure Boot enabled.

Debian Way Installation Step 3: Check if your system uses dracut.

Dracut is the low-level tool that is used to create an initial image used by the kernel for preloading the block device modules (such as IDE, SCSI or RAID) which are needed to access the root filesystem, mounting the root filesystem and booting into the real system (Source). This "job" can be done not only by dracut, but also by initramfs-tools. You can find out "who" does this job for your system with dpkg -l | grep -E 'dracut|initramfs-tools'. If you see in the output dracut, you have to:

• Make a dracut configuration file /etc/dracut.conf.d/10-nvidia.conf (you can actually name it anything you like, as long as it ends in .conf) with the following contents:

install_items+=" /etc/modprobe.d/nvidia-blacklists-nouveau.conf /etc/modprobe.d/nvidia.conf /etc/modprobe.d/nvidia-options.conf "

• Note the spaces between quotes and characters.
• The modprobe.d files referenced here will be added by the nvidia-driver package. #### Debian Way Installation Step 4: Choose a flavour - "proprietary" vs "open"

I mentioned the fact that there is ongoing transition of NVIDIA fully towards open-source GPU kernel modules. It is cool, no doubts, but in this transition period for us, users, this just adds more confusion. Here is the Debian Documentation on NVIDIA drivers installation:

Which "flavour" should you choose? If before there was question: which version should you install? Now the question is: which flavour (open source/proprietary) and which version should you install?

If you're an open-source software supporter, the choice might seem pretty obvious. But at the same time, it’s worth noting that this relatively new open-source flavor of the NVIDIA driver stack is still, well... relatively new compared to the proprietary version we've been using for years. That might (or might not) mean it's less mature and potentially more prone to bugs or issues.

However, in practice, as newer driver versions come out and you get your hands on more modern GPUs, you might find that you actually do not have a choice anyway.

In NVIDIA's article about their transition to open-source kernel modules, I found two important diagrams:

Previously, using the open-source GPU kernel modules would mean that you could not use the top-level metapackage. You would have had to install the distro-specific NVIDIA driver open package along with the cuda-toolkit-X-Y package of your choice.
Beginning with the CUDA 12.6 release, the flow effectively switches places (Source)

CUDA Toolkit is the thingy which should be installed AFTER NVIDIA drivers installation on your system. and CUDA Toolkit version suitable for your system depends fully on the version of CUDA driver version (remember this aforementioned libcuda.so?). Here is the compatibility matrix:

So, according to this table, if you install NVIDIA drivers of version >=560.x.x, you must install "open" flavour if you want to install on top of them CUDA Toolkit.

Little spoiler: version 535.x of "open" falvour drivers doesn’t work on my GPU even if it is supposed to.

I say it is supposed to work, because my GPU device is in the list of supported devices by this "open" flavour drivers. How to understand if "open" flavour is an option for your GPU device?

You need to check the compatibility of your GPU with the NVIDIA's open GPU kernel modules - there’s a table here with all supported models (f you scroll down, you’ll see it).

However, just finding your GPU model name in the table isn’t enough. For example, my GPU — an NVIDIA GeForce RTX 3060 — is listed five or more times. So what you should actually be checking is:

In the below table, if three IDs are listed, the first is the PCI Device ID, the second is the PCI Subsystem Vendor ID, and the third is the PCI Subsystem Device ID.

So first, I had to find the right parameters - at least the first one- the PCI Device ID. Because for my card, in all the mentions in that table, there's only one number that mentioned - the PCI Device ID.

Here is how to identify both Vendor and Device ID:

$ lspci -nn | grep NVIDIA
06:0b:0 VGA compatible controller [0300]: NVIDIA Corporation GA106 [GeForce RTX 3060 Lite Hash Rate] [10de:2504] (rev a1)

From the output above, 10de is the Vendor ID and 2504 the Device ID.

And, apparently my GPU is in the table of compatible devices:

NB! You CANNOT install both flavours - "just to test" (to switch flavour later on you will have to purge the installed one), of course, and I want to explain some stuff about what is the software level difference in-depth between these two flavours (even if installation commands look somehow alike).

NB! DO NOT EXECUTE THESE COMMANDS ONE AFTER ANOTHER, READ THE EXPLANATION BELOW FIRST, IF YOU REALLY DON'T CARE EXECUTE ANY OF THEM, BUT NOT BOTH.

To install "proprietary" flavor these commands should be run:

$ sudo apt install nvidia-driver firmware-misc-nonfree

To install "open" flavor, there is an additional package to install - nvidia-open-kernel-dkms:

$ sudo apt install nvidia-open-kernel-dkms nvidia-driver firmware-misc-nonfree

You can see that both commands install the nvidia-driver package and firmware-misc-nonfree. The latter one is related to firmware, not the driver. Don’t confuse the two - firmware and drivers are not the same thing. However, that’s not really the point here.

What actually makes the difference when installing a specific flavour is the order of the commands — and I’ll show you why. It all comes down to the dependencies each package brings in.

Debian Way Installation: DKMS is your bro when it comes to drivers

First, I want to elaborate on nvidia-open-kernel-dkms package — specifically the dkms part of this package name.

DKMS is your bro when it comes to Linux drivers (kernel modules).

Dynamic Kernel Module Support (DKMS) is a framework which allows kernel modules to be dynamically built for each kernel on your system in a simplified and organized fashion. (Source)

It is exactly DKMS that takes care of automatically rebuilding registered kernel modules (read drivers) whenever you install a different Linux kernel.

If you install some proprietary drivers on Debian without DKMS is not ideal. What’s actually happening under the hood during installation is that standalone kernel modules (those .ko files) are compiled as-is.

Leaving stability aside for a second, the first major inconvenience you’ll run some time after installation into is this: you’ll have to reinstall (rebuild) them manually every time there’s a major kernel update. And if you have Secure Boot enabled on your system, you’ll also need to sign them all manually. Every time.

So yes — DKMS is the bro when it comes to installing extra drivers (kernel modules). It builds them for you in an organized way.

NB! For experienced folk: I know, that I am generalising — I’m aware that sometimes DKMS can turn into the pure evil and nuke stuff, especially because it’s way too eager to rebuild stuff the moment it sees kernel headers updated.
However, IMHO, for regular desktop/home use on stable systems like Debian, DKMS is still bro in the end.

Chances are your OS doesn’t have the dkms package installed — meaning, no DKMS tool at all. As far as I know, DKMS doesn’t come preinstalled.

DKMS relies heavily on Linux headers, so I want to explain what those are.

Debian Way Installation Step: About Linux headers

If you're using your Debian system the "Debian way", you're probably installing packages mostly from the official Debian repositories. Since these packages (including the kernel) come from Debian’s repos, they’re built and tested to work well together.

The Linux kernel itself comes in the linux-image-* package. After installation, you get a bunch of preinstalled drivers — which are essentially kernel modules — that make various pieces of your hardware work: Wi-Fi sticks, Bluetooth headsets, etc.

These preinstalled drivers are actually part of the upstream Linux kernel. They are separate kernel modules, sure, but they communicate with the kernel seamlessly because they’re written and optimized to do exactly that.

However, when it comes to external, third-party kernel modules (third-party means that the source code was written by non Debian/Linux devs)— for them, your kernel is somehow a black box. These modules can’t just "communicate" to it directly. That’s where Linux headers come in.

Linux headers can be roughly described as the programming interface needed to interact with the Linux kernel. If a module needs to communicate with the kernel, headers are required to build and install it — and to make it work at all.

So here's a basic schematic of how it all fits together:

DKMS<-->linux-headers* package<-->Kernel (linux-image-* package)<--> Your Debian OS

So when you install the package nvidia-open-kernel-dkms, it must pull in headers and dkms as dependencies. You can explore the full dependency chain here.

nvidia-kernel-dkms OR nvidia-open-kernel-dkms <-- install kernel space components of NVIDIA drivers; libcuda1 and other libraries (lib*) <-- install user-space components of NVIDIA drivers, a.k.a CUDA drivers

But now you might be wondering:
"If I want to install the proprietary flavour instead, will I just get some sad, standalone kernel modules built without DKMS?"

The answer is NO. nvidia-driver package as dependencies shall bring you something like nvidia-kernel-dkms (notice, non open).

$ sudo apt install --simulate nvidia-driver 

Installing:                     
  nvidia-driver

Installing dependencies:
  dkms                     libnvcuvid1                libnvidia-rtcore          nvidia-persistenced
  firmware-nvidia-gsp      libnvidia-allocator1       nvidia-alternative        nvidia-settings
  glx-alternative-mesa     libnvidia-cfg1             nvidia-driver-bin         nvidia-smi
  glx-alternative-nvidia   libnvidia-egl-gbm1         nvidia-driver-libs        nvidia-support
  glx-diversions           libnvidia-egl-wayland1     nvidia-egl-common         nvidia-suspend-common
  libcuda1                 libnvidia-eglcore          nvidia-egl-icd            nvidia-vdpau-driver
  libegl-nvidia0           libnvidia-encode1          nvidia-installer-cleanup  nvidia-vulkan-common
  libgl1-nvidia-glvnd-glx  libnvidia-glcore           nvidia-kernel-common      nvidia-vulkan-icd
  libgles-nvidia1          libnvidia-glvkspirv        nvidia-kernel-dkms        update-glx
  libgles-nvidia2          libnvidia-ml1              nvidia-kernel-support     xserver-xorg-video-nvidia
  libgles1                 libnvidia-pkcs11-openssl3  nvidia-legacy-check
  libglx-nvidia0           libnvidia-ptxjitcompiler1  nvidia-modprobe

Suggested packages:
  menu  nvidia-cuda-mps

Let me give you a comparison. Let's say you want to install the Brave browser, and you already have Firefox installed. When you installed Firefox, it brought in a bunch of dependencies needed for a browser to function on your freshly installed Debian. Brave is also a browser — and even though it definitely has its own unique dependencies (maybe fewer, maybe more), it may still rely on some of the low-level stuff that Firefox already brought in. So when you install Brave, it might skip installing those dependencies because they’re already there.

It can also go the other way: Brave might be able to use low-level software A or low-level software B to function, and it just happens to find the low-level software B Firefox brought in. So Brave uses that instead of pulling in the low-level software A. But if you had installed Brave first, it would have brought in low-level software A. :3

Same logic applies here with the NVIDIA drivers.

If the nvidia-driver package doesn't find any existing NVIDIA kernel modules already installed, it will go ahead and install everything — including the kernel-level stuff.

But if you already installed the kernel modules beforehand (through nvidia-open-kernel-dkms), and then you install nvidia-driver, it will bring in just the user-space libraries.

$ sudo apt install --simulate nvidia-open-kernel-dkms nvidia-driver

Installing:                     
  nvidia-driver  nvidia-open-kernel-dkms

Installing dependencies:
  dkms                     libnvcuvid1                libnvidia-rtcore            nvidia-settings
  firmware-nvidia-gsp      libnvidia-allocator1       nvidia-alternative          nvidia-smi
  glx-alternative-mesa     libnvidia-cfg1             nvidia-driver-bin           nvidia-support
  glx-alternative-nvidia   libnvidia-egl-gbm1         nvidia-driver-libs          nvidia-suspend-common
  glx-diversions           libnvidia-egl-wayland1     nvidia-egl-common           nvidia-vdpau-driver
  libcuda1                 libnvidia-eglcore          nvidia-egl-icd              nvidia-vulkan-common
  libegl-nvidia0           libnvidia-encode1          nvidia-installer-cleanup    nvidia-vulkan-icd
  libgl1-nvidia-glvnd-glx  libnvidia-glcore           nvidia-kernel-common        update-glx
  libgles-nvidia1          libnvidia-glvkspirv        nvidia-legacy-check         xserver-xorg-video-nvidia
  libgles-nvidia2          libnvidia-ml1              nvidia-modprobe
  libgles1                 libnvidia-pkcs11-openssl3  nvidia-open-kernel-support
  libglx-nvidia0           libnvidia-ptxjitcompiler1  nvidia-persistenced

Suggested packages:
  menu  nvidia-cuda-mps  nvidia-kernel-dkms  | nvidia-kernel-source  | nvidia-open-kernel-source

And no, this has nothing to do with your user’s home folder or /home or anything like that. This goes much deeper — we're talking about memory spaces: kernel space vs user space.

The key point here is that in this context, kernel space always comes first — the kernel modules are the base layer. The user-space components (like libraries and tools) attach themselves to what's already there in kernel space.

_NB! Potential culprit if you have installed NVIDIA drivers but they do not work - your NVIDIA kernel modules versions should be aligned with your nvidia-driver version, you can do analysis with dpkg -l or apt list - - installed and grep nvidia

So, actually, your flavour choice all boils down to two packages — only one of which will be installed and used on your Debian:
nvidia-kernel-dkms or (its dependency alternative) nvidia-open-kernel-dkms.

Installing "proprietary" flavour, version 535.x.y - from LTS branch

I have installed "proprietary" flavor because as I mentioned even though my GPU is in compatibility matrix with "open" flavor of 535.x. driver version does not work. I will show you error I get later.

Before dealing with anything related to drivers I ALWAY create a snapshot of my system. I use Timeshift tool for this. You can check this my article on snapshotting with Timeshift.

To purge all existing nvidia-packages installed on your system you can try something like that:

# to list nvidia-related packages installed previously with apt
$ apt list --installed | grep nvidia
$ sudo apt --purge remove '*nvidia*'
$ sudo apt autoremove

Installation:

$ sudo apt install nvidia-driver firmware-misc-nonfree
# NB!!!If your linux-image-* package is from bookworm backports, you must install nvidia-driver package from this repo to avoid broken dependencies error!

If you did not blacklist nouveau drivers before installation, at certain point during installation you will see a warning message in the terminal (likely on the blue background):

Conflicting nouveau kernel module loaded
The free nouveau kernel module is currently loaded and conflicts with the non-free nvidia kernel module
The easiest way to fix this is to reboot the machine once the installation has finished

So, you just need to press Enter to proceed, the solution is the reboot - once installation has finished, reboot your system (sudo reboot).

When you are booted again, run nvidia-smi command.
This is my output:

If you see something similar (and no errors), congratulations! You have successfully installed the NVIDIA drivers. For additional confirmation, you can list your PCI devices and the kernel modules in use (loaded drivers) by running lspci -k | grep -A 3 NVIDIA.

Here are NVIDIA kernel modules built by DKMS with love for you:

$ sudo modinfo -n nvidia
/lib/modules/6.12.21-amd64/updates/dkms/nvidia.ko

$ ls /lib/modules/6.12.21-amd64/updates/dkms/
nvidia-drm.ko  nvidia.ko  nvidia-modeset.ko  nvidia-peermem.ko  nvidia-uvm.ko

$ ls /usr/lib/x86_64-linux-gnu/ | grep libcuda
libcudadebugger.so.1
libcudadebugger.so.535.183.01
libcuda.so
libcuda.so.1
libcuda.so.535.183.01

4. How and when to update NVIDIA drivers

This section is not about NVIDIA driver VERSION updates, because even other Debian releases (Unstable, Testing) offer the SAME major NVIDIA driver version—535.x—just like Bookworm repo. So if you’re not planning to downgrade (which is another story entirely), I don’t really see any "debian source" for VERSION update.

However, I do want to discuss a different kind of NVIDIA driver update—not about the version, but about the kernel module update itself.

If this question still did not pop up in your mind, I will anticipate it: "Since NVIDIA drivers are kernel modules, what happens to them then when Debian kernel version updates?"

It can be quite common that when you start using Debian, one of the first things you do is install NVIDIA drivers. But eventually, if you’re using Debian Stable release, you might encounter the need for a more major kernel version—for example, in my case, it was for Wi-Fi USB adapter drivers. So you learn a bit about backports and update the kernel from there - not just small regular updates from Debian Stable repositories (like from 6.1.10 to 6.1.11), but literally jumping from kernel v6.1.x to v6.9.x or even v6.12.x. That’s a major jump, and there’s a good chance your NVIDIA driver won’t work properly. Why? Because of Linux headers.

As I mentioned, headers are really important for NVIDIA drivers to work on your system. They serve as an API or interface that the NVIDIA driver uses to communicate with the kernel. When you update the kernel with sudo apt install -t bookworm-backports linux-image-amd64 (to install the newest kernel version from backports), it will only install the kernel and not the headers! You have to install the headers manually, and they must match your kernel version exactly. So if you install linux-image-amd64 from backports, you also have to install the headers in the same way (linux-headers-amd64). If you use a more detailed command pointing to the exact version of linux-image* package (e.g. sudo apt install -t bookworm-backports linux-image-6.9.7+bpo-amd64), the headers should match it (e.g. sudo apt install -t bookworm-backports linux-headers-6.9.7+bpo-amd64)—they’re always paired.

Here’s the trick with NVIDIA driver updates: if you installed them the Debian way, they were built with DKMS. This nice tool will rebuild (read "update") your NVIDIA drivers, and the trigger for that is installing the linux headers. During the final steps of their installation, you’ll see in log that DKMS is rebuilding stuff (and not just NVIDIA drivers, but also other kernel modules-drivers you installed in a way that they were built with DKMS).

So, this is yet another reason why it’s better to install NVIDIA drivers in the Debian way, or at least make sure that whatever you install manually is built with DKMS and not just scrapped together with some script.

However, keep in mind, that a VERY major kernel update (for example, when kernel gets updated from version 6.x to 7.x) may require installing a newer NVIDIA driver, as changes to the kernel APIs may not be compatible with the existing driver version.

5. BONUS SECTIONS

5.1 Installing driver in NVIDIA suggested way (with .run file)

I downloaded my "driver" (.run file) for my GPU card model from this section of NVIDIA Official website using:

$ wget https://us.download.nvidia.com/XFree86/Linux-x86_64/570.133.07/NVIDIA-Linux-x86_64-570.133.07.run

The search prompt where you can enter your OS, GPU model, etc., is here.

A link to the README instructions is available under the Additional Information tab on the download page of a driver.

Chapter 4 of this README is dedicated to installation of NVIDIA driver with this .run executable.

The .run file is a self-extracting archive. When executed, it extracts the contents of the archive and runs the contained nvidia-installer utility, which provides an interactive interface to walk you through the installation.

And here is about how Nvidia driver installation will communicate with your kernel:

When the installer is run, it will check your system for the required kernel sources and compile the kernel interface. You must have the source code for your kernel installed for compilation to work. On most systems, this means that you will need to locate and install the correct kernel-source, kernel-headers, or kernel-devel package; on some distributions, no additional packages are required.

In a default Debian setup (the set of packages you get pre-installed), you’ll only have the package linux-image-* (which contains kernel itself and default kernel modules-drivers, as it was mentioned above)—without the kernel headers or developer libraries preinstalled.

So, naturally, the installation process for NVIDIA drivers requires having Linux headers. However, Linux headers aren’t the only requirement for installation. And the README file contains all the additional instructions.

The important section to pay attention to—which can cause a very unpleasant experience for your PC management—is if this .run script does not find DKMS (Dynamic Kernel Module Support) installed on your system:

The installer will check for the presence of DKMS on your system. If DKMS is found, you will be given the option of registering the kernel module with DKMS. (README)

If this .run script doesn’t find it—will it prompt you to install it, give a warning, fail, or install it for you? I really have no idea.

So, if the NVIDIA proprietary .run installer doesn’t find DKMS installed on your system (dpkg -l| grep dkms), it will probably compile just standalone kernel modules for each component of their drivers—meaning you’ll have to rebuild them manually at every major kernel update. And if you have Secure Boot enabled on your system, you’ll also need to sign them all manually.

So, first I install DKMS and Linux headers. The dkms package itself pulls in the linux-headers-* package as a dependency. However, be cautious! If you've made any modifications to your kernel (like an update or whatever), make sure to double-check that your Linux headers version match the exact version of your kernel — down to every number and dot.

For example, in my case, my kernel version is:

$ uname -r
6.1.9-32-amd64

I install linux-headers-* in this way to ensure the exact match with my kernel version:

$ sudo apt install linux-headers-$(uname -r)
# then, I install DKMS
$ sudo apt install dkms
# I double check the version of linux headers
$ dpkg -l | grep linux-headers*

(If you see more than one version of headers, it’s probably because you updated the kernel in the past — most likely automatically with sudo apt update && sudo apt upgrade. The most important thing is that in the output you see headers with version that corresponds exactly to the current version of the kernel. You can actually remove older versions of the Linux headers used for previous kernel versions if you don’t need them anymore.)

I downloaded the .run file, and now I’m executing it, following these mini instructions:

Installation instructions: Once you have downloaded the driver, change to the directory containing the driver package and install the driver by running, as root, sh ./NVIDIA-Linux-x86_64-570.133.07.run (https://www.nvidia.com/en-us/drivers/details/242273/)

$ sudo sh ./NVIDIA-Linux-x86_64-570.133.07.run

The first thing I am shown in Terminal UI is the choice of flavour again, and as I mentioned, the "open" flavour from the Debian repo didn’t work. Eh, let’s give it a try here!

Okay, right after first complaint: it needs a C compiler (gcc), so I install it with:

$ sudo apt install build-essential
# to check:
$ gcc -v

Nice, as next, it complains about the nouveau driver currently in use by my system:

I press --> Ok

I press --> Yes

There are some scary words in these commands if you’ve never dealt with it before, but it’s not as bad as it sounds. What the NVIDIA installer is asking for is to first unload the nouveau kernel module. This isn’t just because it’s installed and present — it’s actually in use, meaning your NVIDIA GPU is currently serving it, and it can’t be responsive to NVIDIA drivers.

modprobe configurations are essentially files that get dropped into /etc/modprobe.d/. You’ll get one or two text files with a few simple lines — probably something like blacklist nouveau. Then, the initramfs will be updated (rebuilt) so that it knows not to load nouveau on the next boot, but rather the NVIDIA drivers for the kernel.

The configuration files in the /etc/modprobe.d directory will be read during the next boot, and the blacklisting will be respected.

So actually it tells you what I explained above;
If you want to revert changes later you can just cancel these written files from /etc/modprobe.d

I press -->

I press --> (as an alternative I could do Abort and reboot but I am lazy)

Installer starts to build kernel modules...

--------------You can skip all stuff related to keys, signing if your setup does not have Secure Boot Enabled!-------------------------

I press --> < Sign the kernel module >

I press --> (I have generated a keypaor for signing and enrolled MOK key)

Full path to private key:

Full path to public key:

----- Secure Boot related prompts finsihed ------------

Next, warning about 32-bit libraries:

Next, warning about the fact that some user-space library cannot be installed:

Then, I press --> "Rebuild initramfs"

Okay, NVIDIA kernel modules are built.
Only now, the installation of user-space libraries starts:

Then, I select that I do want it writes X configuration file (If you use Wayland, select No!):

Finally, Installation is completed.

I am informed that I have to do reboot.

Well, apparently it works!

Here is the nvidia-smi output (though, with some strange log messages (?):

$ nvidia-smi
Mon Apr 14 18:47:38 2025       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.133.07             Driver Version: 570.133.07     CUDA Version: 12.8     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 3060        Off |   00000000:01:00.0  On |                  N/A |
|  0%   28C    P8             11W /  170W |     845MiB /  12288MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

Summarizing: If you don’t fully understand these instructions and the steps involved, then installing NVIDIA drivers this way might not be for you. You can, of course, experiment (snapshotting tools are great for these kinds of experiments).

5.2 Installing NVIDIA drivers on Debian Testing with KDE Plasma that is running on Nouveau drivers.

If you didn't know, the KDE Plasma Desktop Environment can run on both the X display server and the Wayland display server. If you prefer the X display server and use it, this section is not for you. You just install the drivers, reboot, and your KDE X session should be intact (the session selector is in the bottom left corner on the login menu). The NVIDIA drivers installation process blacklists the Nouveau drivers, so after rebooting, the KDE desktop environment should start with the NVIDIA drivers.​

However, if you use Wayland and stick with it, you'll need some extra configuration. Right after installing the NVIDIA drivers, your KDE Wayland session might break temporarily until you make a couple of modifications. It's not critical - for example, I installed the NVIDIA drivers, rebooted, and my Wayland session failed. I switched to an X session, made the necessary modifications, rebooted, and after that, my KDE Wayland session started smoothly.

Here is some info about one of my setups with KDE:

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux trixie/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=trixie
# My KDE setup is on Debian Testing (Debian 13!)
$ plasmashell --version
plasmashell 6.3.4
$ nvidia-smi
| NVIDIA-SMI 570.133.07             Driver Version: 570.133.07     CUDA Version: 12.8  
# yep I am a baddy, I installed drivers in NVIDIA recommended way :3  

So, I installed NVIDIA drivers, rebooted and logged into KDE X session (Wayland session was not starting). Then, I just followed steps from Debian documentation on NVIDIA drivers installation, section on Wayland support.

$ sudo vim /etc/default/grub.d/nvidia-modeset.cfg
GRUB_CMDLINE_LINUX="$GRUB_CMDLINE_LINUX nvidia-drm.modeset=1"

$ sudo update-grub

$ sudo apt install nvidia-suspend-common

$ sudo systemctl enable nvidia-suspend.service
$ sudo systemctl enable nvidia-hibernate.service
# This command will fail if you did not reboot after nvidia drivers installation and nouveau drivers are still in use by your Debian
$ sudo systemctl enable nvidia-resume.service

$ cat /proc/driver/nvidia/params | grep PreserveVideoMemoryAllocations
PreserveVideoMemoryAllocations: 1

If this parameter is set to zero, you should be able to override it by adding a configuration into modprobe.d (assuming the file doesn't already exist):

$ sudo vim /etc/modprobe.d/nvidia-power-management.conf
options nvidia NVreg_PreserveVideoMemoryAllocations=1

$ sudo reboot 

After reboot, Voila!