How to Install NVIDIA Drivers on Debian (13, 12, 11)

39 thoughts on “How to Install NVIDIA Drivers on Debian (13, 12, 11)”

1. 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:

     echo 'add_drivers+=" nvidia nvidia_modeset nvidia_uvm nvidia_drm "' | sudo tee /etc/dracut.conf.d/nvidia-modules.conf
     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 mkdir -p /etc/systemd/system/sddm.service.d
     echo '[Service]
     ExecStartPre=/bin/sleep 2' | sudo tee /etc/systemd/system/sddm.service.d/nvidia-wait.conf
     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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

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

    Reply