Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Gray]

Dear Maintainer

I was able to get nvidia fully installed on my hardware  - however I 
found that using the latest kernel 7.0.12 results in a black screen and 
no ability to go to change to the command line as my PC seems to lock up 
using nvidia with that kernel.


I AM able to boot to a full KDE plasma GUI using the previous kernel.

My hardware - using 7.0.10 (7.0.12 was fine until I installed the nvidia 
drivers):


Operating System: Debian GNU/Linux forky/sid
KDE Plasma Version: 6.6.5
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 7.0.10+deb14-amd64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-4790 CPU @ 3.60GHz
Memory: 16 GiB of RAM (14.6 GiB usable)
Graphics Processor 1: NVIDIA GeForce GTX 1060 3GB
Graphics Processor 2: Intel® HD Graphics 4600
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B85M-HD3

Please suggest how I can supply more info to help with this.

Best wishes
Gray

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Tim McConnell]

Dear Maintainer,
Just to let you know, I can currently install the package but then if I
reboot then the computer has no GUI.
current information:
lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce
GTX 1080] (rev a1)
02:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce
GTX 1080] (rev a1)

uname -a
Linux debianTim 7.0.12+deb14.1-amd64 #1 SMP PREEMPT_DYNAMIC Debian
7.0.12-2 (2026-06-12) x86_64 GNU/Linux

 
-- 
Tim McConnell 

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Gray]

Hi

Firstly thank you very much for these instructions. I now have nvidia 
580 installed and can use my nvidia gtx 1060 to game again.


I did have one glitch however. It seems that sddm tries to start before 
the display is ready, which did not occur with the Noveau driver, so I 
have to assume that the nvidia drivers are just a bit slower to load.


The fix I found is to force the sddm service to wait a bit:

sudo systemctl edit sddm.service

and add this in:

[Service]
ExecStartPre=/usr/bin/sleep 10

While I have no idea what the ramifications are of this, it got me back 
into the GUI and I can see how the games run in Steam :)


Best wishes
Gray

On Mon, 25 May 2026 01:50:18 -0500 Nate McKay 
 wrote:

> Hello,
>
> I have an older card [GeForce GTX 1050 Ti] that is no longer supported
> with the 590 and 595 drivers as was noted by Forrest Cahoon. The 580
> series still does support these older cards (maybe yours is one). The
> nVidia repo referenced above no longer has the 580 version drivers
> available, but I found them referenced here:
>
> 
https://developer.nvidia.com/datacenter-driver-580-downloads?target_os=Linux&target_arch=x86_64&Distribution=Debian&target_version=12&target_type=deb_local

>
> This installs a local repo on your machine containing the 580.159.04
> series drivers and userspace libraries that can then be
> installed/upgraded by apt.
>
> #Installation Instructions:
> wget 
https://developer.download.nvidia.com/compute/nvidia-driver/580.159.04/local_installers/nvidia-driver-local-repo-debian12-580.159.04_1.0-1_amd64.deb

> sudo dpkg -i nvidia-driver-local-repo-debian12-580.159.04_1.0-1_amd64.deb
> sudo cp 
/var/nvidia-driver-local-repo-debian12-580.159.04/nvidia-driver-*-keyring.gpg

> /usr/share/keyrings/
> sudo apt-get update
>
> #NVIDIA Driver Instructions (choose one option)
> #To install the open kernel module flavor:
> #sudo apt-get install -y nvidia-open-580
> #To install the proprietary kernel module flavor:
> sudo apt-get install -y cuda-drivers-580
> #To switch between NVIDIA Driver kernel module flavors see here:
> 
#https://docs.nvidia.com/datacenter/tesla/driver-installation-guide/#switching-between-driver-module-flavors

>
> I had the main NVIDIA repo added at the time (as you do), I tested
> this and needed to pin the nvidia-driver and all relevant dependencies
> to 580.159.04-1, which you are probably going to need to do anyway if
> your card is no longer supported from 590 onward. I have attached the
> pin files for your convenience (the amd64 one I built out by hand, the
> i386 version uses wildcards once I knew what all the deps were -
> sorry, I was tired).
>
> With the 580 repo package and pins set up, 'sudo apt-get install -y
> cuda-drivers-580' ran normally and set up the 580 driver DKMS for all
> installed kernels, including the 7.0.x versions I had installed. I saw
> somewhere the 580 driver was updated against linux 7.1.x at least.
>
> $ apt list --installed | grep -i nvidia
> firmware-nvidia-graphics/unstable,unstable,now 20260410-1 all [installed]
> firmware-nvidia-gsp/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libegl-nvidia0/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libegl-nvidia0/unknown,now 580.159.04-1 i386 [installed,automatic]
> libgles-nvidia1/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libgles-nvidia1/unknown,now 580.159.04-1 i386 [installed,automatic]
> libgles-nvidia2/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libgles-nvidia2/unknown,now 580.159.04-1 i386 [installed,automatic]
> libglx-nvidia0/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libglx-nvidia0/unknown,now 580.159.04-1 i386 [installed,automatic]
> libnvidia-allocator1/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libnvidia-allocator1/unknown,now 580.159.04-1 i386 [installed,automatic]
> libnvidia-api1/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libnvidia-cfg1/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libnvidia-egl-gbm1/unknown,now 1.1.3-1 amd64 [installed,automatic]
> libnvidia-egl-gbm1/unknown,now 1.1.3-1 i386 [installed,automatic]
> libnvidia-egl-wayland1/unknown,now 1:1.1.21-1 amd64 [installed,automatic]

--
15 Tweed Terrace
Stanley
County Durham
DH9 6JQ
07732 508799
---
Running Microsoft's "System Idle Process" will never
help cure cancer, AIDS nor Alzheimer's. But running
Rosetta@home or World Community Grid just might.
https://boinc.bakerlab.org/rosetta/
https://www.worldcommunitygrid.org/

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Nate McKay]

I remembered moments after I sent this that the repo contains a couple
of pinning debs you can just install before 'sudo apt-get install -y
cuda-drivers-580' to configure pinning for 580, but I didn't test it
at the time.

Thanks,
Nathan

On Mon, May 25, 2026 at 1:50 AM Nate McKay
 wrote:
>
> Hello,
>
> I have an older card [GeForce GTX 1050 Ti] that is no longer supported
> with the 590 and 595 drivers as was noted by Forrest Cahoon. The 580
> series still does support these older cards (maybe yours is one). The
> nVidia repo referenced above no longer has the 580 version drivers
> available, but I found them referenced here:
>
> https://developer.nvidia.com/datacenter-driver-580-downloads?target_os=Linux&target_arch=x86_64&Distribution=Debian&target_version=12&target_type=deb_local
>
> This installs a local repo on your machine containing the 580.159.04
> series drivers and userspace libraries that can then be
> installed/upgraded by apt.
>
> #Installation Instructions:
> wget 
> https://developer.download.nvidia.com/compute/nvidia-driver/580.159.04/local_installers/nvidia-driver-local-repo-debian12-580.159.04_1.0-1_amd64.deb
> sudo dpkg -i nvidia-driver-local-repo-debian12-580.159.04_1.0-1_amd64.deb
> sudo cp 
> /var/nvidia-driver-local-repo-debian12-580.159.04/nvidia-driver-*-keyring.gpg
> /usr/share/keyrings/
> sudo apt-get update
>
> #NVIDIA Driver Instructions (choose one option)
> #To install the open kernel module flavor:
> #sudo apt-get install -y nvidia-open-580
> #To install the proprietary kernel module flavor:
> sudo apt-get install -y cuda-drivers-580
> #To switch between NVIDIA Driver kernel module flavors see here:
> #https://docs.nvidia.com/datacenter/tesla/driver-installation-guide/#switching-between-driver-module-flavors
>
> I had the main NVIDIA repo added at the time (as you do), I tested
> this and needed to pin the nvidia-driver and all relevant dependencies
> to 580.159.04-1, which you are probably going to need to do anyway if
> your card is no longer supported from 590 onward. I have attached the
> pin files for your convenience (the amd64 one I built out by hand, the
> i386 version uses wildcards once I knew what all the deps were -
> sorry, I was tired).
>
> With the 580 repo package and pins set up, 'sudo apt-get install -y
> cuda-drivers-580' ran normally and set up the 580 driver DKMS for all
> installed kernels, including the 7.0.x versions I had installed. I saw
> somewhere the 580 driver was updated against linux 7.1.x at least.
>
> $ apt list --installed | grep -i nvidia
> firmware-nvidia-graphics/unstable,unstable,now 20260410-1 all [installed]
> firmware-nvidia-gsp/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libegl-nvidia0/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libegl-nvidia0/unknown,now 580.159.04-1 i386 [installed,automatic]
> libgles-nvidia1/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libgles-nvidia1/unknown,now 580.159.04-1 i386 [installed,automatic]
> libgles-nvidia2/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libgles-nvidia2/unknown,now 580.159.04-1 i386 [installed,automatic]
> libglx-nvidia0/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libglx-nvidia0/unknown,now 580.159.04-1 i386 [installed,automatic]
> libnvidia-allocator1/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libnvidia-allocator1/unknown,now 580.159.04-1 i386 [installed,automatic]
> libnvidia-api1/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libnvidia-cfg1/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libnvidia-egl-gbm1/unknown,now 1.1.3-1 amd64 [installed,automatic]
> libnvidia-egl-gbm1/unknown,now 1.1.3-1 i386 [installed,automatic]
> libnvidia-egl-wayland1/unknown,now 1:1.1.21-1 amd64 [installed,automatic]
> libnvidia-egl-wayland1/unknown,now 1:1.1.21-1 i386 [installed,automatic]
> libnvidia-egl-xcb1/unknown,now 1:1.0.5-1 amd64 [installed,automatic]
> libnvidia-egl-xcb1/unknown,now 1:1.0.5-1 i386 [installed,automatic]
> libnvidia-egl-xlib1/unknown,now 1:1.0.5-1 amd64 [installed,automatic]
> libnvidia-egl-xlib1/unknown,now 1:1.0.5-1 i386 [installed,automatic]
> libnvidia-eglcore/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libnvidia-eglcore/unknown,now 580.159.04-1 i386 [installed,automatic]
> libnvidia-encode1/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libnvidia-fbc1/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libnvidia-glcore/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libnvidia-glcore/unknown,now 580.159.04-1 i386 [installed,automatic]
> libnvidia-glvkspirv/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libnvidia-glvkspirv/unknown,now 580.159.04-1 i386 [installed,automatic]
> libnvidia-gpucomp/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libnvidia-gpucomp/unknown,now 580.159.04-1 i386 [installed,automatic]
> libnvidia-ml1/unknown,now 580.159.04-1 amd64 [installed,automatic]
> libnvidia-ml1/unknown,now 580.159.04-1 i386 [installed,automatic]
> libnvidia

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Nate McKay]

Hello,

I have an older card [GeForce GTX 1050 Ti] that is no longer supported
with the 590 and 595 drivers as was noted by Forrest Cahoon. The 580
series still does support these older cards (maybe yours is one). The
nVidia repo referenced above no longer has the 580 version drivers
available, but I found them referenced here:

https://developer.nvidia.com/datacenter-driver-580-downloads?target_os=Linux&target_arch=x86_64&Distribution=Debian&target_version=12&target_type=deb_local

This installs a local repo on your machine containing the 580.159.04
series drivers and userspace libraries that can then be
installed/upgraded by apt.

#Installation Instructions:
wget 
https://developer.download.nvidia.com/compute/nvidia-driver/580.159.04/local_installers/nvidia-driver-local-repo-debian12-580.159.04_1.0-1_amd64.deb
sudo dpkg -i nvidia-driver-local-repo-debian12-580.159.04_1.0-1_amd64.deb
sudo cp 
/var/nvidia-driver-local-repo-debian12-580.159.04/nvidia-driver-*-keyring.gpg
/usr/share/keyrings/
sudo apt-get update

#NVIDIA Driver Instructions (choose one option)
#To install the open kernel module flavor:
#sudo apt-get install -y nvidia-open-580
#To install the proprietary kernel module flavor:
sudo apt-get install -y cuda-drivers-580
#To switch between NVIDIA Driver kernel module flavors see here:
#https://docs.nvidia.com/datacenter/tesla/driver-installation-guide/#switching-between-driver-module-flavors

I had the main NVIDIA repo added at the time (as you do), I tested
this and needed to pin the nvidia-driver and all relevant dependencies
to 580.159.04-1, which you are probably going to need to do anyway if
your card is no longer supported from 590 onward. I have attached the
pin files for your convenience (the amd64 one I built out by hand, the
i386 version uses wildcards once I knew what all the deps were -
sorry, I was tired).

With the 580 repo package and pins set up, 'sudo apt-get install -y
cuda-drivers-580' ran normally and set up the 580 driver DKMS for all
installed kernels, including the 7.0.x versions I had installed. I saw
somewhere the 580 driver was updated against linux 7.1.x at least.

$ apt list --installed | grep -i nvidia
firmware-nvidia-graphics/unstable,unstable,now 20260410-1 all [installed]
firmware-nvidia-gsp/unknown,now 580.159.04-1 amd64 [installed,automatic]
libegl-nvidia0/unknown,now 580.159.04-1 amd64 [installed,automatic]
libegl-nvidia0/unknown,now 580.159.04-1 i386 [installed,automatic]
libgles-nvidia1/unknown,now 580.159.04-1 amd64 [installed,automatic]
libgles-nvidia1/unknown,now 580.159.04-1 i386 [installed,automatic]
libgles-nvidia2/unknown,now 580.159.04-1 amd64 [installed,automatic]
libgles-nvidia2/unknown,now 580.159.04-1 i386 [installed,automatic]
libglx-nvidia0/unknown,now 580.159.04-1 amd64 [installed,automatic]
libglx-nvidia0/unknown,now 580.159.04-1 i386 [installed,automatic]
libnvidia-allocator1/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-allocator1/unknown,now 580.159.04-1 i386 [installed,automatic]
libnvidia-api1/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-cfg1/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-egl-gbm1/unknown,now 1.1.3-1 amd64 [installed,automatic]
libnvidia-egl-gbm1/unknown,now 1.1.3-1 i386 [installed,automatic]
libnvidia-egl-wayland1/unknown,now 1:1.1.21-1 amd64 [installed,automatic]
libnvidia-egl-wayland1/unknown,now 1:1.1.21-1 i386 [installed,automatic]
libnvidia-egl-xcb1/unknown,now 1:1.0.5-1 amd64 [installed,automatic]
libnvidia-egl-xcb1/unknown,now 1:1.0.5-1 i386 [installed,automatic]
libnvidia-egl-xlib1/unknown,now 1:1.0.5-1 amd64 [installed,automatic]
libnvidia-egl-xlib1/unknown,now 1:1.0.5-1 i386 [installed,automatic]
libnvidia-eglcore/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-eglcore/unknown,now 580.159.04-1 i386 [installed,automatic]
libnvidia-encode1/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-fbc1/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-glcore/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-glcore/unknown,now 580.159.04-1 i386 [installed,automatic]
libnvidia-glvkspirv/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-glvkspirv/unknown,now 580.159.04-1 i386 [installed,automatic]
libnvidia-gpucomp/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-gpucomp/unknown,now 580.159.04-1 i386 [installed,automatic]
libnvidia-ml1/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-ml1/unknown,now 580.159.04-1 i386 [installed,automatic]
libnvidia-ngx1/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-nvvm4/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-nvvm704/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-opticalflow1/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-pkcs11-openssl3/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-present/unknown,now 580.159.04-1 amd64 [installed,automatic]
libnvidia-ptxjitcom

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Tim McConnell]

