Mounting Windows drives to non-default location in wsl.conf stops wslbridge from starting

[pd93]

In the latest insider build of Windows 10 [17093] there is a new configuration file for the WSL at /etc/wsl.conf. Among other things, this allows you to change the path on which your Windows drives are mounted (default is /mnt/).

This is extremely useful at the moment, as it allows us to get Docker working via the WSL. (See this issue for details).

I originally created an issue with wsltty as the terminal was exiting immediately after launching, but @mintty has determined that the issue is here instead. The error given when starting wsltty or wslbridge is:

wslbridge error: failed to start backend process
note: backend error output: /bin/bash: /mnt/c/Users/user/AppData/Local/wsltty/bin/wslbridge-backend: No such file or directory

Having had a quick look through the code here, it seems that the only mentions of the /mnt path string are in this function. It's just a question of how to find what path the user has mounted their Windows drives to (in my case /) and using that instead.

It may also be worth mentioning that the task that function performs, can now be done with the wslpath tool included in the latest insiders builds (since 17046).

[rprichard]

I wonder if wslpath accepts a GUID specifying the WSL instance.

Assuming it does, then I think this issue can be fixed by invoking wslpath.exe (if it exists). I'd expect that to slow the startup time a bit, but I think that's OK. This seems fairly easy to fix.

[mintty]

You'd have to ramp up a WSL environment twice for calling wslpath in advance, right?
I think delaying startup is a delicate issue for many users, reading /etc/wsl.conf would be faster.
If you don't want to introduce registry handling for this purpose, mintty could pass you the mount root as a parameter if that helps.

[rprichard]

You'd have to ramp up a WSL environment twice for calling wslpath in advance, right?

Oh, wslpath is a WSL command. I thought it was an EXE for some reason. That would be pretty slow.

Yeah, it should probably read wsl.conf somehow. If someone's using wsl.conf, I think it's wrong for wslbridge to assume /mnt/<drive>, so I think I'd prefer that wslbridge find wsl.conf by default. Is the WSL root path in the registry somewhere?

[mintty]

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\{guid} value BasePath

[rprichard]

Thanks, that should work.

[mintty]

It seems to be even worse; reading the release notes, it seems that the mount point can also be adjusted with /etc/fstab, with subtle precedence behaviour that needs to be verified (cannot yet test myself).
Maybe it would be easier to copy wslbridge-backend into the WSL root filesystem? The frontend could perhaps do that on demand, on first invocation.

[rprichard]

It seems to be even worse; reading the release notes, it seems that the mount point can also be adjusted with /etc/fstab, with subtle precedence behaviour that needs to be verified (cannot yet test myself).
Maybe it would be easier to copy wslbridge-backend into the WSL root filesystem? The frontend could perhaps do that on demand, on first invocation.

That seems hairy -- e.g. permissions, concurrent startup, conflicting wslbridge versions, etc. If wslbridge can't find a WSL path to its backend, maybe the user should configure its backend WSL path?

I wonder if wslpath is correct when /etc/fstab is used.

wslbridge currently invokes bash.exe -c "/mnt/drv/path/to/wslbridge-backend <args>".

Maybe it could use wslpath inside the lone bash.exe invocation. Something like:

bash.exe -c '"$(wslpath C:/path/to/wslbridge-backend)" <args>'

[mintty]

Ah, that sounds worth a try. Provided wslpath always exists, but I've checked it's already available on Legacy Bash-on-Windows, as well as Ubuntu and openSUSE, so maybe we can just rely on it.

[mintty]

I wonder if wslpath is correct when /etc/fstab is used.

Also, if it should not be correct, we can blame it on wslpath :)

[pd93]

@rprichard I'm pretty sure that wslpath will obey the /etc/fstab file. I can test this for you, but I'm not sure what to actually put in it.

[pd93]

Provided wslpath always exists

You could just put a little test in the bash invocation and use the default mount if wslpath doesn't exist:

bash.exe -c '"$([ $(command -v wslpath) ] && echo $(wslpath "C:/") || echo "/mnt/c")/path/to/wslbridge-backend" <args>'

[rprichard]

I implemented a version of the invoke-wslpath idea on this branch: https://github.com/rprichard/wslbridge/tree/wslpath.

I decided to use this syntax (w/o newlines):

$(if [ "$(command -v wslpath)" ]; then
  wslpath 'C:\path\to\backend' || echo false;
else
  echo /mnt/c/path/to/backend;
fi) <args>

Part of my rationale was that wslpath can fail (e.g. because the backend isn't on a mounted volume), and when it does, it could be confusing to use the /mnt/ path. Hopefully, if wslpath fails, it will always print something to stderr, which wslbridge will show.

[pd93]

@rprichard looks good to me. Your assumption that something is always written to stderr on failure looks to be true - I've tried a few things.

Also, this may be obvious, but it's worth mentioning that wslpath will expect escaped backslashes (It actually accepts forward slashes for windows paths too). See examples below:

# Single backslash fails
wslpath C:\Users
# wslpath: C:Users: Invalid argument

# Escaped backslash is fine
wslpath C:\\Users
# /c/Users

# Forward slash is also fine
wslpath C:/Users
# /c/Users

[mintty]

The chosen approach prevents an obvious solution to another issue, the user's default shell;
while it could have been handled by using the wsl.exe launcher rather than bash.exe,
this isn't possible anymore as you rely on a specific shell to run the wslpath sequence above.
(Or am I on the wrong track because it's wslbridge-backend that starts the shell?)
Anyway, maybe you can reconsider your #17 (comment) on this occasion.

[rprichard]

this isn't possible anymore as you rely on a specific shell to run the wslpath sequence above ... (Or am I on the wrong track because it's wslbridge-backend that starts the shell?)

Yeah, the backend effectively chooses the shell when it invokes exec. Currently the frontend picks a default of /bin/bash, but I have a patch where the backend chooses the default by calling getpwuid(getuid())->pw_shell.

The frontend's use of bash.exe to invoke the backend, on the other hand, doesn't matter that much, if at all. Windows 15063 has only bash.exe, not wsl.exe, so if wslbridge were to use wsl.exe, it would have to retain bash.exe support.

[pd93]

@rprichard @mintty Worth noting that in the latest Insiders Preview, there are now additional flags for the wsl.exe binary.

These include -exec for invoking a binary without starting a shell and -distribution for selecting the Linux distro. Insider previews are on RS5, so these won't be publicly available until Autumn (Fall), but I figured they were relevant to this issue as starting a new shell just to invoke wslpath was a sore point previously.

[Biswa96]

But to run with exec option there should be a GUID entry in Lxss registry. Wsl.exe won't run without any registry. There is a RtlGuidToString() before exec option.

[mintty]

Is there any actual explanation of the new options (not just listing their existence as on that page...)?
Does the -exec option accept Windows pathname syntax? Only then it would help with the wslpath issue.
And what's the syntax of -distribution? (Not that it would matter, we have a solution for selection a distribution and I don't see the need to change it...)
Thanks.

[Biswa96]

exec option only accepts only Linux path (i.e. /mnt/c). Distribution option has only the distro name. Do you want that wsl.exe? I can upload that.

[mintty]

No thanks. In that case the -exec option isn't useful for our case.

[Biswa96]

The exec option uses the COM interface. If someone reverse that COM interface that can be used in mintty. Though the COM vtable is unstable and undocumented. It also sets the console output to UTF-16 and lot more stuffs.