Nvidia open kernel module 590.48.01 fails to build on debian 6.18.5+deb14-amd64

Graphics / Linux Linux
,
1

Hello,

I am using debian with kernel “6.18.5+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.18.5-1 (2026-01-16) x86_64 GNU/Linux” on a frame.work laptop with discrete NVIDIA RTX 5070:

lspci |grep -i nvidia
c2:00.0 VGA compatible controller: NVIDIA Corporation GB206M [GeForce RTX 5070 Max-Q / Mobile] (rev a1)

The nvidia-kernel-dkms package can install flawlessly (though gives error messages telling me that my graphics card is only supported by the Open drivers.

Installing nvidia-open however is a totally different story, as it fails to build the kernel modules:

sudo apt install nvidia-open
[…]

Building for 6.18.3+deb14-amd64 and 6.18.5+deb14-amd64

Building initial module nvidia/590.48.01 for 6.18.3+deb14-amd64
Sign command: /lib/modules/6.18.3+deb14-amd64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module(s)…(bad exit status: 2)
Failed command:
‘make’ -j24 KERNEL_UNAME=6.18.3+deb14-amd64 IGNORE_PREEMPT_RT_PRESENCE=1 IGNORE_XEN_PRESENCE=1 modules

Error! Bad return status for module build on kernel: 6.18.3+deb14-amd64 (x86_64)
Consult /var/lib/dkms/nvidia/590.48.01/build/make.log for more information.
dpkg: error processing package nvidia-kernel-open-dkms (–configure):
old nvidia-kernel-open-dkms package postinst maintainer script subprocess failed with exit status 10
dpkg: dependency problems prevent configuration of nvidia-open:
nvidia-open depends on nvidia-kernel-open-dkms (>= 590.48.01); however:
Package nvidia-kernel-open-dkms is not configured yet.

dpkg: error processing package nvidia-open (–configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
nvidia-kernel-open-dkms
nvidia-open
Error: Sub-process /usr/bin/dpkg returned an error code (1)

So I checked the make.log for errors and this is what I found:

DKMS (dkms-3.3.0) make.log for nvidia/590.48.01 for kernel 6.18.3+deb14-amd64 (x86_64)
Thu 22 Jan 12:27:26 CET 2026

Building module(s)

command: ‘make’ -j24 KERNEL_UNAME=6.18.3+deb14-amd64 IGNORE_PREEMPT_RT_PRESENCE=1 IGNORE_XEN_PRESENCE=1 modules

make -C src/nvidia
make -C src/nvidia-modeset
[…]

[ nvidia-modeset ] CXX src/dp/nvdp-timer.cpp
[ nvidia-modeset ] LD _out/Linux_x86_64/turing_shaders.xz.o
Segmentation fault
make[1]: *** [Makefile:200: _out/Linux_x86_64/turing_shaders.xz.o] Error 139
make[1]: *** Deleting file ‘_out/Linux_x86_64/turing_shaders.xz.o’
make[1]: *** Waiting for unfinished jobs…
[ nvidia ] CC generated/g_sem_surf_nvoc.c
[ nvidia ] CC generated/g_spdm_nvoc.c

[…]

[ nvidia ] CC src/kernel/gpu/ccu/kernel_ccu_api.c
[ nvidia ] CC src/kernel/gpu/ce/arch/ampere/kernel_ce_ga100.c
[ nvidia ] CC src/kernel/gpu/ce/arch/ampere/kernel_ce_ga102.c
make[1]: Leaving directory ‘/var/lib/dkms/nvidia/590.48.01/build/src/nvidia-modeset’
[ nvidia ] CC src/kernel/gpu/ce/arch/blackwell/kernel_ce_gb100.c
make: *** [Makefile:46: src/nvidia-modeset/_out/Linux_x86_64/nv-modeset-kernel.o] Error 2
make: *** Waiting for unfinished jobs…
[ nvidia ] CC src/kernel/gpu/ce/arch/blackwell/kernel_ce_gb10b.c
[ nvidia ] CC src/kernel/gpu/ce/arch/blackwell/kernel_ce_gb202.c

[…]

I’m not sure where I should look for more information. Am I perhaps missing some packages (kernel headers are installed, contrib/non-free/non-free firmware is active in debian.sources) or some specific dependencies?

2

I’ve just installed 6.18.5 from Sid on a Forky VM (which I’m guessing is what you are using) and 590.48.01 from Trixie’s DC repo has been built without any problems:

morgwai@vm-forky:~$ sudo dkms status
nvidia/590.48.01, 6.17.12+deb14-amd64, x86_64: installed
nvidia/590.48.01, 6.17.13+deb14-amd64, x86_64: installed
nvidia/590.48.01, 6.18.5+deb14-amd64, x86_64: installed

Which repo have you obtained the driver from? Also make sure that your Forky installation is up2date: things move fast on testing.

3

I got the packages from the official sources (for some reason the link was changed into a hyperlink, but it’s from dh,eveloper.download.nvidia.com ):

$ cat /etc/apt/sources.list.d/nvidia-drivers.sources
Types: deb
URIs: Index of /compute/cuda/repos/debian13/x86_64
Suites: /
Signed-By: /usr/share/keyrings/nvidia-drivers.gpg

Oh, and I saw something weird when I ran the dkms status command:

$ sudo dkms status
nvidia/590.48.01: added
vhba/20250329, 6.18.3+deb14-amd64, x86_64: installed
vhba/20250329, 6.18.5+deb14-amd64, x86_64: installed

“nvidia” is just added (possibly because it wasn’t built?)

I wonder what these vhba are…

My system is up to date.

4

from apt-cache show $(apt-file search /usr/src/vhba |cut -d ':' -f 1 |head -n 1) :

VHBA kernel module, a virtual SCSI host bus adapter used by CDEmu daemon from
the CDEmu suite.

No offense, but it seems to me that Debian testing (“Forky”) is not the right suite for you: it is expected to break from time to time, so if you are not proficient with command-line, then the stable release (13 “Trixie”) will most probably be better for you.

5

Okay, perhaps I shouldn’t have derailed from the original topic : the open dkms fails to build and I’m not sure where to look for the culprit.

I’m aware that sid breaks stuff (like in Toy Story), so my quest here is not to improve my command-line skills (they do improve the more I play with it), but rather to find out where I can start looking for pointers.

When I say my system is up-to-date, it’s because I perform regular package upgrades. In my first message I provided the system info and you can see that the kernel 6.18.5 is from Jan 16th.

So do you have any clues as to where I could look for possible culprits?

6

Basically one of the components of the toolchain (linker, LD) has crashed:

This is most probably due to an upstream bug or a bug in Sid, which is generally an expected thing, as Sid is not even a release:

Debian Unstable (also known by its codename “Sid”) is not a release

Rather it’s just a loose collection of staging packages for “testing” (Forky) that may or may not conflict with each other at any given time:

no release-like quality assurance and integration testing is done on it.

If you insist on using Sid, then the “fastest” way to fix it, is probably to downgrade to some older version of the toolchain that is not affected by this bug. This in turn however will most probably make it impossible to correctly build modules for 6.18.5+deb14 kernel, as you generally need to use the same toolchain for the kernel image and its modules, so after downgrading you will first need to build your own kernel and then build modules for it.

I would however highly recommend going back at least to Forky as it is at least a release (unlike Sid) and it is at least guaranteed that its packages do not conflict with each other and form a (somewhat) coherent distro. Then on top of that, if you feel adventurous, you can install a few carefully selected packages from Sid (or even “experimental”). This is BTW the most common way that Debian developers work on “testing” and is well documented in the Debian reference: Chapter 2. Debian package management

7

Thank you, that’s super helpful. I may also have messed up with some of the system thingies due to my framework laptop not being fully supported out-of-the-box by debian…

I’ll scratch the system (having different partitions is always helpful) and install a clean system, either forky as you suggest, and I will then see which bleeding edge packages I want to add on top of that.

Thank you again.

8

So @morgwai666 thanks for your tips. I ended up re-installing the system using the latest trixie release and built from there.

The kernel module built without any issues. There’s some other head-scratching moments with Wayland weirdness but I’m going to leave that for another day.

It feels weird to come back to debian after all these years (I started out with Woody/Sarge and jigdo). Many things have changed so I’ve got a lot of catch up to do systemwise: I’m confused about Wayland, not sure what happened to “init 0/init 3/init …” but it’s good to see that debian is not standing still!

9

I use X11+MATE, so haven’t experienced any such stuff myself, but from what I read, Wayland is a total mistake, so I hope MATE will stay with X11.

What were you using during this time?

Did you mean s/Wayland/systemd/ or s/Wayland/init/ maybe? ;-)
SysV init has been replaced by systemd, which I also dislike and I consider migrating to Devuan (fork of Debian without systemd) from time to time, but I’m always too busy/lazy to make this effort ;-]

10

Wayland IS a total mistake! It doesn’t even take into account system keyboard configuration (I use UK Extended keyboard but for some reason Wayland decides that the WM should not check system config at all) but I’m going to stop here ;-).

Oh, just tinkering with the system. I was also programming stuff at that time… Enjoying the freedom of Open Source while rebooting often into Windows for playing games… but now with Wine and Steam support vastly improved I can let go of the Eye of Mordor.

I used one sentence to talk about two different things (a habit of mine).

I am confused about Wayland - nothing seems to work as expected/intended.

I installed a new debian system on this laptop and when tinkering with the initial setup I sometimes had to reboot after configuring some settings and realised SysV init was gone (init 6 was supposed to reboot the system, right? No, type “reboot”).

So yeah, it feels like the more things change, the more they stay the same… ;-)

1 Like