Monday, May 6, 2024
Homepage · nvidia
 Popular · Latest · Hot · Upcoming
14
rated 0 times [  14] [ 0]  / answers: 1 / hits: 30086  / 2 Years ago, mon, july 11, 2022, 10:21:15

I had planned a day of relaxing with Portal 2 but on starting Steam (for the first time in a couple of weeks) I was greeted with the following message in the terminal:



Error: API mismatch: the NVIDIA kernel module has version 270.41.19,

but this NVIDIA driver component has version 270.41.06.  Please make

sure that the kernel module and all NVIDIA driver components

have the same version.


I'll confess I don't really know what it's talking about when it says driver. The verion of nvidia-current is 270.41.19. I thought that was the driver and module, all in one.



I use the X-SWAT PPA and I have noted that the nvidia-settings package has boosted to 275.09.07. As this is just a settings application, I don't think this mismatch has anything to do with this. It's also not the same version as the problem being described.



I'd rather not purge back to the standard Nvidia driver as it's less than stable on my GTX580. I would accept an answer that takes the manual setup and makes it recompile when the kernel recompiles (ie, some DKMS wizardry) but it has to work. I don't want to drop back to text-mode every time I restart after a kernel upgrade.



Edit: Minecraft works without a single complaint about driver versions. Penumbra dies with roughly the same error when entering a game.



Edit: Here's what I'm dealing with in terms of 32bit files. They all seem to be at the right version.



ls -l /usr/lib32/nvidia-current/ | awk '{ print $8 " " $9 " " $10 }'



libcuda.so -> libcuda.so.270.41.19

libcuda.so.1 -> libcuda.so.270.41.19

libcuda.so.270.41.19  

libGL.la  

libGL.so -> libGL.so.1

libGL.so.1 -> libGL.so.270.41.19

libGL.so.270.41.19  

libnvcuvid.so -> libnvcuvid.so.1

libnvcuvid.so.1 -> libnvcuvid.so.270.41.19

libnvcuvid.so.270.41.19  

libnvidia-cfg.so -> libnvidia-cfg.so.1

libnvidia-cfg.so.1 -> libnvidia-cfg.so.270.41.19

libnvidia-cfg.so.270.41.19  

libnvidia-compiler.so -> libnvidia-compiler.so.1

libnvidia-compiler.so.1 -> libnvidia-compiler.so.270.41.19

libnvidia-compiler.so.270.41.19  

libnvidia-glcore.so.270.41.19  

libnvidia-ml.so -> libnvidia-ml.so.1

libnvidia-ml.so.1 -> libnvidia-ml.so.270.41.19

libnvidia-ml.so.270.41.19  

libnvidia-tls.so.270.41.19  

libnvidia-wfb.so.1 -> libnvidia-wfb.so.270.41.19

libnvidia-wfb.so.270.41.19  

libOpenCL.so -> libOpenCL.so.1

libOpenCL.so.1 -> libOpenCL.so.1.0

libOpenCL.so.1.0 -> libOpenCL.so.1.0.0

libOpenCL.so.1.0.0  

libXvMCNVIDIA_dynamic.so.1 -> libXvMCNVIDIA.so.270.41.19

libXvMCNVIDIA.so -> libXvMCNVIDIA.so.270.41.19

libXvMCNVIDIA.so.1 -> libXvMCNVIDIA.so.270.41.19

libXvMCNVIDIA.so.270.41.19


Edit 2: I might have found something.



Lurking in /usr/lib32/ proper (not the nvidia-current subdir) I found the following:



ls -l /usr/lib32/ | awk '{ print $8 " " $9 " " $10 }' | grep 270



libcuda.so.1 -> libcuda.so.270.41.06

libcuda.so.270.41.06  

libGL.so.1 -> libGL.so.270.41.06

libGL.so.270.41.06  

libnvidia-compiler.so.270.41.06  

libnvidia-glcore.so.270.41.06  

libnvidia-tls.so.270.41.06  

libvdpau.so.1 -> libvdpau.so.270.41.06

libvdpau.so.270.41.06  

libvdpau_trace.so -> vdpau/libvdpau_trace.so.270.41.06


For some reason everything in /usr/lib32/nvidia-current/ is the right version but there's a load of cruft in /usr/lib32/ that might be ruining the party.



Edit 3: Trying to track down which package owns these files has failed:



find /usr/lib32 -iname '*270.41.06*' -exec dpkg -S "{}" ;



dpkg-query: no path found matching pattern /usr/lib32/libnvidia-compiler.so.270.41.06.

dpkg-query: no path found matching pattern /usr/lib32/libGL.so.270.41.06.

dpkg-query: no path found matching pattern /usr/lib32/vdpau/libvdpau_nvidia.so.270.41.06.

dpkg-query: no path found matching pattern /usr/lib32/vdpau/libvdpau_trace.so.270.41.06.

dpkg-query: no path found matching pattern /usr/lib32/libvdpau.so.270.41.06.

dpkg-query: no path found matching pattern /usr/lib32/tls/libnvidia-tls.so.270.41.06.

dpkg-query: no path found matching pattern /usr/lib32/libnvidia-tls.so.270.41.06.

dpkg-query: no path found matching pattern /usr/lib32/libcuda.so.270.41.06.

dpkg-query: no path found matching pattern /usr/lib32/libnvidia-glcore.so.270.41.06.


Any tips on how I should deal with these broken versions? Delete them? Delete then symlink to ./nvidia-current/ versions?


More From » nvidia
 Answers
3

On finding out there were a load of old files crufting up /usr/lib32/ I moved them out the way with the following command:


sudo find /usr/lib32 -iname '*270.41.06*' -exec mv {} {}.old ;

And restarted X. This broke everything 3D. Huzzah. Using a previous commend I could see there were four broken links:


ls -l /usr/lib32/ | awk '{ print $8 " " $9 " " $10 }' | grep 270



libcuda.so.1 -> libcuda.so.270.41.06

libGL.so.1 -> libGL.so.270.41.06

libvdpau.so.1 -> libvdpau.so.270.41.06

libvdpau_trace.so -> vdpau/libvdpau_trace.so.270.41.06

Rather than manually replace the links for four files, I went to Elrond, Lord of Rivendell and tasked him with setting up a fellowship that could trapse into Morhdorh, toddle up to Mount Doom and craft me one command to bring me (and by that I do mean us all) and in the darkness bind us.


Enough of that. Here is the one command:


ls -l /usr/lib32/ | awk '{ print $8 " " $9 " " $10 }' | grep 270 | cut -d' ' -f1 | xargs -l1 sudo bash -c "rm /usr/lib32/$0 && ln -s /usr/lib32/nvidia-current/$0 /usr/lib32/$0"

Isn't she spectacular. And it worked. I now have 4 shiny new symlinks:


ls -l /usr/lib32/ | awk '{ print $8 " " $9 " " $10 }' | grep '/nvidia-current'



libcuda.so.1 -> /usr/lib32/nvidia-current/libcuda.so.1

libGL.so.1 -> /usr/lib32/nvidia-current/libGL.so.1

libOpenCL.so -> nvidia-current/libOpenCL.so

libvdpau.so.1 -> /usr/lib32/nvidia-current/libvdpau.so.1

libvdpau_trace.so -> /usr/lib32/nvidia-current/libvdpau_trace.so

I then checked to see if everything had worked. Before restarting I thought I should check to see if the links were correct:


ls -l /usr/lib32/ | awk '{ print $8 " " $9 " " $10 }' | grep '/nvidia-current' | cut -d' ' -f3 | xargs file



/usr/lib32/nvidia-current/libcuda.so.1:      symbolic link to `libcuda.so.270.41.19'

/usr/lib32/nvidia-current/libGL.so.1:        symbolic link to `libGL.so.270.41.19'

/usr/lib32/nvidia-current/libvdpau.so.1:     ERROR: cannot open `/usr/lib32/nvidia-current/libvdpau.so.1' (No such file or directory)

/usr/lib32/nvidia-current/libvdpau_trace.so: ERROR: cannot open `/usr/lib32/nvidia-current/libvdpau_trace.so' (No such file or directory)

Great. So the mega-command only did two links right. After looking a little further, it seems the libvdpau files actually live in /usr/lib32/nvidia-current/vdpau/. No messing about this time:


sudo rm /usr/lib32/libvdpau{,_trace}.so*

sudo ln -s /usr/lib32/{nvidia-current/vdpau/,}libvdpau.so*

sudo ln -s /usr/lib32/{nvidia-current/vdpau/,}libvdpau_trace.so*



ls -l /usr/lib32/ | awk '{ print $8 " " $9 " " $10 }' | grep '/nvidia-current' | cut -d' ' -f3 | xargs file



/usr/lib32/nvidia-current/libcuda.so.1:                      symbolic link to `libcuda.so.270.41.19'

/usr/lib32/nvidia-current/libGL.so.1:                        symbolic link to `libGL.so.270.41.19'

/usr/lib32/nvidia-current/vdpau/libvdpau.so.270.41.19:       ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

/usr/lib32/nvidia-current/vdpau/libvdpau_trace.so.270.41.19: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

At least they're properly (if a little ungainily) linked in. Time to test.


Edit: This worked but learn from my struggle: Keep it simple.


[#44455] Monday, July 11, 2022, 2 Years  [reply] [flag answer]
Only authorized users can answer the question. Please sign in first, or register a free account.
sertold
Add To Favorites
Follow
Total Points: 445
Total Questions: 123
Total Answers: 113
Location: Burundi
Member since Wed, Sep 28, 2022
2 Years ago
;