Hi again
Just to report back on this, the issue was my find
command: by filtering for type -f
I inadvertently missed the libnvoptix.so.1
symlink in /usr/lib/x86_64-linux-gnu
, so there were actually two libnvoptix.so.1
files.
sudo
commands were reading the /usr/lib/x86_64-linux-gnu
one, whereas default user commands were trying to use /usr/lib/wsl/lib/libnvoptix.so.1
, which was just a stub. strace
showed this difference, for those curious:
sudo strace -f -e trace=file -o strace.sudo.log {MY_COMMAND}
strace -f -e trace=file -o strace.nosudo.log {MY_COMMAND}
diff -u <(grep -i libnvoptix strace.sudo.log) <(grep -i libnvoptix strace.nosudo.log)
The diff showed:
-18836 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnvoptix.so.1", O_RDONLY|O_CLOEXEC) = 18
vs
+19024 openat(AT_FDCWD, "/usr/lib/wsl/lib/libnvoptix.so.1", O_RDONLY|O_CLOEXEC) = 18
I fixed it by copying across the library from /usr/lib/x86_64-linux-gnu/libnvoptix.so.570.144
to /usr/lib/wsl/lib/
and renaming it to /libnvoptix.so.1
, which is part of the instructions in the workaround forum post for Optix here.
I had previously tried that workaround without success, I think probably because of not properly matching the windows driver version to a compatible linux driver version, but I’m guessing. In the workaround instructions it doesn’t detail which Linux driver to use for your chosen windows driver, which may be helpful to add.
So I ended up installing the Linux driver in WSL on top of the Windows driver, which is what “worked” and gave my sudo commands access to Optix. I chose a Linux driver in the same family (560) to my Windows one and it seems to be compatible, though I may have broken other things I don’t know about yet.