How to Install NVIDIA Drivers on Debian 13, 12 and 11

45 thoughts on “How to Install NVIDIA Drivers on Debian 13, 12 and 11”

1. NVIDIA has again said F-U to legacy cards. I will move to a ATI/AMD type when this card dies.

   Reply

2. I am trying to install Debian 13.2 on a PC with an Nvidia RTX-5060 Ti 16GB video card. As I understand it the 5060 Ti is so new that the Debian installer does not recognize it. Thus the installation completes with *no* video driver (not even “nouveau”) installed. I have to use “ctrl-alt-F4” to login at a command-line console.

   Using said console window I tried to follow the instructions on this page to configure my Debian installation to download and install the latest Nvidia driver from the “open” repo. I worked through the procedure without error down to the step “Install the Open Kernel Modules (CUDA Repo)” where I successfully executed the command:

   sudo apt install nvidia-driver nvidia-kernel-open-dkms nvidia-smi nvidia-settings

   and this executed and finished without error. However when I tried the next two steps I got:

   Reboot to Load the NVIDIA Driver
   sudo reboot

   Confirm NVIDIA Driver Installation on Debian
   nvidia-smi

   but the last command yielded

   -bash: nvidia-smi: command not found

   As suggested in the “Troubleshooting” section I tried:

   sudo apt install nvidia-smi
   nvidia-smi is already the newest version (595.58.03-1)

   Ironically, I was getting so frustrated trying to get Steam games to run on this machine back when it had an Intel ARC B580 video card, that I decided to buy a new *Nvidia* card – the RTX-5060 Ti – so that my hardware would be *more compatible* and *easier to install drivers for*.

   Is there any way to get this to work? If it matters , I am pretty certain that the actual installation and build of the kernel modules completed without error…

   Reply

   • UPDATE: I have discovered that what is happening is that although the driver was built successfully it failed to install because it was not “signed” with a “certificate”. I am reviewing content on this site as well as others to determine how to move forward. I want to leave Secure Boot enabled on the this PC because it also hosts a Windows 11 installation. So I am going to try and figure out how to digitally sign this driver so it will load.

     Reply

     • Steve, your follow-up confirmed two separate issues. You were right about the guide needing improvement: NVIDIA’s CUDA repository nvidia-smi package for the 595 branch is a transitional dummy, so APT can say it is installed while the command is still missing. The article now uses nvidia-driver-cuda, which provides /usr/bin/nvidia-smi.

       For Secure Boot, keep it enabled and enroll DKMS’s MOK key. On Debian 13 with the CUDA repo, this is normally enough:

       sudo apt install nvidia-driver-cuda mokutil openssl
       sudo dkms generate_mok
       sudo mokutil --import /var/lib/dkms/mok.pub
       sudo reboot

       At the MOK screen, choose Enroll MOK, enter the temporary password, then reboot. If dkms generate_mok is unavailable or mok.pub is missing, use the article’s Secure Boot section because it now includes the older Debian fallback paths too.

       Reply

       • Hi Joshua! Just a quick note (and a big “thank you”!) to let you know I was successful in getting the Nvidia driver installed for the RTX5060 Ti. I am running driver version 595.58.03-1 under kernel 6.12.73+deb13+1-amd64.

         However I am still trying to figure out how the particular steps *I* went through (more on this later) managed to actually work! Here is what I did, including one thing I perhaps should not have done:

         1) Since I had not had this machine up for a couple of weeks I instinctively did
         sudo apt update
         sudo apt upgrade

         The latter step apparently upgraded me from kernel 6.12.74 to 6.12.88. This was probably a mistake as we shall see…

         2) I then performed the steps in your reply to me above:

         $ sudo apt install nvidia-driver-cuda mokutil openssl
         $ sudo dkms generate_mok
         $ sudo mokutil --import /var/lib/dkms/mok.pub
         $ sudo reboot

         After these steps the boot process still stopped at the “starting CUPS” step as it had all along. I used ctrl-alt-F2 to get a console and then logged in. I presumed the driver was still not loading for some reason, probably related to Secure Boot and the certificate problem. I consulted your Troubleshooting section topic “Secure Boot Blocks NVIDIA DKMS Modules” and did the steps under “Install mokutil and confirm Secure Boot state:” followed by the “generate_mok” steps.

         Here I rebooted but still got stopped at the “starting CUPS” stage (i.e. “black screen”; ctrl-alt-F2). I saw the next steps about “If the NVIDIA module was already built before the key was enrolled…” and realized they applied to my situation, so I performed these steps next. In fact I wrote a bash script that executes these commands and tees the output (STDOUT & STDERR) to a log file in my home directory, since the first time I ran them manually, the output went by too quick to read and there appeared to be an error message. I ran the script and captured the output:

         Error! Your kernel headers for kernel 6.12.88+deb13-amd64 cannot be found at /lib/modules/6.12.88+deb13-amd64/build or /lib/modules/6.12.88+deb13-amd64/source.
         Please install the linux-headers-6.12.88+deb13-amd64 package or use the --kernelsourcedir option to tell DKMS where it’s located.
         update-initramfs: Generating /boot/initrd.img-6.12.88+deb13-amd64

         Seeing this I realized what I had done – my previous build and installation of the Nvidia driver which was successful was done under kernel 6.12.74+deb13+1-amd64 which meant I had headers for that kernel but not the one I was now running (6.12.88). So I thought the best plan would be to restore the machine to the backup I made immediately after the successful driver build, and then repeat the steps I had done so far today *without* doing any “sudo apt update” or “sudo apt upgrade” commands like I had done before. And here is where it gets weird…

         This machine dual boots with Windows 11. It has two NVMe SSDs, a 1TB Gen.5 (very fast) and a 4TB Gen.4 (pretty fast). Windows is installed on the 1TB drive. To take advantage of the Gen.5 speed for Debian, I installed “/” (root) on the 1TB Gen.5 but to avoid problems with Windows corrupting the boot process when booting from the same disk as Debian, I put the “/boot” (2GB) partition on the 4TB Gen.4 drive. Finally, “/home” is also on the 4TB Gen.4 drive, to take advantage of all that fast storage space.

         So, as mentioned above, I decided I needed to revert to kernel 6.12.74 and re-do the steps I had already done today to solve the certificate problem with the Nvidia driver. I use “Clonezilla” and I had made backups of both the “/” and “/boot” partitions immediately after successfully building and installing Nvidia driver 595.58.03-1. I then reinstalled both of these partition images to their respective disks and then rebooted… and to my delight, amazement, and befuddlement, this time the machine booted up perfectly into Debian 13.2 and then straight into KDE Plasma / Wayland!

         Pardon my French but “WTF”?

         I am mystified by how and why this worked. I thought all the steps I took today made changes *only* to the “/” and “/boot” partitions? Did the MOK certificate step make some change in the firmware on the motherboard (Gigabyte X870E Aorus Master) or perhaps in the TPM 2.0 module?

         At any rate it looks like I now have a working system running Debian 13.2, kernel 6.12.74, with Nvidia driver 595.58.03-1 on an RTX5060 Ti (16GB) video card! Thanks again for all your help!

         Reply

         • Steve, the weird part is real but explainable: MOK enrollment is stored in UEFI firmware through shim’s MOK database, not in Debian’s / or /boot partitions and not in the TPM. So the enrollment survived your Clonezilla restore. The restore brought back the 6.12.74 kernel and NVIDIA module that had already been built, and the enrolled DKMS certificate finally let Secure Boot trust it. The 6.12.88 error was separate: DKMS could not rebuild for that running kernel because matching headers were missing. I updated the article to put that header check before the forced DKMS rebuild.

3. Hi,
   I’ve installed the nvidia-open version on Trixie, to replace the drive 550 in the debian vanilla repository (they show some error in the logs, I prefer update).

   Now, if I use drm, xorg do not start BUT if I restart the service sddm in tty2, it works.
   The xorg error is:

   [ 17.478] (II) Loading sub module “fb”
   [ 17.478] (II) LoadModule: “fb”
   [ 17.478] (II) Module “fb” already built-in
   [ 17.478] (EE)
   [ 17.478] (EE) Backtrace:
   [ 17.479] (EE) unw_get_proc_name failed: no unwind info found [-10]
   [ 17.479] (EE) 0: /usr/lib/xorg/Xorg (?+0x0) [0x55b32d1cec6d]
   [ 17.479] (EE) unw_get_proc_name failed: no unwind info found [-10]
   [ 17.480] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7f17b9577df0]
   [ 17.480] (EE) unw_get_proc_name failed: no unwind info found [-10]
   [ 17.480] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7f17b95cc95c]
   [ 17.480] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x12) [0x7f17b9577cc2]
   [ 17.481] (EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x22) [0x7f17b95604ac]
   [ 17.481] (EE) unw_get_proc_name failed: no unwind info found [-10]
   [ 17.481] (EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7f17b9560420]
   [ 17.481] (EE) unw_get_proc_name failed: no unwind info found [-10]
   [ 17.481] (EE) 6: /usr/lib/xorg/Xorg (?+0x0) [0x55b32d0300d7]
   [ 17.481] (EE) 7: /usr/lib/xorg/modules/libglamoregl.so (glamor_init+0xcc) [0x7f17b0f5167c]
   [ 17.482] (EE) unw_get_proc_name failed: no unwind info found [-10]
   [ 17.482] (EE) 8: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) [0x7f17b0f92728]
   [ 17.482] (EE) unw_get_proc_name failed: no unwind info found [-10]
   [ 17.482] (EE) 9: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) [0x7f17b0f887fe]
   [ 17.482] (EE) 10: /usr/lib/xorg/Xorg (AddGPUScreen+0xf4) [0x55b32d052044]
   [ 17.482] (EE) unw_get_proc_name failed: no unwind info found [-10]
   [ 17.482] (EE) 11: /usr/lib/xorg/Xorg (?+0x0) [0x55b32d0b0191]
   [ 17.482] (EE) unw_get_proc_name failed: no unwind info found [-10]
   [ 17.482] (EE) 12: /usr/lib/xorg/Xorg (?+0x0) [0x55b32d0b5e65]
   [ 17.482] (EE) unw_get_proc_name failed: no unwind info found [-10]
   [ 17.482] (EE) 13: /usr/lib/xorg/Xorg (?+0x0) [0x55b32d0b23ca]
   [ 17.482] (EE) unw_get_proc_name failed: no unwind info found [-10]
   [ 17.482] (EE) 14: /usr/lib/xorg/Xorg (?+0x0) [0x55b32d0b2b23]
   [ 17.482] (EE) 15: /usr/lib/xorg/Xorg (config_init+0xd) [0x55b32d0b139d]
   [ 17.483] (EE) 16: /usr/lib/xorg/Xorg (InitInput+0xc1) [0x55b32d094531]
   [ 17.483] (EE) unw_get_proc_name failed: no unwind info found [-10]
   [ 17.483] (EE) 17: /usr/lib/xorg/Xorg (?+0x0) [0x55b32d055c8d]
   [ 17.483] (EE) unw_get_proc_name failed: no unwind info found [-10]
   [ 17.483] (EE) 18: /lib/x86_64-linux-gnu/libc.so.6 (?+0x0) [0x7f17b9561ca8]
   [ 17.483] (EE) 19: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7f17b9561d65]
   [ 17.483] (EE) 20: /usr/lib/xorg/Xorg (_start+0x21) [0x55b32d03e641]
   [ 17.483] (EE)
   [ 17.483] (EE)
   Fatal server error:
   [ 17.483] (EE) Caught signal 6 (Aborted). Server aborting
   [ 17.483] (EE)
   [ 17.484] (EE)
   Please consult the The X.Org Foundation support
   at http://wiki.x.org
   for help.
   [ 17.484] (EE) Please also check the log file at “/var/log/Xorg.0.log” for additional information.
   [ 17.484] (EE)
   [ 17.619] (EE) Server terminated with error (1). Closing log file.

   Reply

   • Thanks for the detailed report and Xorg log, Lorenzo. The backtrace points to a known race condition on Debian Trixie with nvidia-open drivers and kernel modesetting. At first boot, SDDM starts before the NVIDIA DRM render nodes (/dev/dri/renderD128) are fully initialized, causing the modesetting X driver to crash when glamor_init tries to use them. Your workaround of restarting SDDM manually works because by then the render nodes are ready.

     This timing issue affects systems using nvidia-open with DRM modesetting, particularly on dracut-based Debian 13 installations. Two approaches can resolve it:

     Option 1: Add NVIDIA modules to early boot

     Force NVIDIA modules to load during initramfs by adding them to the dracut configuration:

     sudo install -d /etc/dracut.conf.d
     printf '%s\n' 'add_drivers+=" nvidia nvidia_modeset nvidia_uvm nvidia_drm "' | sudo tee /etc/dracut.conf.d/nvidia-modules.conf > /dev/null
     sudo dracut --force

     Option 2: Delay display manager startup

     Create an override to add a delay before SDDM starts, giving the render nodes time to initialize:

     sudo install -d /etc/systemd/system/sddm.service.d
     printf '%s\n' '[Service]' 'ExecStartPre=/bin/sleep 2' | sudo tee /etc/systemd/system/sddm.service.d/nvidia-wait.conf > /dev/null
     sudo systemctl daemon-reload

     Try Option 1 first since it addresses the root cause. The nvidia-open modules initialize faster when loaded early in the boot process rather than on-demand. If Option 1 alone does not resolve it, add Option 2 as a fallback. After either change, reboot and verify that SDDM starts successfully on the first attempt.

     I have added this troubleshooting section to the article under “Xorg Fails on First Boot with DRM Modesetting (Debian 13)” so future readers with the same issue can find it directly. Thanks for the detailed Xorg log, it made pinpointing the race condition much easier.

     Reply

4. The Nvidia APT repo method does not seem to work (anymore?). APT complains about unresolved dependencies (and rightly so!)

   For example I run:
   > sudo apt install nvidia-driver cuda nvidia-settings nvidia-smi

   I get errors:
   Unsatisfied dependencies:
   nvidia-driver-cuda : Conflicts: nvidia-smi
   nvidia-driver-libs : Depends: libnvidia-egl-xcb1 (<= 575.51.03-1) but 1:1.0.1-1 is to be installed
   Depends: libnvidia-egl-xlib1 (<= 575.51.03-1) but 1:1.0.1-1 is to be installed
   Recommends: nvidia-driver-libs:i386 (= 575.51.03-1)
   nvidia-smi : Depends: nvidia-alternative (= 560.35.05-1)
   Depends: libnvidia-ml1 (= 560.35.05-1) but 575.51.03-1 is to be installed

   Indeed if you look at the "nvidia-smi" package in your web browser here:
   https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64/
   There's basically no package since version 560.xx

   Looks like the dependencies on these packages are a giant mess now and not all of them are being generated for all the driver versions being released.

   Reply

   • Thanks for reporting this, arustictop. You’ve identified a legitimate packaging issue with NVIDIA’s CUDA repository where nvidia-smi versions lag behind current driver releases, creating dependency conflicts. This affects Debian 12 and 11 users specifically.

     The conflict happens because nvidia-driver-cuda (part of the full driver stack) conflicts with the standalone nvidia-smi package when you try to install both explicitly. The solution is to avoid listing nvidia-smi separately since it’s already included as a dependency when you install the driver metapackage. Use this command instead:

     sudo apt install nvidia-driver nvidia-settings

     For the proprietary driver variant. If you need the open-source kernel modules, use:

     sudo apt install nvidia-driver nvidia-kernel-open-dkms nvidia-settings

     The nvidia-driver metapackage automatically pulls in nvidia-smi as a dependency at the correct matching version, avoiding the version mismatch you encountered. The article has been updated to reflect this working installation command pattern based on NVIDIA’s official Debian installation guide.

     The libnvidia-egl-xcb1 and libnvidia-egl-xlib1 dependency issues you mentioned stem from Debian’s base packages having newer versions than what the NVIDIA CUDA repository expects. These conflicts typically resolve themselves when you let APT handle dependencies automatically rather than forcing specific package combinations. If you still encounter version conflicts, verify your system is fully updated with sudo apt update && sudo apt upgrade before attempting driver installation.

     For Debian 13 Trixie users: NVIDIA’s CUDA repository currently doesn’t support Debian 13, so you must use Debian’s default repositories instead (Method 1 in the guide). Debian 13 ships driver versions 550.x and 535.x through the standard repositories without these packaging conflicts.

     Reply

5. Hi Joshua, what do you mean by “it is recommended to install all the drivers”? I’ve just installed the “NVIDIA Drivers With Cuda Support (Proprietary)” for my gtx1060 6gb, but are you recommending I also install the opensource cuda support driver too?
   Thanks,
   Tim

   Reply

   • Thanks for the question, Tim. You only need to install ONE driver variant, not both. The GTX 1060 is a Pascal architecture GPU, so you should stick with the proprietary NVIDIA driver you already installed. You’re all set.

     The “recommended to install all drivers” language was unclear and has been removed from the guide. Here’s what actually matters for your GTX 1060:

     • Proprietary driver (what you installed): Best choice for GTX 1060. Mature, stable, full feature support including CUDA for compute workloads.
     • Open-source driver (nvidia-kernel-open-dkms): Alternative option with open kernel modules, but the proprietary variant delivers better performance and stability for Pascal GPUs like yours.

     Installing both simultaneously creates conflicts and serves no purpose. The system uses one driver at a time. The open-source variant targets newer hardware (Turing/Ampere/Ada Lovelace) where NVIDIA invested more optimization effort. For Pascal-generation cards, the proprietary driver remains the recommended choice.

     Your current setup with the proprietary driver and CUDA support is exactly what you need for gaming, rendering, or machine learning workloads on the GTX 1060. No additional driver installation necessary.

     Reply

6. Tried this twice. No success it just errors out on me

   Reply

   • Which part? Got any error logs you can post? This would be helpful.
     Also, your graphics card, system information.

     Reply

     • I have 5090 and installed proxmox and get the error:

       root@pve:~# apt install nvidia-driver nvidia-kernel-open-dkms cuda nvidia-smi nvidia-settings
       Reading package lists… Done
       Building dependency tree… Done
       Reading state information… Done
       Some packages could not be installed. This may mean that you have
       requested an impossible situation or if you are using the unstable
       distribution that some required packages have not yet been created
       or been moved out of Incoming.
       The following information may help to resolve the situation:

       The following packages have unmet dependencies:
       nvidia-driver-cuda : Conflicts: nvidia-smi
       nvidia-driver-libs : Depends: libnvidia-egl-xcb1 (<= 575.51.03-1) but 1:1.0.1-2 is to be installed
       Depends: libnvidia-egl-xlib1 (<= 575.51.03-1) but 1:1.0.1-2 is to be installed
       Recommends: nvidia-driver-libs:i386 (= 575.51.03-1)
       nvidia-smi : Depends: nvidia-alternative (= 560.35.05-1)
       Depends: libnvidia-ml1 (= 560.35.05-1) but 575.51.03-1 is to be installed
       Recommends: nvidia-kernel-dkms (= 560.35.05-1) but it is not installable or
       nvidia-kernel-560.35.05 or
       nvidia-open-kernel-560.35.05 but it is not installable
       E: Unable to correct problems, you have held broken packages.

       Reply

       • Thanks for reporting this, Steven. The RTX 5090 is Blackwell architecture, which requires NVIDIA’s open-source kernel modules exclusively. Your error shows version conflicts because you explicitly installed nvidia-smi as a separate package, which creates mismatches between nvidia-smi 560.x and the driver stack 575.x.

         The nvidia-driver metapackage automatically includes nvidia-smi at the correct matching version, so installing it separately causes the dependency conflicts you are seeing. Additionally, nvidia-driver-cuda explicitly conflicts with standalone nvidia-smi installations.

         Remove the conflicting packages first:

         sudo apt autoremove nvidia-smi nvidia-driver-cuda nvidia-driver-libs --purge

         Update your package cache to reflect the removal:

         sudo apt update

         Install the driver without explicitly specifying nvidia-smi:

         sudo apt install nvidia-driver nvidia-kernel-open-dkms nvidia-settings

         After installation completes, reboot to activate the driver:

         sudo reboot

         Once the system restarts, verify the driver loaded correctly:

         nvidia-smi

         The nvidia-smi binary comes from nvidia-driver automatically, keeping versions synchronized. Proxmox uses its own kernel, so before installation verify your kernel headers match your running kernel with uname -r, then install the corresponding Proxmox kernel headers package (typically pve-headers-$(uname -r)). If conflicts persist, ensure you enabled both contrib and non-free repositories per the guide’s pre-installation steps.

         Reply

7. Hi!
   At the step “Debian 12 Bookworm Import GPG Key for Nvidia” the error occurs “curl: (22) The requested URL returned error: 403
   gpg: no OpenPGP format data found”

   Reply

   • Thanks for reporting this, Zinoviev. The 403 error indicates NVIDIA changed how they distribute their repository GPG key. The direct .pub file download method is no longer working.

     Use this updated method to import the NVIDIA GPG key. First, install the CUDA keyring package which handles the GPG key automatically:

     For Debian 12 Bookworm:

     wget https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64/cuda-keyring_1.1-1_all.deb
     sudo dpkg -i cuda-keyring_1.1-1_all.deb
     sudo apt update

     For Debian 11 Bullseye:

     wget https://developer.download.nvidia.com/compute/cuda/repos/debian11/x86_64/cuda-keyring_1.1-1_all.deb
     sudo dpkg -i cuda-keyring_1.1-1_all.deb
     sudo apt update

     This keyring package installs the GPG key and repository configuration automatically, replacing the manual curl method. After running these commands, proceed with the driver installation steps from the guide. The article has been updated to reflect this change.

     Reply

8. Joshua
   My Debian 12 was updated to nvidia driver 560 which killed it as I was running on 535 quite smoothly can I stop this from happening again .
   Bob

   Reply

   • Thanks for sharing this, Bob. Unexpected driver upgrades breaking a stable setup is exactly what NVIDIA’s version pinning packages prevent. You can lock your system to the 535 driver branch to avoid automatic upgrades to 560 or newer versions.

     First, downgrade back to the 535 driver if you haven’t already:

     sudo apt install nvidia-driver=535.* nvidia-kernel-dkms=535.*

     Then install the pinning package to lock your system to the 535 branch:

     sudo apt install nvidia-driver-pinning-535

     This prevents APT from upgrading to 560 or any newer driver branches while still receiving security updates within the 535.x series. The pinning package creates an APT preference that tells the package manager to stick with 535.

     Verify the pinning is active:

     apt-cache policy nvidia-driver

     You should see the 535 version marked as the candidate even if newer versions exist in the repository. The guide’s “Lock Driver to Specific Version or Branch” section covers this feature in detail for future reference.

     Reply

9. Joshua
   I had driver Linux-x86_64-535.216.01 working fine on my GTX1050 Ti , an update pushed the driver to 560 which does not work I have to start all over !
   Bob

   Reply

10. nvidia-detect was not available within non-free-firmware. I had to add “non-free” to make it visible to `sudo apt install`.
    So, here is the entire command I propose to modify the corresponding one in this tutorial :
    `sudo add-apt-repository contrib non-free-firmware non-free`

    Reply

    • Thanks for the feedback Thibault, I’ll make a point to update the article.

      Reply

11. Thank you so much for this tutorial and keeping it up-to-date! One problem though… The 32-bit support is at version 555, while the 64-bit support is at 560. Is there coming an update for it, or can I install 64-bit version 555?

    Reply

    • Thanks for the kind words, Arthur. The version mismatch between 64-bit drivers (560) and 32-bit libraries (555) was temporary and happened when NVIDIA released new driver versions before the corresponding 32-bit packages finished building and testing.

      Your system worked fine with this mismatch for most applications. The 32-bit libraries (nvidia-driver-libs:i386) provided compatibility for older 32-bit games and applications, while your primary 64-bit driver handled all GPU operations. The version difference didn’t affect stability or performance.

      The 32-bit packages typically caught up within a few days to weeks. You could have either waited for the 555 32-bit libraries to update to 560, or downgraded your 64-bit driver to 555 if you needed exact version matching:

      sudo apt install nvidia-driver=555.* nvidia-kernel-dkms=555.*

      By now, the 32-bit packages have updated to match the 64-bit version through regular system updates. This type of temporary version lag is normal in NVIDIA’s release cycle and resolves itself automatically.

      Reply

12. Hello and thank you for the tutorial. Very well written and easy to follow.

    Everything works well, but unfortunately, after rebooting, the system gets stuck on the login screen (keeps returning to it).
    The system is a fresh Debian 12 KDE with Nvidia drivers including Cuda and Wayland. It’s a 2-monitor setup with a GTX 2080.

    When I switch to X11 at login, I can sign in. However, the graphics are unusual: multiple backgrounds and windows on both monitors. I can open a CLI, the keyboard is QWERTY instead of QWERTZ. But that’s manageable.
    As a Linux newbie, I’m a bit lost and hoping for some help here. Unfortunately, I couldn’t find anything suitable online 🙁

    Best regards,
    Elmar

    Reply

    • Thanks for the detailed report, Elmar. The login loop on Wayland with your GTX 2080 indicated missing kernel modesetting configuration, which was required for NVIDIA Wayland support. The unusual multi-monitor behavior in X11 suggested display configuration conflicts.

      First, verify kernel modesetting was enabled for NVIDIA:

      cat /sys/module/nvidia_drm/parameters/modeset

      If this showed N, enable it with:

      echo "options nvidia-drm modeset=1" | sudo tee /etc/modprobe.d/nvidia-options.conf
      sudo update-initramfs -u
      sudo reboot

      Additionally, enable NVIDIA power management for proper suspend/resume and Wayland session availability:

      echo "options nvidia NVreg_PreserveVideoMemoryAllocations=1" | sudo tee /etc/modprobe.d/nvidia-power-management.conf
      sudo apt install nvidia-suspend-common
      sudo systemctl enable nvidia-suspend.service nvidia-hibernate.service nvidia-resume.service
      sudo reboot

      These steps are detailed in the guide’s “Configure Wayland Support” section. The keyboard layout reverting to QWERTY suggested KDE wasn’t loading your user session properly due to the Wayland initialization failure. Once modesetting was configured, both Wayland sessions and proper multi-monitor X11 behavior should have worked correctly.

      Reply

      • Hello Joshua,

        Thank you very much for your tips. I have now tried several fresh installations and installed the drivers both via the repository using your method and directly as *.run files. The error remains the same. I’m now going to check under udev.d to see if all the rules are present (a tip from another forum pointed to a rule that is blocking the Nvidia driver). Setting up a new system doesn’t take long.

        Under X11, the NVIDIA driver is present, but the regional settings are disabled. This has set the keyboard layout to English, and I cannot activate German or add the language, even though it was available before.
        Wayland is important to me because I have monitors of different sizes, all of which can do 4k. I need to be able to scale them individually; otherwise, I can’t use the setup for graphics and video. I need the NVIDIA drivers to make full use of Davinci Resolve.

        I will follow your tips and report back.

        Best regards,
        Elmar

        Reply

        • Thanks for the detailed follow-up, Elmar. The fact that the issue persisted across multiple fresh installations and both APT and runfile methods pointed to either a configuration conflict or hardware-specific quirk with your multi-monitor 4K setup rather than installation problems.

          The udev rules investigation was a good direction. Check if any custom udev rules were interfering with NVIDIA device initialization:

          ls -la /etc/udev/rules.d/ | grep nvidia
          ls -la /lib/udev/rules.d/ | grep nvidia

          For the KDE regional settings being disabled under X11, this typically indicated the plasma-desktop session wasn’t loading your user configuration properly. Verify your display manager configuration recognized the NVIDIA driver:

          cat /etc/sddm.conf.d/kde_settings.conf

          For your DaVinci Resolve workflow with mixed 4K monitors requiring per-display scaling, Wayland was indeed the right choice. The kernel modesetting and power management configuration from the previous reply should have enabled proper Wayland sessions. Additionally, verify your monitors were detected correctly:

          xrandr --listproviders
          nvidia-smi

          If you discovered specific udev rules or configuration files causing conflicts, sharing those details would have helped identify the root cause for your particular hardware combination.

          Reply

      • Hi, Joshua,

        Having an issue when I use Method 2.

        After following the steps and arriving at:

        `sudo apt install nvidia-driver nvidia-smi nvidia-settings`

        I get an error claiming the installation failed due to unmet dependencies:

        `nvidia-alternative : Depends: glx-alternative-nvidia (>= 1.2) but it is not installable`
        `E: Unable to correct problems, you have held broken packages.`

        This is on a fresh install of Debian 12. Any ideas?

        Reply

        • I have a similar error!

          Reply

        • Hello Joshua!
          I have an issue when I use Method 2 the similar like Mat.
          How you can see on Nvidia’s website:
          https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64/
          the latest version of nvidia-driver, nvidia-msi and nvidia-settings are 560.35.03-1.

          But when I am using:
          echo ‘deb [signed-by=/usr/share/keyrings/nvidia-drivers.gpg] https://developer.download.nvidia.com/compute/cuda/repos/debian12/x86_64/ /’ | sudo tee /etc/apt/sources.list.d/nvidia-drivers.list,
          and after this:
          apt search nvidia-driver,
          apt search nvidia-settinds,
          apt search nvidia-smi,
          I see that latest version of nvidia-driver and nvidia-settings are: 565.57.01-1 amd64,
          and latest version of nvidia-smi is: 560.35.03-1 amd64.
          565.57.01-1 is beta-version (how you can see on Vnidia website).
          And when I try:
          apt install nvidia-driver nvidia-smi nvidia-settings,
          I receive error:
          Packages with unsatisfied dependencies:
          nvidia-smi : Dependencies: nvidia-alternative (= 560.35.03-1)
          Dependencies: libnvidia-ml1 (= 560.35.03-1) but 565.57.01-1 will be installed
          Recommends: nvidia-kernel-dkms (= 560.35.03-1) but 565.57.01-1 will be installed or
          nvidia-kernel-560.35.03 or
          nvidia-open-kernel-560.35.03 but it cannot be installed
          E: Unable to troubleshoot, you have broken fixed packages.

          P.S. I used your tutorial long time. But few days ago I received update 565.57.01-1 for nvidia and all broked.
          I purged nvidia and tried install again like you wrote. And now I receive error.
          Your Method 1 is work. Installing *.run-file from Nvidia work. But Method 2 not work.

          Please, tell me how I can fix this, because Method 2 is the best.
          Thank you!

          Reply

          • Thanks for the detailed report, conscious. You identified exactly what was happening: NVIDIA pushed beta driver 565.57.01 to their CUDA repository before the supporting packages (nvidia-smi 560.35.03) were updated to match, creating version conflicts.

            The explicit nvidia-smi installation caused this issue. The nvidia-driver metapackage automatically includes nvidia-smi as a dependency at the correct matching version. Installing it separately forced APT to resolve conflicting version requirements between the beta driver and stable nvidia-smi.

            Remove nvidia-smi from the installation command:

            sudo apt install nvidia-driver nvidia-settings

            If you wanted to avoid beta drivers entirely and stick with stable 560.x, pin the driver to that specific version:

            sudo apt install nvidia-driver=560.* nvidia-settings=560.*

            Then install the version pinning package to prevent future beta upgrades:

            sudo apt install nvidia-driver-pinning-560

            The guide has been updated to remove the explicit nvidia-smi installation, which was causing these version conflicts. APT handles nvidia-smi automatically when you install nvidia-driver, ensuring version consistency.

        • Thanks for reporting this, Mat. The glx-alternative-nvidia dependency error indicated a conflict between NVIDIA’s CUDA repository packages and Debian’s default repository packages. This typically happened when package priorities weren’t set correctly or when mixing installation methods.

          First, verify which repositories were providing NVIDIA packages:

          apt-cache policy nvidia-driver glx-alternative-nvidia

          The nvidia-smi package should not have been installed explicitly, as it’s automatically included as a dependency of nvidia-driver. Installing it separately could have caused version conflicts. The correct command was:

          sudo apt install nvidia-driver nvidia-settings

          To resolve the dependency conflict, remove any partially installed NVIDIA packages and reinstall cleanly:

          sudo apt autoremove --purge nvidia*
          sudo apt update
          sudo apt install nvidia-driver nvidia-settings

          If the issue persisted, ensuring Debian’s contrib repository was enabled often resolved the glx-alternative-nvidia dependency:

          sudo add-apt-repository contrib
          sudo apt update
          sudo apt install nvidia-driver nvidia-settings

          The guide has been updated to remove the explicit nvidia-smi installation, as it’s automatically provided by nvidia-driver.

          Reply

