libcuda.so.1 is not a symbolic link #5548

sirredbeard · 2020-07-06T15:53:46Z

This is cross-post of Ubuntu bug 1886532 which is pending investigation.

On Windows 10 build 20161 WSL2 running sudo apt upgrade results in warning:

"libcuda.so.1 is not a symbolic link"

It appears to be a result of a postinst hook in libc-bin.

https://bugs.launchpad.net/ubuntuwsl/+bug/1886532

therealkenc · 2020-07-06T20:36:41Z

Yeah, copies not symlinks.

aricursion · 2020-09-07T02:19:15Z

Is there a solution for this? My /usr/lib/wsl/lib looks exactly like this. Where do I need symlinks and from where to where?

therealkenc · 2020-09-07T15:41:39Z

It's in %SYSTEMROOT%\System32\lxss\lib. It might be possible to make it a symlink in that folder, though I haven't tried and mucking your System32 is not recommended for lots of good reasons. You could also probably make the warning go away by mount binding a symlink over the file on the WSL side. Haven't tried that either.

Thus far the warning hasn't proved blocking in any way. It isn't even that clear (to me) why ldconfig feels inclined to point it out, because there isn't anything technically "wrong" with the file not being a symlink, except for violating a convention. Absent some heretofore unstated blocking use-case, the smart play ("solution") is to ignore the warning.

aricursion · 2020-09-09T02:46:45Z

What would cause problems with symlinking from system32. Like I know generally altering system32 is bad, but would symlinks cause problems?

wanfuse123 · 2020-09-19T15:49:40Z

Directory of C:\Windows\System32\lxss\lib

09/18/2020 03:53 PM

.
08/30/2020 09:51 AM 124,664 libcuda.so
09/12/2020 08:44 AM 832,936 libd3d12.so
09/12/2020 08:44 AM 5,073,944 libd3d12core.so
09/12/2020 08:44 AM 25,069,816 libdirectml.so
09/12/2020 08:44 AM 878,768 libdxcore.so
08/30/2020 09:51 AM 40,496,936 libnvwgf2umx.so
6 File(s) 72,477,064 bytes
1 Dir(s) 643,723,309,056 bytes free

C:\Windows\System32\lxss\lib>mklink libcuda.so.1 libcuda.so
symbolic link created for libcuda.so.1 <<===>> libcuda.so

wanfuse123 · 2020-09-19T21:02:22Z

simlynk generates new error

sudo docker run --rm --gpus all nvidia/cuda:11.0-base nvidia-smi
Failed to initialize NVML: Unknown Error

wanfuse123 · 2020-09-19T21:06:05Z

docker run --gpus all nvcr.io/nvidia/k8s/cuda-sample:nbody nbody -privileged -gpu -benchmark
Run "nbody -benchmark [-numbodies=]" to measure performance.
-fullscreen (run n-body simulation in fullscreen mode)
-fp64 (use double precision floating point values for simulation)
-hostmem (stores simulation data in host memory)
-benchmark (run benchmark to measure performance)
-numbodies= (number of bodies (>= 1) to run in simulation)
-device= (where d=0,1,2.... for the CUDA device to use)
-numdevices= (where i=(number of CUDA devices > 0) to use for simulation)
-compare (compares simulation results running once on the default GPU and once on the CPU)
-cpu (run n-body simulation on the CPU)
-tipsy=<file.bin> (load a tipsy model file for simulation)

NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled.

Error: only 0 Devices available, 1 requested. Exiting.

NOTE: the -privileged switch changes the error from above

PeerXu · 2020-10-09T08:01:50Z

$ sudo docker run --gpus all nvcr.io/nvidia/k8s/cuda-sample:nbody nbody -privileged -gpu -benchmark
CUDA error at bodysystemcuda_impl.h:159 code=46(cudaErrorDevicesUnavailable) "cudaEventCreate(&m_deviceData[0].event)" 
Run "nbody -benchmark [-numbodies=<numBodies>]" to measure performance.
	-fullscreen       (run n-body simulation in fullscreen mode)
	-fp64             (use double precision floating point values for simulation)
	-hostmem          (stores simulation data in host memory)
	-benchmark        (run benchmark to measure performance) 
	-numbodies=<N>    (number of bodies (>= 1) to run in simulation) 
	-device=<d>       (where d=0,1,2.... for the CUDA device to use)
	-numdevices=<i>   (where i=(number of CUDA devices > 0) to use for simulation)
	-compare          (compares simulation results running once on the default GPU and once on the CPU)
	-cpu              (run n-body simulation on the CPU)
	-tipsy=<file.bin> (load a tipsy model file for simulation)

NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled.

> Windowed mode
> Simulation data stored in video memory
> Single precision floating point simulation
> 1 Devices used for simulation
GPU Device 0: "GeForce GTX 1080" with compute capability 6.1

> Compute 6.1 CUDA device: [GeForce GTX 1080]

wanfuse123 · 2020-10-09T10:35:17Z

What happens if tou ad -- compair after benchmark ? Forget it if one or two dashes

Shohou · 2020-11-10T12:35:25Z

/usr/lib/wsl/lib is included through /etc/ld.so.conf.d. You will find a file there with instructions how to prevent its generation. You have to delete that file and create /etc/wsl.conf with the fillowing lines:

[automount]
ldconfig = false

thierryherrmann · 2020-11-16T02:42:26Z

Same problem here using Win 10 build 20257.1 both with ubuntu 18.04 and ubuntu 20.04 (kernel 4.19.128).
Problem shows up either through sudo apt-get install -y nvidia-docker2 or sudo apt-get install -y cuda-toolkit-11-0, two steps mentioned in the official NVidia CUDA-wsl procedure.
Must have worked at some point but something must have been broken

ligewu · 2021-01-03T06:20:47Z

disable automount in /etc/wsl.conf

[automount]
ldconfig = false

copy /usr/lib/wsl/lib to /usr/lib/wsl2/lib (in wsl, writable)
edit /etc/ld.so.conf.d/ld.wsl.conf

/usr/lib/wsl/lib --> /usr/lib/wsl2/lib (new location)

rm /usr/lib/wsl2/lib/libcuda.so.* and sudo ldconfig

works for CUDA in WSL, but "Segmentation fault" in DirectML

ImanHosseini · 2021-08-27T04:20:24Z

Will this issue ever be fixed?

sryio · 2021-09-03T12:19:33Z

There is another solution works for me :

Open cmd as Administrator and cd into C:\Windows\System32\lxss\lib
Delete libcuda.so and libcuda.so.1 (You can also do this in Windows Explorer as well)
Run wsl -e /bin/bash in cmd and you should already in /mnt/c/Windows/System32/lxss/lib, now you have permission to create symlink:

    ln -s libcuda.so.1.1 libcuda.so.1
    ln -s libcuda.so.1.1 libcuda.so

Done.

Soooda · 2021-10-07T20:19:48Z

Having this output running sudo zypper install <packages> on openSUSE-42 distro.

(3/7) Installing: libtermkey1-0.18-1.1.x86_64 ....................................................................[done]
Additional rpm output:
/sbin/ldconfig: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link



(4/7) Installing: libunibilium0-1.2.0-1.1.x86_64 .................................................................[done]
Additional rpm output:
/sbin/ldconfig: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link



(5/7) Installing: libuv1-1.6.1-5.4.x86_64 ........................................................................[done]
Additional rpm output:
/sbin/ldconfig: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link



(6/7) Installing: libvterm0-0~bzr681-1.11.x86_64 .................................................................[done]
Additional rpm output:
/sbin/ldconfig: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link

Just upgraded to Windows 11 and installed 510.06_gameready_win11_win10-dch_64bit_international.exe following Run Linux GUI apps on WSL
Does anyone encounter a similar issue?

donalhunt · 2021-10-11T16:33:01Z

There is another solution works for me :

Open cmd as Administrator and cd into C:\Windows\System32\lxss\lib

Delete libcuda.so and libcuda.so.1 (You can also do this in Windows Explorer as well)

Run wsl -e /bin/bash in cmd and you should already in /mnt/c/Windows/System32/lxss/lib, now you have permission to create symlink:
    ln -s libcuda.so.1.1 libcuda.so.1
    ln -s libcuda.so.1.1 libcuda.so
Done.

