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

[PureHing]

Environment

• WIN10 Insider Preview 20175.rs_prerelease.200717-1349
• WSL2 ->ubuntu18.04
• darknet-CUDA

Question

I can successfully use tensorflow-gpu under ubuntu18.04-wsl2 with install 455.41_gameready_win10-dch_64bit_international.exe, but when I start to compile darknet it prompts error :
sh /usr/bin/ld: cannot find -lcuda collect2: error: ld returned 1 exit status
So i execute sudo ldconfig -v:

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

 libcuda.so.1 -> libcuda.so.1.1

Then execute sudo ln -sf /usr/lib/wsl/lib/libcuda.so.1.1 /usr/lib/wsl/lib/libcuda.so.1,
it prompts ln: failed to create symbolic link '/usr/lib/wsl/lib/libcuda.so.1': Read-only file system

How can I successfully compile darknet？Thanks

[therealkenc]

/dupe #5548

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!

[alexcdot]

I was able to build darknet by making a symlink to the directory where the rest of my cuda library files were /usr/local/cuda/lib64 by doing:

sudo ln -s /usr/lib/wsl/lib/libcuda.so.1 /usr/local/cuda/lib64/libcuda.so

With the help of: pjreddie/darknet#1480

[Mulbetty]

I was able to build darknet by making a symlink to the directory where the rest of my cuda library files were /usr/local/cuda/lib64 by doing:

sudo ln -s /usr/lib/wsl/lib/libcuda.so.1 /usr/local/cuda/lib64/libcuda.so

With the help of: pjreddie/darknet#1480

I don't find the folder /usr/lib/wsl, How do you get it ? Or how do you install the cuda?

[alexcdot]

This is specifically for Nvidia CUDA in WSL 2 with the Windows Insider Preview on the Dev Channel. I followed this guide after I had Windows Insider Preview on Dev Channel set up: https://docs.microsoft.com/en-us/windows/win32/direct3d12/gpu-cuda-in-wsl

[John-Joubert]

Please review response post by @PhyX-Meow re: yuk7/ArchWSL#248.
As he points out, it really has nothing to do with your Linux install. It's a simple fix in Windows.
The solution he posts is for Arch, but the fix is exactly same for Ubuntu, etc. in a WSL2 install.
The issue is that Windows delivers libcuda.so, libcuda.so.1, and libcuda.so.1.1 as fully separate copies of the same file.
The fix is just to remove libcuda.so and libcuda.so.1, and just make sym links for each of them to libcuda.so.1.1

Run a command line shell as Administrator, type "cmd" to get a non-powershell command line.

Then type the following commands to create the problematic symbolic links:

C:
cd \Windows\System32\lxss\lib
del libcuda.so
del libcuda.so.1
mklink libcuda.so libcuda.so.1.1
mklink libcuda.so.1 libcuda.so.1.1

when you're done, it will look like this:

C:\Windows\System32\lxss\lib> DIR
... ...
Directory of C:\Windows\System32\lxss\lib
03/15/2022 04:00 PM

.
03/15/2022 03:59 PM libcuda.so [libcuda.so.1.1]
03/15/2022 04:00 PM libcuda.so.1 [libcuda.so.1.1]

Then, just finish your command you were running,
in my case, the solution was just run "apt reinstall libc-bin". This is because libc-bin was getting the errors when I had run "apt upgrade -y" command. (see below)

The error I received in my "apt upgrade -y" command was two lines:
#> apt upgrade -y
.... < stuff deleted > ...
Processing triggers for libc-bin (2.31-0ubuntu9.7) ...
/sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link
... < stuff deleted > ...

As per @PhyX-Meow

"Actually this is not relate to Arch, nor ArchWSL. It's caused by libcuda.so in your C:\Windows\System32\lxss\lib\ folder not a symbolic link, which is installed by nvidia driver. One solution to [remove] the warning is delete libcuda.so and libcuda.so.1 and use make symbolic link to libcuda.so.1.1. Command line: mklink . Note the command not work in powershell, you shall use cmd.exe."