Package: nvidia-kernel-dkms
Version: 595.71.05-1
Followup-For: Bug #1135362
X-Debbugs-Cc: tmcconnell...@gmail.com
Control: tags -1 ftbfs

Dear Maintainer,

I followed these steps:
1.ran $ wget
https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/cuda-
keyring_1.1-1_all.deb
2. Then ran  dpkg -i /path/to/cuda-keyring_1.1-1_all.deb
3. Then ran apt update && apt upgrade
and it installed both just fine. HOWEVER the drivers are not recognized, if I
run
nvidia-smiNVIDIA-SMI has failed because it couldn't communicate with the
NVIDIA driver. Make sure that the latest NVIDIA driver is installed and
running.
dpkg -l
rc  nvidia-alternative550.163.01-5
amd64allows the selection of NVIDIA as GLX provider
ii  nvidia-driver 595.71.05-1
amd64NVIDIA metapackage
ii  nvidia-driver-cuda595.71.05-1
amd64NVIDIA driver CUDA integration components
ii  nvidia-driver-libs:amd64  595.71.05-1
amd64NVIDIA metapackage (OpenGL/GLX/EGL/GLES libraries)
ii  nvidia-egl-icd595.71.05-1
amd64NVIDIA EGL installable client driver (ICD)
rc  nvidia-installer-cleanup  20240109+1
amd64cleanup after driver installation with the nvidia-installer
rc  nvidia-kernel-common  20240109+1
amd64NVIDIA binary kernel module support files
ii  nvidia-kernel-dkms595.71.05-1
amd64NVIDIA binary kernel module DKMS source
ii  nvidia-kernel-support 595.71.05-1
amd64NVIDIA binary kernel module support files
ii  nvidia-modprobe   595.71.05-1
amd64utility to load NVIDIA kernel modules and create device nodes
ii  nvidia-opencl-icd:amd64   595.71.05-1
amd64NVIDIA OpenCL installable client driver (ICD)
ii  nvidia-persistenced   595.71.05-1
amd64daemon to maintain persistent software state in the NVIDIA driver
ii  nvidia-settings   595.71.05-1
amd64Tool for configuring the NVIDIA graphics driver
rc  nvidia-support20240109+1
amd64NVIDIA binary graphics driver support files
ii  nvidia-vdpau-driver:amd64 595.71.05-1
amd64Video Decode and Presentation API for Unix - NVIDIA driver
ii  nvidia-vulkan-icd:amd64   595.71.05-1
amd64NVIDIA Vulkan installable client driver (ICD)
ii  nvidia-xconfig

lspci | grep VGA 
01:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce GTX 1080]
(rev a1) 02:00.0 VGA compatible controller: NVIDIA Corporation GP104 [GeForce
GTX 1080] (rev a1)

To ensure DKMS and the nvidia driver installed I ran:
apt install nvidia-kernel-dkms nvidia-driver
nvidia-kernel-dkms is already the newest version (595.71.05-1).
nvidia-driver is already the newest version (595.71.05-1).
Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

So it appears the driver was installed but isn't being recognised. Is there an
ETA when a working version will be available?


-- System Information:
Debian Release: forky/sid
Architecture: amd64 (x86_64)

Kernel: Linux 7.0.7+deb14-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nvidia-kernel-dkms depends on:
ii  dkms   3.4.0-1
ii  firmware-nvidia-gsp [firmware-nvidia-gsp]  595.71.05-1
ii  nvidia-kernel-support  595.71.05-1

Versions of packages nvidia-kernel-dkms recommends:
ii  nvidia-driver   595.71.05-1
ii  nvidia-driver-cuda  595.71.05-1

nvidia-kernel-dkms suggests no packages.

-- no debconf information

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[arizona.rover]

Is anbe OK? I can't find any sign of activity from him since March.

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Forrest Cahoon]

Note that this fix won't work for everyone as Nvidia dropped support for a
bunch of older GPUs with version 590. I used to use the Nvidia repo, but I
had to go back to the Debian repo after my GTX-1060 stopped working.

I can't find the official Nvidia notice about this but here's an article
about it:
https://www.tomshardware.com/tech-industry/geforce-590-driver-branch-is-the-first-without-feature-support-for-gtx-9-and-10-series-gpus-linux-release-marks-the-end-of-the-line-for-graphics-cards-that-defined-an-era

I used François Gannaz's patch on my sid system and that fixed my problem.

On Mon, May 18, 2026 at 9:47 PM Thomas More  wrote:

> Package: nvidia-kernel-dkms
> Followup-For: Bug #1135362
> X-Debbugs-Cc: debian-am...@lists.debian.org, deb...@gilead.dev
> User: debian-am...@lists.debian.org
> Usertags: amd64
> Control: tags -1 ftbfs
>
> On Mon, 18 May 2026 17:24:14 +0200 (CEST) Giacomo Mulas
>  wrote:
>
> ...
>
> > it appears that the latest git version of at least the open version of
> the
> > nvidia kernel module on github (595.71.05) is compatible with 7.0.x
> kernels.
> > Since usually the closed version is aligned, at least in terms of kernel
> > interfaces, this may be the case for that as well. Would it be feasible
> to
> > pull these versions (or a somewhat previous one known to be compatible
> with
> > new kernels) at least in experimental, even without letting get into sid
> or
> > testing? This would provide at least a partial working alternative to
> keep
> > kernel updates on hold for people depending on GPU offloading support on
> > nvidia.
>
> It turns out that it's actually quite easy to install Debian-packaged
> versions of the latest drivers straight from upstream:
>
> https://developer.nvidia.com/cuda-downloads
>
> https://old.reddit.com/r/debian/comments/1jyzgrx/the_correct_way_to_install_newer_nvidia_drivers/
>
> For Debian unstable on amd64, all I had to do was basically:
>
> $ wget
> https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/cuda-keyring_1.1-1_all.deb
> # dpkg -i /path/to/cuda-keyring_1.1-1_all.deb # this installs a keyring
> and adds a repository
> # apt update && apt upgrade
>
> and voila - 595.71.05 built fine against 7.0.7+deb14-amd64. I rebooted, and
> now I'm successfully running 595.71.05 (I haven't yet tested extensively).
>
> -- System Information:
> Debian Release: forky/sid
>   APT prefers oldstable-security
>   APT policy: (500, 'oldstable-security'), (500, 'unstable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 7.0.7+deb14-amd64 (SMP w/16 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages nvidia-kernel-dkms depends on:
> ii  dkms   3.4.0-1
> ii  firmware-nvidia-gsp [firmware-nvidia-gsp]  595.71.05-1
> ii  nvidia-kernel-support  595.71.05-1
>
> Versions of packages nvidia-kernel-dkms recommends:
> ii  nvidia-driver  595.71.05-1
>
> nvidia-kernel-dkms suggests no packages.
>
> -- debconf-show failed
>
> --
> To unsubscribe, send mail to 1135362-unsubscr...@bugs.debian.org.
>

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Thomas More]

Package: nvidia-kernel-dkms
Followup-For: Bug #1135362
X-Debbugs-Cc: debian-am...@lists.debian.org, deb...@gilead.dev
User: debian-am...@lists.debian.org
Usertags: amd64
Control: tags -1 ftbfs

On Mon, 18 May 2026 17:24:14 +0200 (CEST) Giacomo Mulas
 wrote:

...