13. How do I remove the NVIDIA APT so that I can install the default one?

    Reply

    • Never mind. I figured it out.

      Reply

    • Thanks for asking, Chris. To switch from the NVIDIA CUDA repository back to Debian’s default repository, remove the NVIDIA repository configuration and purge the installed drivers:

      sudo rm /etc/apt/sources.list.d/nvidia-drivers.list
      sudo rm /usr/share/keyrings/nvidia-drivers.gpg
      sudo apt update
      sudo apt autoremove --purge nvidia*

      Then install drivers from Debian’s default repository following Method 1 in the guide:

      sudo apt update
      sudo apt install nvidia-driver firmware-misc-nonfree
      sudo reboot

      This removed the NVIDIA CUDA repository, cleaned up any CUDA-sourced driver packages, and installed the stable Debian-tested drivers instead. The Debian repository provides more conservative driver versions with thorough distribution testing.

      Reply

14. Thanks, got me up to 545.23.08 on debain 12 sadly I think 550.40+ is required for the new 6GB 3050

    Detected NVIDIA GPUs:
    01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA107 [GeForce RTX 3050 6GB] [10de:2584] (rev a1)

    Checking card: NVIDIA Corporation GA107 [GeForce RTX 3050 6GB] (rev a1)
    Uh oh. Your card is not supported by any driver version up to 545.23.08.
    A newer driver may add support for your card.
    Newer driver releases may be available in backports, unstable or experimental.

    Guess I am risking the vendor run/installer

    Reply

    • Just in case anyone with the same card finds this comment.

      I can confirm I got the 550.40.x drivers directly from the nvidia run script on the nvidia website installed and they work fine so far on Debian 12

      Reply

      • Thanks, Billy, for posting the feedback.

        Currently I have this as a method for Fedora Nvidia Drivers installation, as currently Nvidia and Fedora from 38 onwards is a complete mess. I will add the same method for Debian as well as an optional back up method if all else fails.

        Reply

15. What driver version from Nvidia APT PPA will work with the latest stable Debian kernel 6.1.0-18 ?

    For example version 535.104.12 does not work.

    Reply

16. It worked perfectly. I’ve chosen the option “Install NVIDIA Drivers Without Cuda Support (Proprietary)”.
    Normally I would never leave comment on a website/blog/forum. You’ve helped me we with a problem that I have been struggling for over 5 years, now I can finally connect to a monitor with HDMI. None of the other solutions provided on the internet worked for me (Connect Debian to external monitors, while having a hybrid GPU (Nvidia/Intel)). The only resort I had, was to choose Linux Mint.

    Many thanks, keep this good work alive!

    Reply

    • Thanks Anon for the feedback, glad it worked out. 🙂

      Reply

17. Thank you for the tutorial. It helps a lot. The only thing missing is the fact that nvidia driver may not work properly if you have secure boot enabled in your bios settings.

    Reply

18. Thank you very much. Now everything working good. Because nvidia-driver from Debian repository not working good.
    Thank you again!

    Reply