:)

[ArrowRaider]

@John-Joubert
This did not help me. It still says /sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link whenever ldconfig is run.

My directory listing in the one folder is this:

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

06/20/2022  08:48 PM    <DIR>          .
06/20/2022  08:48 PM    <SYMLINK>      libcuda.so [libcuda.so.1.1]
06/20/2022  08:48 PM    <SYMLINK>      libcuda.so.1 [libcuda.so.1.1]
12/15/2021  08:16 AM           141,464 libcuda.so.1.1
06/05/2021  08:06 AM           785,608 libd3d12.so
11/23/2021  01:55 AM         5,398,848 libd3d12core.so
06/05/2021  08:06 AM           827,904 libdxcore.so
12/15/2021  08:16 AM         5,962,912 libnvcuvid.so
12/15/2021  08:16 AM         5,962,912 libnvcuvid.so.1
12/15/2021  08:16 AM           424,400 libnvidia-encode.so
12/15/2021  08:16 AM           424,400 libnvidia-encode.so.1
12/15/2021  08:16 AM           201,880 libnvidia-ml.so.1
12/15/2021  08:16 AM           354,768 libnvidia-opticalflow.so
12/15/2021  08:16 AM           354,768 libnvidia-opticalflow.so.1
12/15/2021  08:16 AM        53,491,712 libnvwgf2umx.so
12/15/2021  08:16 AM           682,488 nvidia-smi

[PhyX-Meow]

@ArrowRaider Try restart wsl2, or restart your pc.

[BrainSlugs83]

@John-Joubert that worked for me... I'm wondering why this bug is closed if we still have to do this manual workaround. -- Why can't this just be fixed in WSL?

[geek111]

Please review response post by @PhyX-Meow re: yuk7/ArchWSL#248. As he points out, it really has nothing to do with your Linux install. It's a simple fix in Windows. The solution he posts is for Arch, but the fix is exactly same for Ubuntu, etc. in a WSL2 install. The issue is that Windows delivers libcuda.so, libcuda.so.1, and libcuda.so.1.1 as fully separate copies of the same file. The fix is just to remove libcuda.so and libcuda.so.1, and just make sym links for each of them to libcuda.so.1.1

Run a command line shell as Administrator, type "cmd" to get a non-powershell command line.

Then type the following commands to create the problematic symbolic links:

C: cd \Windows\System32\lxss\lib del libcuda.so del libcuda.so.1 mklink libcuda.so libcuda.so.1.1 mklink libcuda.so.1 libcuda.so.1.1

when you're done, it will look like this:

C:\Windows\System32\lxss\lib> DIR ... ... Directory of C:\Windows\System32\lxss\lib 03/15/2022 04:00 PM **
** . 03/15/2022 03:59 PM libcuda.so [libcuda.so.1.1] 03/15/2022 04:00 PM libcuda.so.1 [libcuda.so.1.1]

Then, just finish your command you were running, in my case, the solution was just run "apt reinstall libc-bin". This is because libc-bin was getting the errors when I had run "apt upgrade -y" command. (see below)

The error I received in my "apt upgrade -y" command was two lines: #> apt upgrade -y .... < stuff deleted > ... Processing triggers for libc-bin (2.31-0ubuntu9.7) ... /sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link ... < stuff deleted > ...

As per @PhyX-Meow

"Actually this is not relate to Arch, nor ArchWSL. It's caused by libcuda.so in your C:\Windows\System32\lxss\lib\ folder not a symbolic link, which is installed by nvidia driver. One solution to [remove] the warning is delete libcuda.so and libcuda.so.1 and use make symbolic link to libcuda.so.1.1. Command line: mklink . Note the command not work in powershell, you shall use cmd.exe."

:)

When I do this things then have something like this:

RuntimeWarning: Running on CPU now! Make sure your PyTorch version matches your CUDA.The unoptimized RealESRGAN is slow on CPU. If you want to disable it, please remove --bg_upsampler and --face_upsample in command.
warnings.warn('Running on CPU now! Make sure your PyTorch version matches your CUDA.'

And CPU not GPU doing all :(

[thyarles]

Please review response post by @PhyX-Meow re: yuk7/ArchWSL#248. As he points out, it really has nothing to do with your Linux install. It's a simple fix in Windows. The solution he posts is for Arch, but the fix is exactly same for Ubuntu, etc. in a WSL2 install. The issue is that Windows delivers libcuda.so, libcuda.so.1, and libcuda.so.1.1 as fully separate copies of the same file. The fix is just to remove libcuda.so and libcuda.so.1, and just make sym links for each of them to libcuda.so.1.1

Run a command line shell as Administrator, type "cmd" to get a non-powershell command line.

Then type the following commands to create the problematic symbolic links:

C: cd \Windows\System32\lxss\lib del libcuda.so del libcuda.so.1 mklink libcuda.so libcuda.so.1.1 mklink libcuda.so.1 libcuda.so.1.1

when you're done, it will look like this:

**C:\Windows\System32\lxss\lib> DIR ... ... Directory of C:\Windows\System32\lxss\lib 03/15/2022 04:00 PM **

** . 03/15/2022 03:59 PM libcuda.so [libcuda.so.1.1] 03/15/2022 04:00 PM libcuda.so.1 [libcuda.so.1.1]**
Then, just finish your command you were running, in my case, the solution was just run "apt reinstall libc-bin". This is because libc-bin was getting the errors when I had run "apt upgrade -y" command. (see below)

The error I received in my "apt upgrade -y" command was two lines: #> apt upgrade -y .... < stuff deleted > ... Processing triggers for libc-bin (2.31-0ubuntu9.7) ... /sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link ... < stuff deleted > ...

As per @PhyX-Meow

"Actually this is not relate to Arch, nor ArchWSL. It's caused by libcuda.so in your C:\Windows\System32\lxss\lib\ folder not a symbolic link, which is installed by nvidia driver. One solution to [remove] the warning is delete libcuda.so and libcuda.so.1 and use make symbolic link to libcuda.so.1.1. Command line: mklink . Note the command not work in powershell, you shall use cmd.exe."

:)

This approach worked to me, but on the next day my WSL 2 crashed. Then I just give an wsl --update on the PoweShell and it worked again.

[valzargaming]

cd \Windows\System32\lxss\lib del libcuda.so del libcuda.so.1 mklink libcuda.so libcuda.so.1.1 mklink libcuda.so.1 libcuda.so.1.1

I made a slight tweak to your command for anyone struggling getting this to work. Adding && between the various commands ensures proper evaluation from left to right, otherwise users might run into The system cannot find the path specified.

cd C:\Windows\System32\lxss\lib && del libcuda.so && del libcuda.so.1 && mklink libcuda.so libcuda.so.1.1 && mklink libcuda.so.1 libcuda.so.1.1

If the error persists after doing the command, shutdown and restart wsl.

[bhaskoro-muthohar]

Why was this issue closed? The problem still persists for me, and I find myself having to use the manual workaround. Could someone take another look, please?

[HEXDude]

Why was this issue closed? The problem still persists for me, and I find myself having to use the manual workaround. Could someone take another look, please?

I have ran into this problem. @John-Joubert His comments works for me after a WSL restart. You may considering a restart.

[PhyX-Meow]

Why was this issue closed? The problem still persists for me, and I find myself having to use the manual workaround. Could someone take another look, please?

As formerly said, the issue has nothing to do with wsl itself. Linux programs require the file to be a symlink, while nvidia driver installed the file as a regular one. You should go for nvidia driver forum or linux community. We can do nothing here 😞

[parsley72]

Why was this issue closed? The problem still persists for me, and I find myself having to use the manual workaround. Could someone take another look, please?

As formerly said, the issue has nothing to do with wsl itself. Linux programs require the file to be a symlink, while nvidia driver installed the file as a regular one. You should go for nvidia driver forum or linux community. We can do nothing here 😞

Go to https://forums.developer.nvidia.com/t/wsl2-libcuda-so-and-libcuda-so-1-should-be-symlink/236301 and like/comment, maybe we'll get some traction.

[Harry84]

same issue..

[s3rgeym]

PS C:\Users\sergey> 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
Windows version: 10.0.22621.1702

[gomo]

I have created a Tensorflow container in docker installed in WSL, but with this solution, Tensorflow can't find the GPU.

By running some process that produces this error and then putting it back into the file again, Tensorflow can find the GPU.

cd C:\Windows\System32\lxss\lib
ren libcuda.so libcuda.so.bak
ren libcuda.so.1 libcuda.so.1.bak
mklink libcuda.so libcuda.so.1.1
mklink libcuda.so.1 libcuda.so.1.1

Do something that produces this error.

cd C:\Windows\System32\lxss\lib
del libcuda.so
del libcuda.so.1
ren libcuda.so.bak libcuda.so
ren libcuda.so.1.bak libcuda.so.1

[jyono]

same issue.... Does this need to be open?

A manual workaround that requires admin privileges isn't feasible for most.

[Rivgad]

Same issue. The manual binding workaround doesn't seem to help me/

[jibnew]

Same with me. Workaround only survives until next nvidia driver update, then it must be done again.

[BrainSlugs83]

Why was this issue closed? The problem still persists for me, and I find myself having to use the manual workaround. Could someone take another look, please?

Looks like this bug was closed as a duplicate of #5548 -- I totally missed that and thought this was closed because a workaround existed (which would be super lame) -- but it looks like #5548 is still open, so for further discussion we should go there I guess. 🙂

[78Alpha]

This happens to be the first one to show online

[JohnRDOrazio]

I'm noticing that this error (or warning?) is showing when installing python3-pip. At the end of the installation I see:

Processing triggers for man-db (2.10.2-1) ...
Processing triggers for libc-bin (2.35-0ubuntu3.5) ...
/sbin/ldconfig.real: /usr/lib/wsl/lib/libcuda.so.1 is not a symbolic link

When inspecting the /usr/lib/wsl/lib/ folder, I see that in fact there are three files, none of which are symlinks:

-rwxrwxrwx 1 root root        14 Dec 31 03:31 libcuda.so
-rwxrwxrwx 1 root root        14 Dec 31 03:31 libcuda.so.1
-r-xr-xr-x 1 root root    158304 Dec  7 00:05 libcuda.so.1.1

So my fix was not so much to do anything on the Windows side, but rather directly in WSL Ubuntu 22.04:

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

Now when I run sudo apt reinstall libc-bin I no longer get the error (or warning).

UPDATE:
I did also change things on the Windows side as indicated by @John-Joubert :

Run a command line shell as Administrator, type "cmd" to get a non-powershell command line.

Then type the following commands to create the problematic symbolic links:

C: cd \Windows\System32\lxss\lib del libcuda.so del libcuda.so.1 mklink libcuda.so libcuda.so.1.1 mklink libcuda.so.1 libcuda.so.1.1

And after uninstalling Ubuntu 22.04 and re-installing again, I'm seeing that there are now symlinks in the /usr/lib/wsl/lib/ folder. I'm not sure if this is due to changes in the filesystem persisting on the WSL side through a wsl --unregister Ubuntu-22.04 in Powershell and then a re-install (which I highly doubt because my filesystem seems to have a clean slate), or if in the install process it's picking up the changes from the Windows side (most likely the case).

[mcarman]

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

Got this from the nvidia site. I screwed up the link.
If you are on wsl, this may help.
It worked for me

[John-Joubert]

Thanks for the kind update! I simply went there, removed the libcuda.so file, and make a symbolic link to the libcuda.so.1.1 file and named it libcuda.so. And then everything went fine. No extra steps (at least thus far). Thanks for the your kind suggestion, so nice of you!

…

________________________________