> it appears that the latest git version of at least the open version of the
> nvidia kernel module on github (595.71.05) is compatible with 7.0.x kernels.
> Since usually the closed version is aligned, at least in terms of kernel
> interfaces, this may be the case for that as well. Would it be feasible to
> pull these versions (or a somewhat previous one known to be compatible with
> new kernels) at least in experimental, even without letting get into sid or
> testing? This would provide at least a partial working alternative to keep
> kernel updates on hold for people depending on GPU offloading support on 
> nvidia.

It turns out that it's actually quite easy to install Debian-packaged
versions of the latest drivers straight from upstream:

https://developer.nvidia.com/cuda-downloads
https://old.reddit.com/r/debian/comments/1jyzgrx/the_correct_way_to_install_newer_nvidia_drivers/

For Debian unstable on amd64, all I had to do was basically:

$ wget 
https://developer.download.nvidia.com/compute/cuda/repos/debian13/x86_64/cuda-keyring_1.1-1_all.deb
# dpkg -i /path/to/cuda-keyring_1.1-1_all.deb # this installs a keyring and 
adds a repository
# apt update && apt upgrade

and voila - 595.71.05 built fine against 7.0.7+deb14-amd64. I rebooted, and
now I'm successfully running 595.71.05 (I haven't yet tested extensively).

-- System Information:
Debian Release: forky/sid
  APT prefers oldstable-security
  APT policy: (500, 'oldstable-security'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 7.0.7+deb14-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nvidia-kernel-dkms depends on:
ii  dkms   3.4.0-1
ii  firmware-nvidia-gsp [firmware-nvidia-gsp]  595.71.05-1
ii  nvidia-kernel-support  595.71.05-1

Versions of packages nvidia-kernel-dkms recommends:
ii  nvidia-driver  595.71.05-1

nvidia-kernel-dkms suggests no packages.

-- debconf-show failed

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Julian Gilbey]

Thanks Jonas!

Best wishes,

   Julian

On Tue, May 12, 2026 at 02:16:04PM +0200, Jonas Andradas wrote:
> Hi Julian, 
> please find attached the patch that was created leveraging Gemini instead.  It
> addresses the same conflicts, but using slightly different approach.  Adding
> here just in case it's useful, not necesssarily as a production-ready patch.
> 
> Thanks,
> Jonas.
> On Mon, May 11, 2026 at 11:31 PM Julian Gilbey  wrote:
> 
>   Hi Jonás,
> 
>   Many thanks for this!
> 
>   Best wishes,
> 
>      Julian
> 
>   On Mon, May 11, 2026 at 07:38:00PM +0200, Jonas Andradas wrote:
>   > Hi Julian, 
>   > Please find attached the "consolidated" patch as "final-patch.patch) (I 
> had
>   3-4
>   > which I merged into one), in case it is useful. As I mentioned, I used
>   Claude
>   > Code to support this process, and iterated several times until a working
>   patch
>   > was produced.  (I also did the same using Gemini, but Gemini's patch 
> seems a
>   > little bit more messy, although it also "works" (e.g. the module 
> compiles). 
>   I
>   > can share the patch produced with Gemini as well for reference when I'm 
> back
>   > home, although the one with Claude seemed the cleanest.)
>   >
>   > Thanks,
>   > Jonas.
>   >
>   > Jonás Andradas
>   >
>   > GPG Fingerprint:  678F 7BD0 83C3 28CE 9E8F
>   >                            3F7F 4D87 9996 E0C6 9372
>   > On Sun, May 10, 2026 at 8:17 AM Julian Gilbey  wrote:
>   >
>   >   Dear Jonas,
>   >
>   >   Thanks for this tantalising message!
>   >
>   >   Until the maintainer is able to provide a "proper" patch, would you be
>   >   able to share your patch?  The maintainer might well then be able to
>   >   check it and either approve or improve on it.
>   >
>   >   Best wishes,
>   >
>   >      Julian
>   >
>   >   On Fri, May 08, 2026 at 08:50:33AM +0200, Jonas Andradas wrote:
>   >   > Package: nvidia-kernel-dkms
>   >   > Version: 550.163.01-5
>   >   > Followup-For: Bug #1135362
>   >   > X-Debbugs-Cc: debian-am...@lists.debian.org, j.andra...@gmail.com
>   >   > User: debian-am...@lists.debian.org
>   >   > Usertags: amd64
>   >   > Control: tags -1 ftbfs
>   >   >
>   >   > Dear Maintainer,
>   >   >
>   >   > I am experiencing this as well in my Debian sid system. I had a 
> similar
>   >   issue a
>   >   > couple of weeks ago in a Proxmox host (running Debian trixie), as
>   Proxmox
>   >   > provides its own kernel and it was bumped to version 7.  Leveraging AI
>   >   (Gemini
>   >   > and Claude) I managed to obtain patches for the nvidia-kernel-dkms
>   package
>   >   in
>   >   > trixie, so that it would compile for Proxmox's kernel 7. These compile
>   and I
>   >   > get the functionality, so for me it was "good enough" for my homelab,
>   but I
>   >   > would not be so bold as to presume they are the best patch possible. 
> If
>   >   these
>   >   > patches can be useful to see the changes that were needed to make this
>   work,
>   >   > such as the ones below, I could upload the file under debian/patches
>   that
>   >   > applied to the trixie package allowed me to built it for Proxmox's
>   kernel 7:
>   >   >
>   >   >      - conftest.sh: detect NV_VM_AREA_STRUCT_HAS___VM_FLAGS, absence 
> of
>   >   > dma_map_ops.map_resource, void return of dma_fence_signal, and
>   >   > drm_mode_config_funcs.fb_create format_info argument
>   >   >      - nv-mm.h: handle vma->vm_flags cast for kernels without 
> __vm_flags
>   >   >      - nv-mmap.c: wrap VMA_LOCK_OFFSET and __is_vma_write_locked for
>   1-arg
>   >   form
>   >   >      - nv-time.h: compat shim for removed in_irq() macro
>   >   >      - nv-dma.c: guard dma_map_ops.map_resource access
>   >   >      - header-presence-tests.mk: add drm/drm_print.h detection
>   >   >      - nvidia-drm-priv.h: include drm_print.h for
>   >   DRM_ERROR/DRM_INFO/DRM_DEBUG
>   >   >      - nvidia-dma-fence-helper.h: handle void dma_fence_signal return
>   type
>   >   >      - nvidia-drm-helper.h: use for_each_new_*_in_state iterators
>   >   >      - nvidia-drm-drv.c, nvidia-drm-fb.c: handle fb_create format_info
>   arg
>   >   >
>   >   >
>   >   > Thanks,
>   >   > Jonas.
> 
> --
> Jonás Andradas
> 
> GPG Fingerprint:  678F 7BD0 83C3 28CE 9E8F
>                            3F7F 4D87 9996 E0C6 9372

> Index: kernel/common/inc/nv-timer.h
> ===
> --- kernel.orig/common/inc/nv-timer.h
> +++ kernel/common/inc/nv-timer.h
> @@ -24,6 +24,7 @@
>  
>  #include 
>  #include  // For container_of
> +#include 
>  
>  #include "conftest.h"
>  
> @@ -65,7 +66,7 @@ static inline void nv_timer_setup(struct
>  
>  static inline void nv_timer_delete_sync(struct timer_list *timer)
>  {
> -#if !defined(NV_BSD) && NV_IS_EXPORT_SYMBOL_PRESENT_timer_delete_sync
> +#if !defined(NV_BSD) && 
> (defined(NV_IS_EXPORT_SYMBOL_PRESENT_timer_delete_sync) || LINUX_VERSION_CODE 
> >= KERNEL_VERSION(6, 12, 0))
>  timer_delete_sync(timer);
>  #else
>  del_timer_

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Jonas Andradas]

Hi Julian,

please find attached the patch that was created leveraging Gemini instead.
It addresses the same conflicts, but using slightly different approach.
Adding here just in case it's useful, not necesssarily as a
production-ready patch.

Thanks,
Jonas.

On Mon, May 11, 2026 at 11:31 PM Julian Gilbey  wrote:

> Hi Jonás,
>
> Many thanks for this!
>
> Best wishes,
>
>Julian
>
> On Mon, May 11, 2026 at 07:38:00PM +0200, Jonas Andradas wrote:
> > Hi Julian,
> > Please find attached the "consolidated" patch as "final-patch.patch) (I
> had 3-4
> > which I merged into one), in case it is useful. As I mentioned, I used
> Claude
> > Code to support this process, and iterated several times until a working
> patch
> > was produced.  (I also did the same using Gemini, but Gemini's patch
> seems a
> > little bit more messy, although it also "works" (e.g. the module
> compiles).  I
> > can share the patch produced with Gemini as well for reference when I'm
> back
> > home, although the one with Claude seemed the cleanest.)
> >
> > Thanks,
> > Jonas.
> >
> > Jonás Andradas
> >
> > GPG Fingerprint:  678F 7BD0 83C3 28CE 9E8F
> >3F7F 4D87 9996 E0C6 9372
> > On Sun, May 10, 2026 at 8:17 AM Julian Gilbey  wrote:
> >
> >   Dear Jonas,
> >
> >   Thanks for this tantalising message!
> >
> >   Until the maintainer is able to provide a "proper" patch, would you be
> >   able to share your patch?  The maintainer might well then be able to
> >   check it and either approve or improve on it.
> >
> >   Best wishes,
> >
> >  Julian
> >
> >   On Fri, May 08, 2026 at 08:50:33AM +0200, Jonas Andradas wrote:
> >   > Package: nvidia-kernel-dkms
> >   > Version: 550.163.01-5
> >   > Followup-For: Bug #1135362
> >   > X-Debbugs-Cc: debian-am...@lists.debian.org, j.andra...@gmail.com
> >   > User: debian-am...@lists.debian.org
> >   > Usertags: amd64
> >   > Control: tags -1 ftbfs
> >   >
> >   > Dear Maintainer,
> >   >
> >   > I am experiencing this as well in my Debian sid system. I had a
> similar
> >   issue a
> >   > couple of weeks ago in a Proxmox host (running Debian trixie), as
> Proxmox
> >   > provides its own kernel and it was bumped to version 7.  Leveraging
> AI
> >   (Gemini
> >   > and Claude) I managed to obtain patches for the nvidia-kernel-dkms
> package
> >   in
> >   > trixie, so that it would compile for Proxmox's kernel 7. These
> compile and I
> >   > get the functionality, so for me it was "good enough" for my
> homelab, but I
> >   > would not be so bold as to presume they are the best patch possible.
> If
> >   these
> >   > patches can be useful to see the changes that were needed to make
> this work,
> >   > such as the ones below, I could upload the file under debian/patches
> that
> >   > applied to the trixie package allowed me to built it for Proxmox's
> kernel 7:
> >   >
> >   >  - conftest.sh: detect NV_VM_AREA_STRUCT_HAS___VM_FLAGS, absence
> of
> >   > dma_map_ops.map_resource, void return of dma_fence_signal, and
> >   > drm_mode_config_funcs.fb_create format_info argument
> >   >  - nv-mm.h: handle vma->vm_flags cast for kernels without
> __vm_flags
> >   >  - nv-mmap.c: wrap VMA_LOCK_OFFSET and __is_vma_write_locked for
> 1-arg
> >   form
> >   >  - nv-time.h: compat shim for removed in_irq() macro
> >   >  - nv-dma.c: guard dma_map_ops.map_resource access
> >   >  - header-presence-tests.mk: add drm/drm_print.h detection
> >   >  - nvidia-drm-priv.h: include drm_print.h for
> >   DRM_ERROR/DRM_INFO/DRM_DEBUG
> >   >  - nvidia-dma-fence-helper.h: handle void dma_fence_signal
> return type
> >   >  - nvidia-drm-helper.h: use for_each_new_*_in_state iterators
> >   >  - nvidia-drm-drv.c, nvidia-drm-fb.c: handle fb_create
> format_info arg
> >   >
> >   >
> >   > Thanks,
> >   > Jonas.
>


-- 
Jonás Andradas

GPG Fingerprint:  678F 7BD0 83C3 28CE 9E8F
   3F7F 4D87 9996 E0C6 9372
Index: kernel/common/inc/nv-timer.h
===
--- kernel.orig/common/inc/nv-timer.h
+++ kernel/common/inc/nv-timer.h
@@ -24,6 +24,7 @@
 
 #include 
 #include  // For container_of
+#include 
 
 #include "conftest.h"
 
@@ -65,7 +66,7 @@ static inline void nv_timer_setup(struct
 
 static inline void nv_timer_delete_sync(struct timer_list *timer)
 {
-#if !defined(NV_BSD) && NV_IS_EXPORT_SYMBOL_PRESENT_timer_delete_sync
+#if !defined(NV_BSD) && (defined(NV_IS_EXPORT_SYMBOL_PRESENT_timer_delete_sync) || LINUX_VERSION_CODE >= KERNEL_VERSION(6, 12, 0))
 timer_delete_sync(timer);
 #else
 del_timer_sync(timer);
Index: kernel/nvidia-drm/nvidia-dma-fence-helper.h
===
--- kernel.orig/nvidia-drm/nvidia-dma-fence-helper.h
+++ kernel/nvidia-drm/nvidia-dma-fence-helper.h
@@ -97,7 +97,8 @@ static inline int nv_dma_fence_signal(nv
 #if defined(NV_LINUX_FENCE_H_PRESENT)
 return fence_signal(fence);
 #else
-retur

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Julian Gilbey]

Hi Jonás,

Many thanks for this!

Best wishes,

   Julian

On Mon, May 11, 2026 at 07:38:00PM +0200, Jonas Andradas wrote:
> Hi Julian, 
> Please find attached the "consolidated" patch as "final-patch.patch) (I had 
> 3-4
> which I merged into one), in case it is useful. As I mentioned, I used Claude
> Code to support this process, and iterated several times until a working patch
> was produced.  (I also did the same using Gemini, but Gemini's patch seems a
> little bit more messy, although it also "works" (e.g. the module compiles).  I
> can share the patch produced with Gemini as well for reference when I'm back
> home, although the one with Claude seemed the cleanest.)
> 
> Thanks,
> Jonas.
> 
> Jonás Andradas
> 
> GPG Fingerprint:  678F 7BD0 83C3 28CE 9E8F
>                            3F7F 4D87 9996 E0C6 9372
> On Sun, May 10, 2026 at 8:17 AM Julian Gilbey  wrote:
> 
>   Dear Jonas,
> 
>   Thanks for this tantalising message!
> 
>   Until the maintainer is able to provide a "proper" patch, would you be
>   able to share your patch?  The maintainer might well then be able to
>   check it and either approve or improve on it.
> 
>   Best wishes,
> 
>      Julian
> 
>   On Fri, May 08, 2026 at 08:50:33AM +0200, Jonas Andradas wrote:
>   > Package: nvidia-kernel-dkms
>   > Version: 550.163.01-5
>   > Followup-For: Bug #1135362
>   > X-Debbugs-Cc: debian-am...@lists.debian.org, j.andra...@gmail.com
>   > User: debian-am...@lists.debian.org
>   > Usertags: amd64
>   > Control: tags -1 ftbfs
>   >
>   > Dear Maintainer,
>   >
>   > I am experiencing this as well in my Debian sid system. I had a similar
>   issue a
>   > couple of weeks ago in a Proxmox host (running Debian trixie), as Proxmox
>   > provides its own kernel and it was bumped to version 7.  Leveraging AI
>   (Gemini
>   > and Claude) I managed to obtain patches for the nvidia-kernel-dkms package
>   in
>   > trixie, so that it would compile for Proxmox's kernel 7. These compile 
> and I
>   > get the functionality, so for me it was "good enough" for my homelab, but 
> I
>   > would not be so bold as to presume they are the best patch possible. If
>   these
>   > patches can be useful to see the changes that were needed to make this 
> work,
>   > such as the ones below, I could upload the file under debian/patches that
>   > applied to the trixie package allowed me to built it for Proxmox's kernel 
> 7:
>   >
>   >      - conftest.sh: detect NV_VM_AREA_STRUCT_HAS___VM_FLAGS, absence of
>   > dma_map_ops.map_resource, void return of dma_fence_signal, and
>   > drm_mode_config_funcs.fb_create format_info argument
>   >      - nv-mm.h: handle vma->vm_flags cast for kernels without __vm_flags
>   >      - nv-mmap.c: wrap VMA_LOCK_OFFSET and __is_vma_write_locked for 1-arg
>   form
>   >      - nv-time.h: compat shim for removed in_irq() macro
>   >      - nv-dma.c: guard dma_map_ops.map_resource access
>   >      - header-presence-tests.mk: add drm/drm_print.h detection
>   >      - nvidia-drm-priv.h: include drm_print.h for
>   DRM_ERROR/DRM_INFO/DRM_DEBUG
>   >      - nvidia-dma-fence-helper.h: handle void dma_fence_signal return type
>   >      - nvidia-drm-helper.h: use for_each_new_*_in_state iterators
>   >      - nvidia-drm-drv.c, nvidia-drm-fb.c: handle fb_create format_info arg
>   >
>   >
>   > Thanks,
>   > Jonas.

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Sebastiaan Couwenberg]

On 5/11/26 7:38 PM, Jonas Andradas wrote:

Please find attached the "consolidated" patch as "final-patch.patch) (I had
3-4 which I merged into one), in case it is useful.


These patches have some merit, but it would be better to get them from upstream 
as this is what seems to be done for prior issues, e.g.:

 
https://salsa.debian.org/nvidia-team/nvidia-graphics-drivers/-/commit/54d4c40a63dad575bc5e907271b47b873c4a87af

Unfortunately README.source doesn't document the procedure to 
cherry-pick/backport upstream changes, not is there a Repository URL in the 
upstream metadata.

Kind Regards,

Bas

--
 PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Jonas Andradas]

Hi Julian,

Please find attached the "consolidated" patch as "final-patch.patch) (I had
3-4 which I merged into one), in case it is useful. As I mentioned, I used
Claude Code to support this process, and iterated several times until a
working patch was produced.  (I also did the same using Gemini, but
Gemini's patch seems a little bit more messy, although it also "works"
(e.g. the module compiles).  I can share the patch produced with Gemini as
well for reference when I'm back home, although the one with Claude seemed
the cleanest.)

Thanks,
Jonas.


Jonás Andradas

GPG Fingerprint:  678F 7BD0 83C3 28CE 9E8F
   3F7F 4D87 9996 E0C6 9372

On Sun, May 10, 2026 at 8:17 AM Julian Gilbey  wrote:

> Dear Jonas,
>
> Thanks for this tantalising message!
>
> Until the maintainer is able to provide a "proper" patch, would you be
> able to share your patch?  The maintainer might well then be able to
> check it and either approve or improve on it.
>
> Best wishes,
>
>Julian
>
> On Fri, May 08, 2026 at 08:50:33AM +0200, Jonas Andradas wrote:
> > Package: nvidia-kernel-dkms
> > Version: 550.163.01-5
> > Followup-For: Bug #1135362
> > X-Debbugs-Cc: debian-am...@lists.debian.org, j.andra...@gmail.com
> > User: debian-am...@lists.debian.org
> > Usertags: amd64
> > Control: tags -1 ftbfs
> >
> > Dear Maintainer,
> >
> > I am experiencing this as well in my Debian sid system. I had a similar
> issue a
> > couple of weeks ago in a Proxmox host (running Debian trixie), as Proxmox
> > provides its own kernel and it was bumped to version 7.  Leveraging AI
> (Gemini
> > and Claude) I managed to obtain patches for the nvidia-kernel-dkms
> package in
> > trixie, so that it would compile for Proxmox's kernel 7. These compile
> and I
> > get the functionality, so for me it was "good enough" for my homelab,
> but I
> > would not be so bold as to presume they are the best patch possible. If
> these
> > patches can be useful to see the changes that were needed to make this
> work,
> > such as the ones below, I could upload the file under debian/patches that
> > applied to the trixie package allowed me to built it for Proxmox's
> kernel 7:
> >
> >  - conftest.sh: detect NV_VM_AREA_STRUCT_HAS___VM_FLAGS, absence of
> > dma_map_ops.map_resource, void return of dma_fence_signal, and
> > drm_mode_config_funcs.fb_create format_info argument
> >  - nv-mm.h: handle vma->vm_flags cast for kernels without __vm_flags
> >  - nv-mmap.c: wrap VMA_LOCK_OFFSET and __is_vma_write_locked for
> 1-arg form
> >  - nv-time.h: compat shim for removed in_irq() macro
> >  - nv-dma.c: guard dma_map_ops.map_resource access
> >  - header-presence-tests.mk: add drm/drm_print.h detection
> >  - nvidia-drm-priv.h: include drm_print.h for
> DRM_ERROR/DRM_INFO/DRM_DEBUG
> >  - nvidia-dma-fence-helper.h: handle void dma_fence_signal return
> type
> >  - nvidia-drm-helper.h: use for_each_new_*_in_state iterators
> >  - nvidia-drm-drv.c, nvidia-drm-fb.c: handle fb_create format_info
> arg
> >
> >
> > Thanks,
> > Jonas.
>
From: Jonas Andradas 
Date: Thu, 08 May 2026 00:00:00 +
Subject: add LINUXINCLUDE to NV_CONFTEST_CFLAGS for split kernel header support

Debian (and other distributions) split kernel headers into an
architecture-specific package and a common package.  The common headers
(including linux/kconfig.h and linux/stdarg.h) live in a separate directory
that is only reachable via LINUXINCLUDE (which already contains the correct
-I flags for both trees).

Without LINUXINCLUDE in NV_CONFTEST_CFLAGS the conftest compilation probes
cannot find kconfig.h, so IS_ENABLED() calls in kernel headers cause every
conftest to fail, and linux/stdarg.h is also undetected, breaking the
nv_stdarg.h include path.

Add $(LINUXINCLUDE) to NV_CONFTEST_CFLAGS so that conftest probes use the
same include search path as the kernel build itself.

---
 Kbuild | 1 +
 1 file changed, 1 insertion(+)

