Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wsltty closes immediately when using a non-default mount path #91

Closed
pd93 opened this issue Feb 8, 2018 · 21 comments
Closed

wsltty closes immediately when using a non-default mount path #91

pd93 opened this issue Feb 8, 2018 · 21 comments

Comments

@pd93
Copy link

pd93 commented Feb 8, 2018

In the latest Windows Insider Build 17093 there is a new WSL configuration file at /etc/wsl.conf. This file allows you (among other things) to specify the mount point for your windows drives (defaults to /mnt/).

My motivation for changing the mount point is that I want to use Docker via the WSL and this doesn't currently work because of an issue with volumes being mounted to the wrong location. Mounting your Windows drives to / via the /etc/wsl.conf file solves this problem, but breaks wsltty.

Once the mount point is changed, wsltty closes immediately when started. I wasn't sure if this was a wsltty or wslbridge issue, so I opened it here first.

Starting up the Ubuntu app works as expected.

@mintty
Copy link
Owner

mintty commented Feb 9, 2018

First, try to get hold of any error message by adding -h alw to the mintty invocation (or Hold=always to the config file).
Also, it would be useful to separate the test cases and invoke wslbridge explicitly, either from a cygwin installation (with wslbridge and wslbridge-backend in /usr/bin, can be copied from the wsltty installation), or by running /bin/wslbridge from a minimal wsltty-based Cygwin shell:
%LOCALAPPDATA%/wsltty/bin/mintty /bin/dash.

@pd93
Copy link
Author

pd93 commented Feb 9, 2018

So adding Hold=always in the config file allowed me to grab the error that prints to the console:

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

Running wslbridge from dash just returns wslbridge: not found, What exactly should I be typing to invoke it explicitly? (I don't have cygwin installed currently, but am happy to if needed)

@mintty
Copy link
Owner

mintty commented Feb 9, 2018

/bin/wslbridge

@mintty
Copy link
Owner

mintty commented Feb 9, 2018

backend error output: /bin/bash: /mnt/c/Users/pete/AppData/Local/wsltty/bin/wslbridge-backend: ...

Apparently wslbridge tries to convert the path to find its backend in %LOCALAPPDATA% (or actually /bin from the cygwin point of view), based on WSL default assumption.
@rprichard: so this is a wslbridge issue...

@pd93
Copy link
Author

pd93 commented Feb 9, 2018

When running /bin/wslbridge, I get the same error as I get when launching wsltty.
I will open an issue with wslbridge and link it back to here.

@mintty
Copy link
Owner

mintty commented Feb 10, 2018

Apart from the startup problem, changing the mount point would actually also spoil the mintty path conversion, for Ctrl+click file opening and pathname pasting. Is the information also available in the registry? How does it look like in the wsl.conf file?

@mintty
Copy link
Owner

mintty commented Feb 10, 2018

If you want to try patching wslbridge, you'd need a Cygwin installation, with packages gcc-core and make,
download wsltty and run make wslbridge-frontend.

@pd93
Copy link
Author

pd93 commented Feb 10, 2018

I'm happy to help contribute to this as not many are running the latest Windows builds. I shall get an instance of Cygwin installed again today and have a look at wslbridge in more detail.

The wsl.conf file uses the .ini format. The file does not exist unless the user creates it and the only thing required to change the mount point is the following:

[automount]
root = /

More details on the file in the link in the OP.

I'm not sure if there is an 'official' way to obtain the root mount point in WSL, but if not, you could either parse the .ini file or run something like mount | grep C: | awk '{ print $3 }' to get the mount point for the C drive.

I mentioned this in the wslbridge issue, but it's worth mentioning here too that in the latest builds, there is a tool called wslpath which performs WSL -> Windows path conversion and back natively. (I've tested this and it complies with non-default mount points).

@mintty
Copy link
Owner

mintty commented Feb 10, 2018

It's best to acquire the information from the file (or registry, if available, if you could have a look) so mintty can set it up without starting another instance of WSL in advance.

@pd93
Copy link
Author

pd93 commented Feb 10, 2018

I can't see that there is anything in the registry after a quick search, but tbh, I'm not 100% sure where I'd be looking anyway. From the documentation, it sounds like the wsl.conf file is read directly on launch.

I think reading from the file is going to be the easiest solution here.. Is there a problem accessing the file in /etc/wsl.conf before starting an instance of WSL? - I know there can be problems when opening a file on the Linux filesystem in Windows.

@mintty
Copy link
Owner

mintty commented Feb 11, 2018

Is the "root" the mount point or the mount prefix? The examples show it always with trailing slash; if you drop that, like "/drive", will mounts be "/drive/c" or "/drivec"?

@pd93
Copy link
Author

pd93 commented Feb 11, 2018

Just tested this and it's a prefix. The trailing slash seems to make no difference to the resulting mount point. If a value of /drive is given, all the drives will be mounted to /drive/x (where x is a drive letter). The directory /drive must exist before the wsl starts or the drives are not mounted.

@pd93
Copy link
Author

pd93 commented Feb 15, 2018

@mintty I was thinking about this today, and it occurred to me that any user that is willing to go through the effort of creating a config file in the WSL probably doesn't mind editing the wsltty config as well. So why not just add a setting to the config file which stores the root mount point. If this setting is absent then we just use the wsl defualt: /mnt/

@mintty
Copy link
Owner

mintty commented Feb 16, 2018

Possible. But it's also fairly feasible to do that implicitly in mintty, I just haven't had the time to do it yet.
However, that's only the smaller part of the issue, applicable to filename copy/paste.
The major problem is that wslbridge will not find its backend, so we'll have to patch it...

@pd93
Copy link
Author

pd93 commented Mar 12, 2018

Hey @mintty Now that the wslbridge issue is closed, what needs to be done here to close the wsltty issue?

@mintty
Copy link
Owner

mintty commented Mar 12, 2018

I need to find the time to check out the wslbridge update, integrate it, and adapt mintty to also consider the mount path for its drag-and-drop and click-open features.
Also I'm currently concerned with a stalling condition related to sixel graphics display. Although that problem has been in the code for 2 years already, I'm not feeling too comfortable to make another release without fixing it first...

@mintty
Copy link
Owner

mintty commented Apr 8, 2018

Support for WSL mount point configuration is now available in mintty (for open/paste path conversion) and wsltty (building with the wslbridge 'wslpath' version). There will be a release soon. However, I'm not really comfortable with releasing with a branch version; maybe we can ask @rprichard to merge or even release it.

@rprichard
Copy link

The wslpath change is already merged into wslbridge master, but I haven't made a release containing it yet.

@mintty
Copy link
Owner

mintty commented Apr 12, 2018

Released 1.8.5 which supports WSL mount path configuration (both /etc/wsl.conf and /etc/fstab) when starting and with path name conversion (for click-open and drag-and-drop paste).

@mintty mintty closed this as completed Apr 12, 2018
@pd93
Copy link
Author

pd93 commented Apr 13, 2018

@mintty Amazing. Thanks for the support. I'll give this a go first thing when I get home today. Just in time for the Windows 10 1803 release that includes the wslpath features

@pd93
Copy link
Author

pd93 commented Apr 13, 2018

Everything works as expected 👍 Thanks again

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants