On 6/13/25 16:35, marillat wrote:
On Sat, 24 Aug 2024 19:32:10 +0200 Marc Glisse <marc.gli...@normalesup.org>
wrote:
and it compiles the modules just fine. One reboot later, I notice that
linux is still using the old module. It seems redundant, so
apt purge nvidia-kernel-dkms
I had the same problem when I've moved to the Nvidia open driver and
spend some time to understand the problem.
More exactly the problem come from the -support packages
nvidia-kernel-support and nvidia-open-kernel-support
Both try to modprobe is own kernel module and this freeze the computer.
Does it really try to load both? (Which shouldn't be possible for 6.15
anyway, since you cannot built that currently.) Or just the wrong?
To fix this issue nvidia-open-kernel-support should Conflicts with
nvidia-open-kernel-support
If both nvidia-kernel-dkms and nvidia-open-kernel-dkms are installed,
nvidia-kernel-dkms takes precedence (this will likely change in the
future in favor of the open module). You can switch between them at
runtime (and without uninstalling any package) by running
update-glx --config nvidia
and (not) selecting the alternative with -open in its name.
This e.g. updates the alternatives to the config files which select the
actual module file names that get loaded when someone does
'modprobe nvidia' etc.
Ideally reboot after update-glx.
At least that's the theory how this was designed to work. I don't (want
to) have the hardware to actually test it ;-) But I'd like to get
confirmation whether the two dkms packages can co-exist and switched at
runtime as planned.
Where would you have expected documentation about this additional step
needed?
(The idea behind co-installability is to support live-systems to come
with as many drivers as possible installed and have some hardware
detection script to select the driver to actually use during boot.
I don't know if anyone ever implemented such a script.)
Andreas