This solution worked for me with the addition of granting permissions on the lib folder to my regular (non-admin) user. Don't forget to revert the permissions afterwards. ;)

amaleewilson · 2021-10-23T03:57:12Z

Having this output running sudo zypper install <packages> on openSUSE-42 distro.

(3/7) Installing: libtermkey1-0.18-1.1.x86_64 ....................................................................[done]
Additional rpm output:
/sbin/ldconfig: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link



(4/7) Installing: libunibilium0-1.2.0-1.1.x86_64 .................................................................[done]
Additional rpm output:
/sbin/ldconfig: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link



(5/7) Installing: libuv1-1.6.1-5.4.x86_64 ........................................................................[done]
Additional rpm output:
/sbin/ldconfig: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link



(6/7) Installing: libvterm0-0~bzr681-1.11.x86_64 .................................................................[done]
Additional rpm output:
/sbin/ldconfig: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link

Just upgraded to Windows 11 and installed 510.06_gameready_win11_win10-dch_64bit_international.exe following Run Linux GUI apps on WSL Does anyone encounter a similar issue?

Exact same issue. Solution below worked for me, too.

There is another solution works for me :

* Open cmd as Administrator and cd into C:\Windows\System32\lxss\lib

* Delete libcuda.so and libcuda.so.1 (You can also do this in Windows Explorer as well)

* Run `wsl -e /bin/bash` in cmd and you should already in `/mnt/c/Windows/System32/lxss/lib`, now you have permission to create symlink:

    ln -s libcuda.so.1.1 libcuda.so.1
    ln -s libcuda.so.1.1 libcuda.so

Done.

EvanThomasKaduthanam · 2021-11-03T07:09:46Z

I am new to this, and I din't get what you sould do in the solution u all said works...

I deleted libcuda.so and libcuda.so.1 using File Explorer, now I am having trouble figuring out the next part, thank you in advance!

LanceMcCarthy · 2021-11-11T13:55:48Z

I am new to this, and I din't get what you sould do in the solution u all said works...

I deleted libcuda.so and libcuda.so.1 using File Explorer, now I am having trouble figuring out the next part, thank you in advance!

Here are the exact steps:

wswind · 2021-12-10T01:51:04Z

I don't want to delete anything under System32
Make symbolic links in another folder like /usr/lib/wsl/lib2 would fix this in wsl.

add ldconfig = false to /etc/wsl.conf

echo -e "[automount]\nldconfig = false" | sudo tee -a /etc/wsl.conf

make the symbolic link and use it

