search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
16.95k stars 798 forks source link

Running `shutdown` from within Linux with systemd enabled breaks population of Windows PATH entries #10727

Open reynoldsa opened 8 months ago

reynoldsa commented 8 months ago

Windows Version

23580.1000

WSL Version

2.0.6.0

Are you using WSL 1 or WSL 2?

Kernel Version

5.15.133

Distro Version

Debian (unstable, custom distro)

Other Software

No response

Repro Steps

  1. Boot any Linux distro with systemd enabled (I tested and this does work on other ones than my Debian install)
  2. Run sudo shutdown -h now as one would on a "normal" Linux machine

Expected Behavior

  1. The distro shuts down and the WSL process used to launch the session exits
  2. The distro starts up normally the next time it is launched

Actual Behavior

  1. The distro shuts down and the WSL process used to launch the session exits
  2. Next time the distro starts up, there are lots of errors about being unable to parse PATH entries, and $PATH does not contain Windows entries. Example errors are below - there is one for each windows PATH entry:

<3>WSL (244) ERROR: UtilTranslatePathList:2853: Failed to translate C:\Program Files\PowerShell\7\

Screenshot 2023-11-08 151314

Diagnostic Logs

WslLogs-2023-11-08_15-12-33.zip

LLQWQ commented 8 months ago

Hello, have you found a solution? I have encountered the same issue.

Throne3d commented 8 months ago

I seem to have a similar issue - I don't remember forcing a shutdown, but I did have systemd enabled and subsequently ran do-release-upgrade on Ubuntu (which seems to force a shutdown + stops WSL at the end), and I'm getting a similar issue now.

I described my issue a bit more in https://github.com/microsoft/WSL/issues/9360#issuecomment-1810569798. It seems like adding this to .wslconfig might have temporarily mitigated the issue:

[wsl2]
virtio9p=false

I'm not sure what the implications are of this config, but at least in my case, this seems to have allowed /mnt/c to get populated and I'm no longer seeing these errors. I'm not sure what would have caused the underlying problem, though - it would be great to resolve that fully!

ciprianglg commented 8 months ago

I had the same problem on the latest version of wsl 2.0.9 and win 11 22h2, using Debian and seems this error is triggered by the fact c drive is not being mounted, and then these path's are not available. I removed everything and installed package 2.0.0 for wsl, and here the problem is the same. To replicate it, after installation just perform wsl --shutdown Debian and then open it again, and you will have the errors related to the paths, and also C: drive is not mounted. You need to perform multiple times wsl --shutdown Debian or --terminate, and then works for some time, but then after reboot, happens again. I think i will move to 1.2.5.0 until this will be resolved

amahpour commented 8 months ago

I am also running WSL 2.0.9 and Windows 11 22h2. I tried everything above and still have the issue intermittently. I've been running WSL 2 since it came out and only recently ran into this issue. I'm not convinced downgrading to WSL 1 is the best solution...

Throne3d commented 7 months ago

It seems like virtio9p has been disabled by default in the latest release - https://github.com/microsoft/WSL/releases/tag/2.0.11

At least in the other thread about a similar issue, several people reported that disabling virtio9p helped out (https://github.com/microsoft/WSL/issues/9360#issuecomment-1811909290), so for anyone stumbling across this issue when searching for "UtilTranslatePathList", maybe upgrading to the latest version of WSL2 will help out. It seems like this issue is being worked on actively!

I'm not sure what's going on for other people in this thread, though, if disabling virtio9p didn't solve it =/ Maybe try upgrading to the latest version of WSL 2 anyway and see?

DarthPjotr commented 7 months ago

I have the same problem. Killing all wsl* processes, including wslservice.exe solved the problem for me.

ciprianglg commented 5 months ago

Did somebody tried to run wsl explicitly with admin rights? On my side i never had problems running it like this. If i open it without admin rights the problem is happening randomly, sometime after reboot, c drive is mounted, other times is not. When is not mounting it, i'm just trying wsl --terminate Debian, and after, it just opens without any problem, but are times when maybe neither this is not working. If somebody know how to debug, or what kind of logging i should enable please let me know. Only stable version where this is not happening is https://github.com/microsoft/WSL/releases/tag/1.2.5