--- a/Kbuild
+++ b/Kbuild
@@ -186,6 +186,7 @@ NV_CFLAGS_FROM_CONFTEST := $(shell $(NV_
 NV_CONFTEST_CFLAGS =
 NV_CONFTEST_CFLAGS += $(NV_CFLAGS_FROM_KBUILD)
+NV_CONFTEST_CFLAGS += $(LINUXINCLUDE)
 NV_CONFTEST_CFLAGS += $(NV_CFLAGS_FROM_CONFTEST) $(ccflags-y) -fno-pie
 NV_CONFTEST_CFLAGS += $(call cc-disable-warning,pointer-sign)
 NV_CONFTEST_CFLAGS += $(call cc-option,-fshort-wchar,)

--
From: Jonas Andradas 
Date: Thu, 08 May 2026 00:00:00 +
Subject: backport VMA lock API changes from Linux 6.15

Linux 6.15 (and thus Linux 7.0) renamed VMA_LOCK_OFFSET to
VM_REFCNT_EXCLUDE_READERS_FLAG and changed __is_vma_write_locked()
from a two-argument form (vma, &seq) to a one-argument form (vma),
with __vma_raw_mm_seqnum(vma) providing the sequence number separately.

Add a backward-compatible alias and conditional compilation so the
manual VMA write-lock implementation in nv_vma_start_write() builds
against both the old and new APIs.

---
 nvidia/nv-mmap.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

---

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[François Gannaz]

Dear maintainer.

Here is a hand-made patch which fixed the build problem on Debian testing.
It works for me, so it may be useful to others, but it's a crude work.

The attached patch contains:
- Linux7 changed VMA_LOCK_OFFSET, so I read a more recent release of the
  nvidia driver (v595) and extracted a fix from it.
- 3 changes of function prototypes were obvious.
- There was an error with awk/pahole, so I removed pahole's variables
  from the Makefile (IIRC, this breaks some debugging features).
  That part of the patch is clearly not suitable for a larger audience.

Regards,
--
François Gannaz
diff --git a/Makefile b/Makefile
index 2dee7b9..adccc37 100644
--- a/Makefile
+++ b/Makefile
@@ -95,7 +95,7 @@ else
   # If scripts/pahole-flags.sh is not present in the kernel tree, add PAHOLE and
   # PAHOLE_AWK_PROGRAM assignments to PAHOLE_VARIABLES; otherwise assign the
   # empty string to PAHOLE_VARIABLES.
-  PAHOLE_VARIABLES=$(if $(wildcard $(KERNEL_SOURCES)/scripts/pahole-flags.sh),,"PAHOLE=$(AWK) '$(PAHOLE_AWK_PROGRAM)'")
+  PAHOLE_VARIABLES=""
 
   ifndef ARCH
 ARCH := $(shell uname -m | sed -e 's/i.86/i386/' \
diff --git a/nvidia-drm/nvidia-dma-fence-helper.h b/nvidia-drm/nvidia-dma-fence-helper.h
index 731f6a7..663ddab 100644
--- a/nvidia-drm/nvidia-dma-fence-helper.h
+++ b/nvidia-drm/nvidia-dma-fence-helper.h
@@ -93,19 +93,19 @@ nv_dma_fence_default_wait(nv_dma_fence_t *fence,
 #endif
 }
 
-static inline int nv_dma_fence_signal(nv_dma_fence_t *fence) {
+static inline void nv_dma_fence_signal(nv_dma_fence_t *fence) {
 #if defined(NV_LINUX_FENCE_H_PRESENT)
-return fence_signal(fence);
+fence_signal(fence);
 #else
-return dma_fence_signal(fence);
+dma_fence_signal(fence);
 #endif
 }
 
-static inline int nv_dma_fence_signal_locked(nv_dma_fence_t *fence) {
+static inline void nv_dma_fence_signal_locked(nv_dma_fence_t *fence) {
 #if defined(NV_LINUX_FENCE_H_PRESENT)
-return fence_signal_locked(fence);
+fence_signal_locked(fence);
 #else
-return dma_fence_signal_locked(fence);
+dma_fence_signal_locked(fence);
 #endif
 }
 
diff --git a/nvidia/nv-mmap.c b/nvidia/nv-mmap.c
index 9351a27..1a52ba0 100644
--- a/nvidia/nv-mmap.c
+++ b/nvidia/nv-mmap.c
@@ -838,16 +838,22 @@ void NV_API_CALL nv_set_safe_to_mmap_locked(
 nvl->safe_to_mmap = safe_to_mmap;
 }
 
+#if defined(VM_REFCNT_EXCLUDE_READERS_FLAG)
+#define NV_VMA_LOCK_OFFSET VM_REFCNT_EXCLUDE_READERS_FLAG
+#else
+#define NV_VMA_LOCK_OFFSET VMA_LOCK_OFFSET
+#endif
+
 #if !NV_CAN_CALL_VMA_START_WRITE
 static NvBool nv_vma_enter_locked(struct vm_area_struct *vma, NvBool detaching)
 {
-NvU32 tgt_refcnt = VMA_LOCK_OFFSET;
+NvU32 tgt_refcnt = NV_VMA_LOCK_OFFSET;
 NvBool interrupted = NV_FALSE;
 if (!detaching)
 {
 tgt_refcnt++;
 }
-if (!refcount_add_not_zero(VMA_LOCK_OFFSET, &vma->vm_refcnt))
+if (!refcount_add_not_zero(NV_VMA_LOCK_OFFSET, &vma->vm_refcnt))
 {
 return NV_FALSE;
 }
@@ -877,7 +883,7 @@ static NvBool nv_vma_enter_locked(struct vm_area_struct *vma, NvBool detaching)
 if (interrupted)
 {
 // Clean up on error: release refcount and dep_map
-refcount_sub_and_test(VMA_LOCK_OFFSET, &vma->vm_refcnt);
+refcount_sub_and_test(NV_VMA_LOCK_OFFSET, &vma->vm_refcnt);
 rwsem_release(&vma->vmlock_dep_map, _RET_IP_);
 return NV_FALSE;
 }
@@ -893,7 +899,7 @@ void nv_vma_start_write(struct vm_area_struct *vma)
 {
 NvU32 mm_lock_seq;
 NvBool locked;
-if (__is_vma_write_locked(vma, &mm_lock_seq))
+if (__is_vma_write_locked(vma))
 return;
 
 locked = nv_vma_enter_locked(vma, NV_FALSE);
@@ -902,7 +908,7 @@ void nv_vma_start_write(struct vm_area_struct *vma)
 if (locked)
 {
 NvBool detached;
-detached = refcount_sub_and_test(VMA_LOCK_OFFSET, &vma->vm_refcnt);
+detached = refcount_sub_and_test(NV_VMA_LOCK_OFFSET, &vma->vm_refcnt);
 rwsem_release(&vma->vmlock_dep_map, _RET_IP_);
 WARN_ON_ONCE(detached);
 }

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Julian Gilbey]

Dear Jonas,

Thanks for this tantalising message!

Until the maintainer is able to provide a "proper" patch, would you be
able to share your patch?  The maintainer might well then be able to
check it and either approve or improve on it.

Best wishes,

   Julian

On Fri, May 08, 2026 at 08:50:33AM +0200, Jonas Andradas wrote:
> Package: nvidia-kernel-dkms
> Version: 550.163.01-5
> Followup-For: Bug #1135362
> X-Debbugs-Cc: debian-am...@lists.debian.org, j.andra...@gmail.com
> User: debian-am...@lists.debian.org
> Usertags: amd64
> Control: tags -1 ftbfs
> 
> Dear Maintainer,
> 
> I am experiencing this as well in my Debian sid system. I had a similar issue 
> a
> couple of weeks ago in a Proxmox host (running Debian trixie), as Proxmox
> provides its own kernel and it was bumped to version 7.  Leveraging AI (Gemini
> and Claude) I managed to obtain patches for the nvidia-kernel-dkms package in
> trixie, so that it would compile for Proxmox's kernel 7. These compile and I
> get the functionality, so for me it was "good enough" for my homelab, but I
> would not be so bold as to presume they are the best patch possible. If these
> patches can be useful to see the changes that were needed to make this work,
> such as the ones below, I could upload the file under debian/patches that
> applied to the trixie package allowed me to built it for Proxmox's kernel 7:
> 
>  - conftest.sh: detect NV_VM_AREA_STRUCT_HAS___VM_FLAGS, absence of
> dma_map_ops.map_resource, void return of dma_fence_signal, and
> drm_mode_config_funcs.fb_create format_info argument
>  - nv-mm.h: handle vma->vm_flags cast for kernels without __vm_flags
>  - nv-mmap.c: wrap VMA_LOCK_OFFSET and __is_vma_write_locked for 1-arg 
> form
>  - nv-time.h: compat shim for removed in_irq() macro
>  - nv-dma.c: guard dma_map_ops.map_resource access
>  - header-presence-tests.mk: add drm/drm_print.h detection
>  - nvidia-drm-priv.h: include drm_print.h for DRM_ERROR/DRM_INFO/DRM_DEBUG
>  - nvidia-dma-fence-helper.h: handle void dma_fence_signal return type
>  - nvidia-drm-helper.h: use for_each_new_*_in_state iterators
>  - nvidia-drm-drv.c, nvidia-drm-fb.c: handle fb_create format_info arg
> 
> 
> Thanks,
> Jonas.

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Thomas More]

Package: nvidia-kernel-dkms
Version: 550.163.01-5
Followup-For: Bug #1135362
X-Debbugs-Cc: debian-am...@lists.debian.org, deb...@gilead.dev
User: debian-am...@lists.debian.org
Usertags: amd64
Control: tags -1 ftbfs

I'm hitting this as well:

*

nvidia/nv-mmap.c:905:42: error: ‘VMA_LOCK_OFFSET’ undeclared (first use in this 
function); did you mean ‘VGA_CRTC_OFFSET’?
  905 | detached = refcount_sub_and_test(VMA_LOCK_OFFSET, 
&vma->vm_refcnt);
  |  ^~~
  |  VGA_CRTC_OFFSET
make[4]: *** 
[/usr/src/linux-headers-7.0.3+deb14-common/scripts/Makefile.build:294: 
nvidia/nv-mmap.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[3]: *** [/usr/src/linux-headers-7.0.3+deb14-common/Makefile:2129: .] Error 
2
make[2]: *** [/usr/src/linux-headers-7.0.3+deb14-common/Makefile:260: 
__sub-make] Error 2
make[2]: Leaving directory '/var/lib/dkms/nvidia-current/550.163.01/build'
make[1]: *** [Makefile:260: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-7.0.3+deb14-common'
make: *** [Makefile:140: modules] Error 2

# exit code: 2

*

FWIW, I found what appears to be the same problem discussed here:

https://github.com/NVIDIA/open-gpu-kernel-modules/issues/1113
and cf. here:

https://old.reddit.com/r/linuxquestions/comments/1sodpgh/i_cant_build_the_nvidia_580xxdkms_on_linux_kernel/`

-- Package-specific info:
uname -a:
Linux edith 6.19.14+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.19.14-1 
(2026-04-25) x86_64 GNU/Linux

/proc/version:
Linux version 6.19.14+deb14-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-15 (Debian 15.2.0-17) 15.2.0, GNU ld (GNU Binutils for 
Debian) 2.46) #1 SMP PREEMPT_DYNAMIC Debian 6.19.14-1 (2026-04-25)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  550.163.01  Tue Apr  8 12:41:17 
UTC 2025
GCC version:  gcc version 15.2.0 (Debian 15.2.0-17) 

Bug#1135362: linux-image-7.0.3+deb14-amd64: Fails to build nVidia module

[Nicolas Patrois]

Package: src:linux
Version: 7.0.3-1
Severity: normal

Dear Maintainer,

I don’t know if it’s the right place to report this bug.
Anyway, this morning, I couldn’t build nVidia module.

Here is apt’s output (a bit filtered):

Paramétrage de linux-headers-7.0.3+deb14-amd64 (7.0.3-1) ...
/etc/kernel/header_postinst.d/dkms:
Sign command: /lib/modules/7.0.3+deb14-amd64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Autoinstall of module nvidia-current/550.163.01 for kernel 7.0.3+deb14-amd64
(x86_64)
Building module(s)..(bad exit status: 2)
Failed command:
env NV_VERBOSE=1 make -j12 modules KERNEL_UNAME=7.0.3+deb14-amd64

Error! Bad return status for module build on kernel: 7.0.3+deb14-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/550.163.01/build/make.log for more
information.

Autoinstall on 7.0.3+deb14-amd64 failed for module(s) nvidia-current(10).

Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
run-parts: /etc/kernel/header_postinst.d/dkms exited with return code 1
dpkg: erreur de traitement du paquet linux-headers-7.0.3+deb14-amd64
(--configure) :
 old linux-headers-7.0.3+deb14-amd64 package postinst maintainer script
subprocess failed with exit status 1
Paramétrage de linux-image-7.0.3+deb14-amd64 (7.0.3-1) ...
I: /initrd.img is now a symlink to boot/initrd.img-7.0.3+deb14-amd64
/etc/kernel/postinst.d/dkms:
Sign command: /lib/modules/7.0.3+deb14-amd64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Autoinstall of module nvidia-current/550.163.01 for kernel 7.0.3+deb14-amd64
(x86_64)
Building module(s)..(bad exit status: 2)
Failed command:
env NV_VERBOSE=1 make -j12 modules KERNEL_UNAME=7.0.3+deb14-amd64

Error! Bad return status for module build on kernel: 7.0.3+deb14-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/550.163.01/build/make.log for more
information.

Autoinstall on 7.0.3+deb14-amd64 failed for module(s) nvidia-current(10).

Error! One or more modules failed to install during autoinstall.
Refer to previous errors for more information.
run-parts: /etc/kernel/postinst.d/dkms exited with return code 1
dpkg: erreur de traitement du paquet linux-image-7.0.3+deb14-amd64
(--configure) :
 old linux-image-7.0.3+deb14-amd64 package postinst maintainer script
subprocess failed with exit status 1
[…]
dpkg: des problèmes de dépendances empêchent la configuration de linux-headers-
amd64 :
 linux-headers-amd64 dépend de linux-headers-7.0.3+deb14-amd64 (= 7.0.3-1);
cependant :
 Le paquet linux-headers-7.0.3+deb14-amd64 n'est pas encore configuré.

dpkg: erreur de traitement du paquet linux-headers-amd64 (--configure) :
 problèmes de dépendances - laissé non configuré
dpkg: des problèmes de dépendances empêchent la configuration de linux-image-
amd64 :
 linux-image-amd64 dépend de linux-image-7.0.3+deb14-amd64 (= 7.0.3-1);
cependant :
 Le paquet linux-image-7.0.3+deb14-amd64 n'est pas encore configuré.

dpkg: erreur de traitement du paquet linux-image-amd64 (--configure) :
 problèmes de dépendances - laissé non configuré
[…]
Traitement des actions différées (« triggers ») pour bamfdaemon
(0.5.6+repack-1.1+b3) ...
Rebuilding /usr/share/applications/bamf-2.index...
Traitement des actions différées (« triggers ») pour desktop-file-utils
(0.28-1) ...
Traitement des actions différées (« triggers ») pour hicolor-icon-theme
(0.18-2) ...
Traitement des actions différées (« triggers ») pour libc-bin (2.42-15) ...
ldconfig: /usr/local/lib/libSDL-1.2.so.0 is not a symbolic link

Traitement des actions différées (« triggers ») pour man-db (2.13.1-1) ...
Traitement des actions différées (« triggers ») pour shared-mime-info
(2.4-5+b3) ...
Traitement des actions différées (« triggers ») pour mailcap (3.76) ...
Des erreurs ont été rencontrées pendant l'exécution :
 linux-headers-7.0.3+deb14-amd64
 linux-image-7.0.3+deb14-amd64
 linux-headers-amd64
 linux-image-amd64
Erreur : Sub-process /usr/bin/dpkg returned an error code (1)

Yours,
nicolas


-- Package-specific info:
** Version:
Linux version 6.19.14+deb14-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-15 (Debian 15.2.0-17) 15.2.0, GNU ld (GNU Binutils for 
Debian) 2.46) #1 SMP PREEMPT_DYNAMIC Debian 6.19.14-1 (2026-04-25)



Running kernel does not match package!



** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.19.14+deb14-amd64 
root=UUID=d79da17c-e9d8-4059-b262-199bec5c2f40 ro quiet splash

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[169969.432647] audit: t