sudo mkdir /usr/lib/wsl/lib2
sudo ln -s /usr/lib/wsl/lib/* /usr/lib/wsl/lib2
echo /usr/lib/wsl/lib2 | sudo tee /etc/ld.so.conf.d/ld.wsl.conf

SuperSandro2000 · 2022-01-07T19:09:02Z

/mnt/c/Windows/System32/lxss/lib

Works on my machine.

Why isn't this not fixed by WSL already?

SofiaXu · 2022-01-14T03:20:49Z

Run CMD in Windows(as Administrator)
cd %SYSTEMROOT%\System32\lxss\lib
del libcuda.so
mklink libcuda.so libcuda.so.1
Run wsl
sudo ldconfig
done
libcuda.so, libcuda.so.1 and libcuda.so.1.1 are same file because they have same hash.

Purpzie · 2022-03-03T17:05:30Z

This also happens in Arch whenever you use pacman. It seems like this isn't limited to Ubuntu. (Note: I used wsl --import with Arch's official bootstrap, not the hacky ArchWSL.)

[2022-03-03T10:28:49-0600] [ALPM-SCRIPTLET] ldconfig: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link

petemoore · 2022-08-05T08:17:25Z

Can this issue be given the "bug" label?
Are there any plans for a fix?
Thanks.

NotTheDr01ds · 2022-08-24T01:55:49Z

Primarily for Windows 11 users (since it uses the [boot].command option in /etc/wsl.conf) -- A slight improvement to the excellent suggestion by @wswind. This approach builds on that one, but doesn't require any change to /etc/ld.so.conf.d/ld.wsl.conf:

One time configuration:

sudo mount --bind /usr/lib/wsl/lib /usr/lib/wsl/lib2 -o X-mount.mkdir
sudo umount /usr/lib/wsl/lib
sudo ln -s /usr/lib/wsl/lib2/* /usr/lib/wsl/lib

Then add the following to /etc/wsl.conf:

[boot]
command = sleep 10 ; mount --bind /usr/lib/wsl/lib /usr/lib/wsl/lib2 -o X-mount.mkdir ; umount /usr/lib/wsl/lib

That:

Bind mounts the ../wsl/lib to ../wsl/lib2 (essentially creates a copy of the mount)
Unmounts the original /usr/lib/wsl/lib
Creates the symlinks so that they live in the directory ldconfig expects
On subsequent boots, the symlinks will already exist in the filesystem, but the /init generated automount will be "hiding" them (and they'd be broken symlinks anyway until the location they are pointing to is mounted). Mounting the bind-mount and unmounting the init-generated one (via /etc/wsl.conf) will cause them to show up and be valid.

It's also possible to get this running on Windows 10 using a wsl.exe -u root mount ... command-line somewhere in your shell startup. If anyone wants help with that, let me know.

Side-note: It might be better to delete and regenerate all of the symlinks on each restart of the WSL distribution anyway. This would make sure that any changes to the libs in a new WSL release are properly symlinked.

nchj · 2022-09-12T13:44:29Z

After two years of discussion
Microsoft still has not marked this as a bug
nor has it provided an official solution
But this problem affects everyone who uses GPU in WSL2
It Really Sucks

julianxhokaxhiu · 2023-07-08T13:03:45Z

I don't want to delete anything under System32 Make symbolic links in another folder like /usr/lib/wsl/lib2 would fix this in wsl.

add ldconfig = false to /etc/wsl.conf
echo -e "[automount]\nldconfig = false" | sudo tee -a /etc/wsl.conf
make the symbolic link and use it
sudo mkdir /usr/lib/wsl/lib2
sudo ln -s /usr/lib/wsl/lib/* /usr/lib/wsl/lib2
echo /usr/lib/wsl/lib2 | sudo tee /etc/ld.so.conf.d/ld.wsl.conf

This should be flagged as the real workaround until an official fix is provided. @craigloewen-msft is it possible to have a bit of attention on this one? Should be trivial to be fixed. Thank you

RandomDSdevel · 2023-07-09T02:58:43Z

I've also been seeing this issue for quite some time. I'm running a custom WSL2 image initially generated from what was then the latest upstream Gentoo 'stage3' tarball as of some time on February 26^th, 2022 using the instructions from here and the relevant Gentoo Wiki page. I've kept both the default, main Gentoo ebuild repository and another ebuild repository I added later synced and kept my packages up to date by re-'emerge'ing them as needed, alongside other package administration/maintenance. This all started back on some version of 64-bit Intel Windows 10 Pro 21H2 — I think that's what must've come with my system, IIRC? —, but I've obviously run several Windows OS and Microsoft Store app updates since then and am currently now on:

64-bit Intel Windows 11 Pro 22H2, build 22621.1928
Windows Feature Experience Pack v1000.22644.1000.0

This has all worked rather well, for the most part. I'm not going to mess with my System32 folder or any other Windows OS folders/files, obviously, or any WSL2 filesystem mappings. I'll just wait for an official fix to land.

Edit: I forgot to mention that I'm also currently using:

PowerShell 7.3.5
PS C:\Users\zadmin> wsl --version
WSL version: 1.2.5.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
# (Snipped…)

avysk · 2023-07-28T16:35:00Z

Just mentioning: this issue was opened more than 3 years ago...

DeForestDiamond · 2023-07-28T16:42:07Z

It's Microsoft, we can't expect much...

ackalker · 2023-09-16T20:39:56Z

If no-one at Microsoft gets @mentioned, I don't think much will happen, as this issue has most likely sunk to the bottom of the pile.

d3vv · 2023-09-17T07:12:25Z

 wsl -v
WSL version: 1.2.5.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.2416

# ldconfig
ldconfig: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link

Is there any progress here?

wizpresso-steve-cy-fan · 2023-10-11T07:51:22Z

I believe there is a bigger problem on Nvidia side. If I do a soft symlink libcuda.so.1.1 to libcuda.so.1 and libcuda.so respectively in /mnt/c/Windows/System32/lxss/lib, docker run --gpus all nvcr.io/nvidia/k8s/cuda-sample:nbody would fail to launch. I do a hard link for now but I'm not sure if that's viable

mosullivan93 · 2023-10-20T12:13:09Z

I was curious about how to fix this while minimising the changes I needed to make to any system files and I came up with an alternative fix that is applicable to certain WSL installations and doesn't involve deleting anything in System32.

If your WSL is in C:\Program Files\WSL (as opposed to C:\Program Files\WindowsApps\MicrosoftCorporation.blahblahblah), then you can take advantage of the way WSL overlays its packaged libraries atop the system's libraries and fix the problem without needing to modify the files under C:\Windows\System32\lxss\lib.

You can check where wslservice.exe is by running: wmic service where name="wslservice" get pathname

You can create the links that ldconfig wants yourself in C:\Program Files\WSL\lib and they'll override the problematic files in your user distributions, and, importantly, the WSLg/System distribution. From an elevated CMD prompt run:

mklink "C:\Program Files\WSL\lib\libcuda.so.1" libcuda.so.1.1
mklink "C:\Program Files\WSL\lib\libnvoptix_loader.so.1" libnvoptix.so.1

Otherwise, if your wslservice.exe is in a protected location (e.g. WindowsApps) then the next least destructive option is simply renaming libcuda.so.1 using rename %SystemRoot%\System32\lxss\lib\libcuda.so.1 libcuda.so.1.bak. The only downside to this is that in your user distribution you would still need to run sudo ldconfig every boot to create the missing symlinks.

avysk · 2023-10-21T09:11:48Z

Hello, anyone from Microsoft here? The bug is laughably old.

vinberg88 · 2023-11-09T12:36:11Z

Paste in Console - Terminal =)

ln -s libcuda.so.1.1 libcuda.so.1
ln -s libcuda.so.1.1 libcuda.so
echo -e "[automount]\nldconfig = false" | sudo tee -a /etc/wsl.conf
sudo mkdir /usr/lib/wsl/lib2
sudo ln -s /usr/lib/wsl/lib/* /usr/lib/wsl/lib2
echo /usr/lib/wsl/lib2 | sudo tee /etc/ld.so.conf.d/ld.wsl.conf

alanlivio · 2023-11-13T11:19:51Z

Rephrasing @nchj: "After ~~two~~ three years of discussion Microsoft still has not marked this as a bug
nor has it provided an official solution"

kizmat · 2023-12-28T07:01:50Z

@wswind #5548 (comment) -Thanks!

I don't want to delete anything under System32 Make symbolic links in another folder like /usr/lib/wsl/lib2 would fix this in wsl.

add ldconfig = false to /etc/wsl.conf
echo -e "[automount]\nldconfig = false" | sudo tee -a /etc/wsl.conf
make the symbolic link and use it
sudo mkdir /usr/lib/wsl/lib2
sudo ln -s /usr/lib/wsl/lib/* /usr/lib/wsl/lib2
echo /usr/lib/wsl/lib2 | sudo tee /etc/ld.so.conf.d/ld.wsl.conf

This seemed to have solved it for me.
Thank you.

wswind · 2023-12-28T07:13:49Z

@wswind #5548 (comment) -Thanks!
I don't want to delete anything under System32 Make symbolic links in another folder like /usr/lib/wsl/lib2 would fix this in wsl.

add ldconfig = false to /etc/wsl.conf
echo -e "[automount]\nldconfig = false" | sudo tee -a /etc/wsl.conf
make the symbolic link and use it
sudo mkdir /usr/lib/wsl/lib2
sudo ln -s /usr/lib/wsl/lib/* /usr/lib/wsl/lib2
echo /usr/lib/wsl/lib2 | sudo tee /etc/ld.so.conf.d/ld.wsl.conf
This seemed to have solved it for me. Thank you.

Haha, it's my pleasure. I switched to a laptop without nvidia graphics card and haven't seen this problem since then.

I'm impressed that this issue hasn't been fixed after all these years.. 😂

alanlivio · 2024-01-03T16:17:55Z

Hi all. I still have this problem. Is there no official solution from the WSL team?

imaspol · 2024-01-12T14:17:09Z

Hi all, I've just run into the same bug when installing nvidia drivers into wsl:
sudo apt-get install -y cuda-drivers
The message I've got:
/sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link
Hope my message will wake up the issue...

matbee-eth · 2024-01-25T23:09:31Z

##5548 (comment)
You may have to rebuild your nvidia docker containers for them to see the updated symlinks

infish155 · 2024-02-14T12:24:24Z

What would happen if I just ignore it? I dont dare to do anything without official solusion.

NotTheDr01ds · 2024-02-15T12:55:49Z

@infish155 Per the thread above, nothing seems to actually be broken by the error. Ignoring it is just fine - That's what most others are doing in the meantime :-)

BraveDrXuTF · 2024-03-07T03:44:28Z

There is another solution works for me :

Open cmd as Administrator and cd into C:\Windows\System32\lxss\lib

Delete libcuda.so and libcuda.so.1 (You can also do this in Windows Explorer as well)

Run wsl -e /bin/bash in cmd and you should already in /mnt/c/Windows/System32/lxss/lib, now you have permission to create symlink:
    ln -s libcuda.so.1.1 libcuda.so.1
    ln -s libcuda.so.1.1 libcuda.so
Done.

“failed to create symbolic link 'libcuda.so.1': Permission denied”, what should I do sir

BraveDrXuTF · 2024-03-07T04:00:34Z

There is another solution works for me :

Open cmd as Administrator and cd into C:\Windows\System32\lxss\lib

Delete libcuda.so and libcuda.so.1 (You can also do this in Windows Explorer as well)

Run wsl -e /bin/bash in cmd and you should already in /mnt/c/Windows/System32/lxss/lib, now you have permission to create symlink:
    ln -s libcuda.so.1.1 libcuda.so.1
    ln -s libcuda.so.1.1 libcuda.so
Done.
“failed to create symbolic link 'libcuda.so.1': Permission denied”, what should I do sir

fixed with cmd admin, but another problem arises: CUDA backend failed to initialize: FAILED_PRECONDITION: No visible GPU devices.

rodgermoore · 2024-03-20T15:33:42Z

Hi all, I've just run into the same bug when installing nvidia drivers into wsl: sudo apt-get install -y cuda-drivers The message I've got: /sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link Hope my message will wake up the issue...

Once a Windows NVIDIA GPU driver is installed on the system, CUDA becomes available within WSL 2. The CUDA driver installed on Windows host will be stubbed inside the WSL 2 as libcuda.so, therefore users must not install any NVIDIA GPU Linux driver within WSL 2.

Source

BHare1985 · 2024-03-24T22:28:31Z

Running into this myself with both Ubuntu and Debian from the Microsoft Store.

This solved it when run inside the linux terminal:

cd /usr/lib/wsl/lib
sudo rm libcuda.so libcuda.so.1
sudo ln -s libcuda.so.1.1 libcuda.so.1
sudo ln -s libcuda.so.1 libcuda.so
sudo ldconfig

RyanbowZ · 2024-04-07T02:44:35Z

remember to execute sudo ldconfig after softlink in the directory of /usr/lib/wsl/lib, rather than C:\Windows\System32\lxss\lib
Otherwise your NVidia GPU Driver might fail!

cyberluke · 2025-02-15T16:56:17Z

2025 and I still need to waste time with this amateur shyte. All developers should send invoice to MS and NVIDIA for that - especially us business licensed customers - you would see how things would get fixed!!! Even with open-source help they are not able to fix it in Q2/2025

EDIT: Running latest Win 11 Insider + latest WSL2 (wsl --update and so on)

benhillis added the GPU label Jul 7, 2020

therealkenc mentioned this issue Jul 28, 2020

/usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link #5663

Closed

Galaxy-Ding mentioned this issue Mar 5, 2022

The size of the lib folder in the c:\windows\system32\lxss\lib directory is 0 #8124

Closed

2 tasks

leofang mentioned this issue Aug 15, 2022

[Question/Issue] How to install cuquantum on WSL2 Ubuntu-20.04? NVIDIA/cuQuantum#12

Closed

king-11 mentioned this issue Jul 27, 2023

Fedora WSL king-11/dotrc#3

Closed

joehays mentioned this issue Jan 11, 2024

WSL slow startup: PCI VMBus probing: Using version 0x10003 #11009

Closed

github-actions bot mentioned this issue Feb 29, 2024

ldconfig: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link #11229

Open

2 tasks

Doomwhite mentioned this issue Apr 8, 2024

Error in the "make -j$(nproc)" step hubisan/emacs-wsl#63

Closed

pedromoraesh mentioned this issue May 28, 2024

Install problem with -lcuda osai-ai/tensor-stream#40

Closed

xeres added a commit to xeres/dotfiles that referenced this issue Jun 19, 2024

fix(wsl): Add the workaround for microsoft/WSL#5548

b07f5cb

libcuda.so.1 is not a symbolic link #5548

libcuda.so.1 is not a symbolic link #5548

Comments

sirredbeard commented Jul 6, 2020

therealkenc commented Jul 6, 2020

aricursion commented Sep 7, 2020

therealkenc commented Sep 7, 2020

aricursion commented Sep 9, 2020

wanfuse123 commented Sep 19, 2020

wanfuse123 commented Sep 19, 2020

wanfuse123 commented Sep 19, 2020

PeerXu commented Oct 9, 2020

wanfuse123 commented Oct 9, 2020 via email • edited by ghost Loading

Shohou commented Nov 10, 2020

thierryherrmann commented Nov 16, 2020

ligewu commented Jan 3, 2021

ImanHosseini commented Aug 27, 2021

sryio commented Sep 3, 2021 • edited Loading

Soooda commented Oct 7, 2021

donalhunt commented Oct 11, 2021

amaleewilson commented Oct 23, 2021

EvanThomasKaduthanam commented Nov 3, 2021

LanceMcCarthy commented Nov 11, 2021

wswind commented Dec 10, 2021 • edited Loading

SuperSandro2000 commented Jan 7, 2022

SofiaXu commented Jan 14, 2022

Purpzie commented Mar 3, 2022 • edited Loading

petemoore commented Aug 5, 2022

NotTheDr01ds commented Aug 24, 2022 • edited Loading

nchj commented Sep 12, 2022

julianxhokaxhiu commented Jul 8, 2023

RandomDSdevel commented Jul 9, 2023 • edited Loading

avysk commented Jul 28, 2023

DeForestDiamond commented Jul 28, 2023

ackalker commented Sep 16, 2023

d3vv commented Sep 17, 2023

wizpresso-steve-cy-fan commented Oct 11, 2023

mosullivan93 commented Oct 20, 2023 • edited Loading

avysk commented Oct 21, 2023

vinberg88 commented Nov 9, 2023 • edited Loading

alanlivio commented Nov 13, 2023

kizmat commented Dec 28, 2023 • edited Loading

wswind commented Dec 28, 2023 • edited Loading

alanlivio commented Jan 3, 2024

imaspol commented Jan 12, 2024

matbee-eth commented Jan 25, 2024 • edited Loading

infish155 commented Feb 14, 2024

NotTheDr01ds commented Feb 15, 2024

BraveDrXuTF commented Mar 7, 2024

BraveDrXuTF commented Mar 7, 2024

rodgermoore commented Mar 20, 2024

BHare1985 commented Mar 24, 2024

RyanbowZ commented Apr 7, 2024

cyberluke commented Feb 15, 2025 • edited Loading

wanfuse123 commented Oct 9, 2020 via email •

edited by ghost

Loading

sryio commented Sep 3, 2021 •

edited

Loading

wswind commented Dec 10, 2021 •

edited

Loading

Purpzie commented Mar 3, 2022 •

edited

Loading

NotTheDr01ds commented Aug 24, 2022 •

edited

Loading

RandomDSdevel commented Jul 9, 2023 •

edited

Loading

mosullivan93 commented Oct 20, 2023 •

edited

Loading

vinberg88 commented Nov 9, 2023 •

edited

Loading

kizmat commented Dec 28, 2023 •

edited

Loading

wswind commented Dec 28, 2023 •

edited

Loading

matbee-eth commented Jan 25, 2024 •

edited

Loading

cyberluke commented Feb 15, 2025 •

edited

Loading