"Failed to translate" errors in CreateProcessParseCommon and UtilTranslatePathList #8723
Comments
|
Thanks for reporting this @anthonyvdotbe. What kind of folder is I'd be curious to see the output of |
Thanks for investigating.
It's a regular folder. However, E: is a mounted BitLocker-encrypted .vhdx file, so that might play a role. And the .vhdx file itself is located in my user folder on C:, where C: is the BitLocker-encrypted system partition.
(ETA is an Active Directory domain) |
ghost
removed
the
|
Thank you @anthonyvdotbe. Out of curiosity, do you see the same errors if you start wsl.exe as administrator ? |
|
Im seeing this in WSL2 when attempting to unmount the WSL partition. I also had a BSOD during a termination/unregistration of a newly imported instance after an unmount. The vhdx for this WSL instance is also in a none standard location. The ACL for C:\Windows\system32 And then again when logging into the WSL instance |
|
/logs |
|
Hello! Could you please provide more logs to help us better diagnose your issue? To collect WSL logs, download and execute collect-wsl-logs.ps1 in an administrative powershell prompt: The scipt will output the path of the log file once done. Once completed please upload the output files to this Github issue. Click here for more info on logging Thank you! |
|
Facing the same problem with one of the latest updates. What I did long before was preventing auto-mounts, because I don't want WSL to have access to my Windows directories /etc/wsl.conf stdout |
|
Thank you @mklueh. Can you share the content of |
|
FWIW this fstab works ok without errors being rendered |
|
Interesting. Does this reproduce all the time when you open WSL ? Does starting WSL as administrator / non administrator make a difference ? |
|
Starting wsl as a normal/admin user makes no difference. I only get these errors whilst I'm setting up the WSL instance. I'm about to do another iteration on the setup script so when I get there I'll post all the logs etc you asked for originally. |
|
Oh I see. In that case, it's expected (since until the instance has been restarted, the fstab will not be mounted and so init will fail to translate the Windows path, which explains the warnings). |
|
So in this case, after downloading the rootfs, importing it then launching it is where the errors show. I'm sure you're correct but do you think these errors are valid and should be shown? |
|
/etc/fstab: LABEL=cloudimg-rootfs / ext4 defaults 0 1 But why did this not happen some versions before and just appeared recently? Is there any good reason to show those errors every time now? |
|
@mklueh this started happening for me after installing the wsl feature from the app store on a h22 upgraded Windows 11 |
|
Same errors everytime I log in my ubuntu 20.04 instance
This appeared after upgrading my "inbox" WSL (kernel version 5.10.102 ) to the Microsoft Store version |
|
I've gotten to the bottom of the issues I was having. This relates to the No errors. So after the import, everything is ok apart from the empty fstab. Let's clear the fstab.. No errors So we can see our C: drive mounted despite it not being listed in /etc/wsl.conf and .wslconfig do not exist. The problem seems simple enough, where someone has setup their WSL installation using the app store, their fstab will not have the correct entries to mount the rootfs, so any additional mounts added after will fail with the errors discussed. Id prefer to see an fstab which matches the mounts. I cannot presume to know how /mnt/c is being mounted. So lets add something into fstab... Still no errors. So lets add something into /etc/wsl.conf shutdown, load wsl... adding an interop into /etc/wsl.conf This removes most of the errors. The only ones that are left are: Conclusion The WSL install from the app store despite explicitly not mounting C: will show errors. I would expect that the wsl.conf is honored when |
In my case I tried to get rid of the standard mounts so WSL can't interfere with the actual Windows system. I believe I did nothing except for disabling the auto mounts. And I'm also not sure if I've installed it via Windows Store. At least none of the Ubuntu "Apps" in the store says "Installed already" |
|
@mklueh I updated my comment, if you use you will see errors. This is a bug. Specifically, if you |
I did the same thing but in my case, the rootfs I imported under the "old" WSL, still works without errors. The newly created instance done using the WSL store version has these problems. |
To give some context on this: If the drives are not mounted, WSL cannot translate between Windows and Linux path. If that's what you want, you can set: in If automount is disabled but you have manual mounts in Closing since this should cover both scenarios. |
|
@OneBlue You still get errors with the setup you provided. This needs to be reopened. /etc/fstab /etc/wsl.conf C:\Users\tbmst>wsl --distribution cme-kinetic Where is |
|
<3>WSL (70) ERROR: CreateProcessParseCommon:782: Failed to translate D:\Kali Linux UIUX ┏━(Message from Kali developers) <> |
|
This issue still exists. I just updated WSL to the store version per the startup text recommendation in WSL. After this, my Ubuntu2004 installation now won't mount /mnt/c or /mnt/d. This has broken my vscode integration as well and my entire development workflow depended on these translations being functional. Is there a workaround? I've tried several of the above methods in this thread. |
|
The other thread at #9167 was closed as well. ....completely ignoring any sort of actual development QA process. In short, there is now an additional dependency that you MUST have an instance of your C: drive mounted in order for WSL to work without errors being shown which is completely undocumented, goes against the documentation for the WSL flags. @OneBlue please reopen this. |
|
I Uninstalled the store app version until this is addressed. Luckily this allowed wsl to revert to the previous version and everything works again. Side note, I also attempted to install a fresh distribution and the issue persists there as well. How can this clear QA? It has to have broken things for many users. @flipkickmedia did you have any details of your work around of having the C: mounted as you mentioned? Are you referring to using the external wsl mount command? |
Unfortunately not :( It seems that with this version of WSL, after trying every possible combination of mounts, flags, etc it all still fails. However....if you build a WSL instance, using the old version, then upgrade your WSL, this runs without issue and you don't see the errors. If you distribute the vhdx file used to build the WSL instance, and import it (details below) you can work round these issues. On a side note, if you do happen to have a machine with the old version on, create a new WSL instance without the changes and compare the two that might provide some sort of solution whilst Microsoft closes some more tickets without actually fixing the problem. |
@flipkickmedia: Looking at the logs, it looks like there is something wrong with you This is clearly a different problem than the one this issue was created on so please open a new issue to track this |
|
As I mentioned in #4122:
|
|
For anyone still experiencing this issue, I seem to have figured out why it was occurring for me. As I was migrating my distro to a new laptop, I copied over my |
|
I haven't had time to dig into this, but will report I too am seeing this problem after an update to wsl: \xxx is a LAN share, that contains nothing I would have ever intentionally associated with WSL (they contain private windows utilities). This is the first thing output (above the "systemd settle" message). They are in the PATH (exe search path) of the hosting environment, but other than that they are not attached/mounted on the host (for example psdrive doesn't show them). Nor are they mentioned in the WSL session's /etc/ftab (nor any /etc/*.conf, I grep for it, nor any $HOME files). Does WSL do anything with the host search path before/during starting an instance? Note that I read @Sebazzz comment above and this seems to be the case, in that this is a Win10 19044 host, am I seen a new .systemd-env file in my home directory which as a "WAYLAND_DISPLAY" setting. In this case WSL is working and a --shutdown doesn't change anything. Perhaps some Win10/WSL snafu. |
Thanks, after deleted invalid ENVIRONMENT, and execute |
|
After performing a wsl--shutdown this got rid of some problems, I'm still seeing the following though:
Not sure how or why. All that I do know is that I started to see these problems after running wsl --update because I was trying to install and run an app on WSL Linux. Actually, that app didn't work... unfortunately but somehow now that I updated I ran into all these issues. Some of the initial issues have to deal with mounting C: drive. Again, performing a simple wsl --shutdown and relaunching appears to help but still can't find an explanation as to why this error comes up. If someone could provide me some context as to why these issues happened, timelines on fix, or any other details that would be appreciated. Just more or less hurts the developers lifecycle and workflow especially if we have work to get done. Make's things really unreliable.
|
|
@maczamora Sorry to hear that. I have a very similar problem. This ticket and, best I found as of March, all other tickets like this have been closed. Best solution I've come up with, imperfect as it is, is to simply not allow distributions running under WSL to process your Windows PATH variable. The "passthru" execution was a nice feature but to me not enough to put up with the annoying messages. To disable it you need to change your distributions /etc/wsl.conf file to include the following: See this documentation: https://learn.microsoft.com/en-us/windows/wsl/wsl-config#wslconf If you really need to access a Windows program from WSL, just add it to your PATH in your login profile. |
I too was experiencing this problem I believe it's worth nothing that the paths reported in the stdout in my situation are the same as in my windows sytem %PATH% environment variable. After wsl --shutdown / wsl -t Distroname |
|
I also have this issue. My fstab: My wsl.conf: My current workaround for this is to create a symbolic link to the network share in Windows and then start wsl from there. Not ideal, but works: |
|
My fairly old wsl2 setup also failed to mount the windows drives at some point. running |
Version
WSL version: 0.65.3.0 Kernel version: 5.15.57.1 WSLg version: 1.0.41 MSRDC version: 1.2.3213 Direct3D version: 1.601.0 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.22000.856
WSL Version
Kernel Version
Linux version 4.4.0-22000-Microsoft ([email protected]) (gcc version 5.4.0 (GCC) ) #653-Microsoft Wed Apr 27 16:06:00 PST 2022
Distro Version
Debian 11
Other Software
A functioning JDK build/test setup
Repro Steps
make TEST='test/jdk/tools/launcher/ClassPathWildCard.sh' testExpected Behavior
No WSL errors occur
Actual Behavior
The following occurs on stderr:
Diagnostic Logs
strace-ff.zip
WslLogs-2022-08-14_10-40-46.zip
strace-no-ff.log
The text was updated successfully, but these errors were encountered: