Linux 6.7.3 + 545.29.06/550.40.07: ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock'

The nvidia-kmod-common comes from Nvidia’s CUDA repo. I ran into that issue too. Nvidia’'s CUDA repo and rpmfusion conflict in strange ways. I’ve temporarily disabled the CUDA repo.

I only have the standard rpmfusion repos enabled as described here: Configuration - RPM Fusion
There is no mention of a separate “nvidia” rpmfusion repo despite the fact that it exists. Seems like an undocumented gotcha.

Indeed.

After cleanning up repos and do a full nvidia remove and reinstall. New Packages were installed.

Desktop render great in all monitors, no Display issues/Refreshing issues. so fa with kmod-nvidia-3:545.29.06-3.fc39.x86_64

akmod-nvidia-545.29.06-3.fc39.x86_64
kmod-nvidia-545.29.06-3.fc39.x86_64
kmod-nvidia-6.7.3-200.fc39.x86_64-545.29.06-3.fc39.x86_64
nvidia-modprobe-545.29.06-1.fc39.x86_64
nvidia-settings-545.29.06-1.fc39.x86_64
xorg-x11-drv-nvidia-545.29.06-2.fc39.x86_64
xorg-x11-drv-nvidia-cuda-libs-545.29.06-2.fc39.x86_64
xorg-x11-drv-nvidia-kmodsrc-545.29.06-2.fc39.x86_64
xorg-x11-drv-nvidia-libs-545.29.06-2.fc39.i686
xorg-x11-drv-nvidia-libs-545.29.06-2.fc39.x86_64
xorg-x11-drv-nvidia-power-545.29.06-2.fc39.x86_64

This issue was your fault, you chose to disable the updates repo (default enabled).

https://bugzilla.rpmfusion.org/show_bug.cgi?id=6862#c4

You’re incorrect the updates repo is enabled. But there is a conflict with the cuda repo. I’ve since disabled the cuda repo but the problem persisted.

I was eventually able to get it to work after realizing that rpmfusion is storing the nvidia drivers in an undocumented repo at:
https://download1.rpmfusion.org/nonfree/fedora/nvidia-driver/

IIRC the “nvidia driver” repo is provided as part of the workstation repos package. It’s part of the collection of repos that are managed by the option to enable third party repos during install/GNOME Software preferences.

It’s segmented off since Fedora can’t enable all of RPM Fusion by default, but a narrowly focused repository of “acceptable” material is less of an issue.

There’s also some documentation of the interaction between RPM Fusion and the CUDA repositories here:

https://rpmfusion.org/Howto/CUDA#Which_driver_Package

That’s even worst, you enabled a conflicting repo.
Doesn’t any one ever read the friggin notes provided, see

https://rpmfusion.org/Howto/CUDA?highlight=(\bCategoryHowto\b)#CUDA_Toolkit

1 Like

Leigh, I understand that troubleshooting without complete information is tricky. I remember you from my FedoraForum days over a decade ago when you were just getting started. But I assert that a routine ‘dnf update’ should not break my setup so badly that I lose an entire afternoon of productivity.

I also understand it’s easier / more convenient to just blame the user, but your assumptions of what I did and did not do are not supported by evidence. I installed the rpmfusion repos from the command line - as I’ve done for years. They worked (mostly trouble-free) until yesterday.

If the argument is that being unaware of an undocumented repo is my fault, then we share differing definitions of responsibility.

1 Like

Why can’t you see you caused this problem?

The rpmfusion updates repo’s are default enabled when you install the rpmfusion release packages.
rpmfusion-free and rpmfusion-nonfree repo’s are frozen like the fedora base repo and aren’t updated after final release.
If you want to disable rpmfusion-free-updates or rpmfusion-nonfree-updates you also need to disable fedora updates repo to match.

You seem fixated on assuming that I disabled the updates repo. I did not. I’m sorry you can’t get past that.

I’m only trying to provide feedback in hopes that it might help others in the future.
Like I said, I’ve managed to resolve the issue on my own. If you don’t feel there’s any issue on the rpmfusion side, you’re welcome to your opinion.

What you like or dislike is of no interest to me. I am only interested in returning my system to a stable and usable state. As that goal has been accomplished, I’d suggest we end the discussion here.

The error occurred on my Debian 12 also well.
Driver: 525.147.05 (from Debian repo)

It happened when updating to kernel 6.1.0-18-amd64.

https://forums.debian.net/viewtopic.php?t=158200


EDITED:
On Debian, upgrading to kernel 6.5 (from backports) fixed the nvidia issue when using kernel 6.1.0-18-amd64 and dkms:

sudo apt install -t bookworm-backports linux-image-amd64
sudo apt install -t bookworm-backports linux-headers-amd64
3 Likes

I believe this change was backported to all applicable and maintained kernels. 6.1 and 6.6 are LTS releases, but 6.5 would have been skipped since it’s EOL.

https://kernel.org/

1 Like

Interesting. If I understand this correctly, if I move between versions other than 6.5 I will most likely get the same error again? I’ll stick with version 6.5 until the patch arrives.

1 Like

Perfect!
I just did a apt update from Debian 12.4 to 12.5 (6.1.0-17-amd64 to 6.1.0-18-amd64) and it wouldn’t finish building the module. I tried purging and reinstalling, same thing.

Building for 6.1.0-18-amd64
Building initial module for 6.1.0-18-amd64
Error! Bad return status for module build on kernel: 6.1.0-18-amd64 (x86_64)
Consult /var/lib/dkms/nvidia-current/525.147.05/build/make.log for more information.
dpkg: error processing package nvidia-kernel-dkms (–configure):

After searching and reading numerous posts, of which really never provided a solution for me, I came across this thread and thankfully I read all the way down.

I would like to add to your post, for those that don’t have backports in their sources.list, to add the following line to their /etc/apt/sources.list file.
deb Index of /debian bookworm-backports main

1 Like

As long as Debian doesn’t backport the change, then yes. I believe this issue should only be exhibited in (upstream versions):

  • 6.8dev
  • 6.7.3+
  • 6.6.15+
  • 6.1.76+
1 Like

Debian 12 - 6.1.0-18-amd64

sh /usr/src/linux-headers-6.1.0-18-common/scripts/modules-check.sh /var/lib/dkms/nvidia-current/525.147.05/build/modules.order
make -f /usr/src/linux-headers-6.1.0-18-common/scripts/Makefile.modpost
sed 's/ko$/o/' /var/lib/dkms/nvidia-current/525.147.05/build/modules.order | scripts/mod/modpost -m -o /var/lib/dkms/nvidia-current/525.147.05/build/Module.symvers -e -i Module.symvers -T -
ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock'
ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_unlock'
make[3]: *** [/usr/src/linux-headers-6.1.0-18-common/scripts/Makefile.modpost:126: /var/lib/dkms/nvidia-current/525.147.05/build/Module.symvers] Error 1
make[2]: *** [/usr/src/linux-headers-6.1.0-18-common/Makefile:1991: modpost] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-6.1.0-18-amd64'
make[1]: *** [Makefile:250: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.1.0-18-common'
make: *** [Makefile:82: modules] Error 2

EDIT - RESOLVED thanks @felipsmartins!! booted on 6.1.0-15, then

sudo apt install -t bookworm-backports linux-image-amd64
sudo apt install -t bookworm-backports linux-headers-amd64
sudo apt purge linux-image-6.1.0-18-amd64
sudo apt update && sudo apt upgrade

rebooted on 6.5.0-0, nvidia installed, life is good again.

3 Likes

wait how did you guys manage to solve this i have the same error. do i have to go back to the old debian kernel? i am using Geforce RTX 30 series

Impossible. I did the same think as U do. Installed kernel from backports repo -6.5 kernel [Debian12 Stable], removed 6.x-18 and it didn’t work and I have the same problem [RTX 3060]. Nvidia drivers still crashing. Even on the kernel 6.5 from backports. I removed backports kernel and back to 6.1.0-17.

Hi All,

I’m getting the same issue as Linuksiarz with Debian 12, RTX 3060 ti and 6.x-18. just can’t get the drivers to install at all. backports or no backports or dropping down a kernel version.

In my case on 6.1.0-17-amd64 kernel everything works fine.

1 Like