WSL2 + Windows Not Working

[kiwidoggie]

I currently have been having non-stop issues on my Windows 10 machine, although this works near flawlessly on Linux.

After installing x11docker in WSL2 (Ubuntu 20.04 LTS), and installing VcXsrv on Windows. When launching any application (like telegram desktop, chromium, any example on the README.md) that the VcXsrv server starts on Windows, has a random port and then will close/shut down, and inside of WSL2 returns back to CLI. Before I was getting an error about could not connect to X server, and now not even that happens.

[173:173:0221/040852.601553:ERROR:browser_main_loop.cc(1438)] Unable to open X display
when trying to launch chromium gets printed on the WSL2 command line.

If I use XLaunch and leave the server open, I don't see any way to provide which display to try and connect to (it always starts a new one with runx). There are no errors, or logs anywhere so I'm kind of at a loss on what to do next.

Is there a way to provide the display number instead of launching a new one to runx? I'll be happy to provide any additional details, but here's the generic "dump" of information.

And I know that support for WSL2 is iffy, but hopefully I can help find a solution, but if not I can always run a VM :)

Windows 10 20H2 (OS Build 19042.804)

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04
Codename: focal

x11docker --version
6.6.2

runx version v0.4.2

vcxsrv-64.1.20.9.0

Firewall: Off (for testing)/VcXsrv was added

[mviereck]

Thank you for the report!

Could you please run some tests to encircle the issue?

• Run a host application with runx. For example, install xterm in WSL2 and run runx -- xterm.
  • If this fails, try runx --no-auth -- xterm
• Disable cookie authentication in x11docker. Example: x11docker --no-auth x11docker/fvwm xterm

Is there a way to provide the display number instead of launching a new one to runx?

Both runx and x11docker have option --display N to specify a display number N. (Note that the number must not be in use by a another running X server).
For test runs it can help to also add --no-auth to disable cookie authentication.

There are no errors, or logs anywhere so I'm kind of at a loss on what to do next.

x11docker has option --debug that might give some hints. Even more verbose is --verbose.
runx has --verbose.

[eine]

@mviereck IIRC, some time ago you decided to stop supporting vcxsrv on WSL, because of authentication issues. The last "official" statement I remember was that vcxsrv was supported on MSYS2 only, and Cygwin/X was to be used on either Cygwin or WSL. Did it change?

[mviereck]

IIRC, some time ago you decided to stop supporting vcxsrv on WSL, because of authentication issues.

It was a bit different: VcXsrv provides xauth.exe for cookie generation. Using this caused troubles.
I've decided not to use xauth.exe anymore. Instead xauth must be provided by WSL/WSL2 or Cygwin themselves.
Only MSYS2 does not provide its own xauth, so there is no cookie support in MSYS2.

OT: That being said, maybe the MSYS2 developer could be asked if he would provide xauth in its repositories. I assume that would be a small and easy to maintain package (other than a full X environment would be).

[eine]

Thanks for clarifying. Would you mind pointing me to the source of the xauth package that you/we would like to be added to MSYS2 repos? Is it this https://gitlab.freedesktop.org/xorg/app/xauth?

[mviereck]

Is it this https://gitlab.freedesktop.org/xorg/app/xauth?

That one looks right.
It might help to also point to the Cygwin package: https://cygwin.com/packages/summary/xauth.html

[mviereck]

@kiwidoggie Could you please have a look and run the tests of my first answer?

[kiwidoggie]

Ubuntu 20.04

runx -- xterm

kuser@godiwik-laptop:/mnt/c/Users/godiwik$ runx -- xterm
runx note: Using random X display number :1555.
If this display number is already in use, X server startup will fail.
You can specify a display number N with option '--display N'.

runx note: Windows firewall settings can forbid application access
to the X server. If no application window appears, but no obvious error
is shown, please check your firewall settings.
Compare: #108

runx note: If you get application error messages like 'Cannot open display'
or 'Invalid MIT-MAGIC-COOKIE', the X authentication cookie might be broken.
You can remove old cookies and stop running X servers with: runx --cleanup

DISPLAY=192.168.1.213:1555 XAUTHORITY=/home/kuser/runx_Xauthority
/usr/local/bin/runx: line 696: xterm: command not found
SUCCESS: The process with PID 11292 has been terminated.
kuser@godiwik-laptop:/mnt/c/Users/godiwik$

``runx --no-auth -- xterm`
kuser@godiwik-laptop:/mnt/c/Users/godiwik$ runx --no-auth -- xterm
runx note: Using random X display number :191.
If this display number is already in use, X server startup will fail.
You can specify a display number N with option '--display N'.

runx note: Windows firewall settings can forbid application access
to the X server. If no application window appears, but no obvious error
is shown, please check your firewall settings.
Compare: #108

runx WARNING: Option --no-auth: Cookie authentication is disabled!
SECURITY RISC!
Your X server vcxsrv listens on TCP connections without any protection.
Others could try to access your system through network connections.
Please use option --no-auth for debugging only.

DISPLAY=192.168.1.213:191
/usr/local/bin/runx: line 696: xterm: command not found
SUCCESS: The process with PID 6436 has been terminated.

x11docker --no-auth x11docker/fvwm xterm

kuser@godiwik-laptop:/mnt/c/Users/godiwik$ x11docker --no-auth x11docker/fvwm xterm
x11docker WARNING: User kuser is member of group docker.
That allows unprivileged processes on host to gain root privileges.

Failed to connect to bus: No such file or directory
x11docker note: Using X server option --runx

x11docker note: WSL2 support is experimental and barely tested yet.
Feedback and bug reports are appreciated!

x11docker WARNING: Option --no-auth: SECURITY RISK!
Allowing access to new X server for everyone.
Your X server is accessable over TCP network without any restriction.
That can be abused to take control over your system.

Image x11docker/fvwm not found locally.
Do you want to pull it from docker hub?
(timeout after 60s assuming no) [Y|n]yx11docker note: Pulling image 'x11docker/fvwm' from docker hub

Using default tag: latest
latest: Pulling from x11docker/fvwm
df20fa9351a1: Pull complete
8ead7a7e873f: Pull complete
Digest: sha256:e7fd7d09c834f44381e7f89248f9b7165ebdeb58bc083f00f1453eaa7833408e
Status: Downloaded newer image for x11docker/fvwm:latest
docker.io/x11docker/fvwm:latest
kuser@godiwik-laptop:/mnt/c/Users/godiwik$ xterm: Xt error: Can't open display: 172.30.96.1:487

When running XLaunch outside in Windows-Land, and specifying --display 1337, or 1337.0 (the number I picked manually I get this)

Adding FW Settings:

[mviereck]

/usr/local/bin/runx: line 696: xterm: command not found

ok, the first two tests failed because xterm is not installed in WSL2.

kuser@godiwik-laptop:/mnt/c/Users/godiwik$ xterm: Xt error: Can't open display: 172.30.96.1:487

The third test shows an unexpected IP adress 172.30.96.1. Likely it is not valid. runx should detect an IP adress starting with 192.168.
Can you please check the output of ipconfig.exe if it shows an IP starting with 192.168?

[kiwidoggie]

Windows IP Configuration


Ethernet adapter vEthernet (Default Switch):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::891e:fc4a:9d09:5f60%32
   IPv4 Address. . . . . . . . . . . : 172.30.96.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

Ethernet adapter vEthernet (WSL):

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::d5b6:728b:d49f:a049%46
   IPv4 Address. . . . . . . . . . . : 172.26.0.1
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . :

Unknown adapter Local Area Connection:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Wireless LAN adapter Local Area Connection* 1:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Wireless LAN adapter Local Area Connection* 2:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Wireless LAN adapter Wi-Fi:

   Connection-specific DNS Suffix  . : lan
   IPv6 Address. . . . . . . . . . . : 2601:600:967f:c1f6::50c
   IPv6 Address. . . . . . . . . . . : 2601:600:967f:c1f6:41e9:83bf:b2a1:67fc
   IPv6 Address. . . . . . . . . . . : fd3b:14ff:77b0::50c
   IPv6 Address. . . . . . . . . . . : fd3b:14ff:77b0:0:41e9:83bf:b2a1:67fc
   Temporary IPv6 Address. . . . . . : 2601:600:967f:c1f6:10a6:5a74:c12a:ae6a
   Temporary IPv6 Address. . . . . . : fd3b:14ff:77b0:0:10a6:5a74:c12a:ae6a
   Link-local IPv6 Address . . . . . : fe80::41e9:83bf:b2a1:67fc%6
   IPv4 Address. . . . . . . . . . . : 192.168.1.213
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : fe80::6038:e0ff:febe:cce0%6
                                       192.168.1.1

Ethernet adapter Bluetooth Network Connection:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :

Seems to be attempting to connect to the Hyper-V adapters (I do have Hyper-V installed) maybe?

[mviereck]

Seems to be attempting to connect to the Hyper-V adapters (I do have Hyper-V installed) maybe?

Yes. That is odd because x11docker should find 192.168.1.213. Adresses starting with 172.* should only be used as a fallback if there is no 192.168.*.

This is the related code in runx, can you test it? It should print IP: 192.168.1.213.

#! /bin/bash
rmcr() {
  # Convert stdin if $1 is empty. Otherwise convert file $1.
  case "${1:-}" in
    "") sed    "s/$(printf "\r")//g" ;;
    *)  sed -i "s/$(printf "\r")//g"  "${1:-}"
  esac
}

Hostip=""
[ "$Hostip" ] || Hostip="$(ipconfig.exe | rmcr | grep 'IPv4' | grep -o '192\.168\.[0-9]*\.[0-9]*'       | head -n1 )"
[ "$Hostip" ] || Hostip="$(ipconfig.exe | rmcr | grep 'IPv4' | grep -o '10\.0\.[0-9]*\.[0-9]*'          | head -n1 )"
[ "$Hostip" ] || Hostip="$(ipconfig.exe | rmcr | grep 'IPv4' | grep -o '[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*' | head -n1 )"
  
echo "IP: $Hostip"

[kiwidoggie]

I modified the script, and it prints correctly it seems like:

kuser@godiwik-laptop:/mnt/c/Users/godiwik$ runx
IP: 192.168.1.213
runx note: Using random X display number :2547.
  If this display number is already in use, X server startup  will fail.
  You can specify a display number N with option '--display N'.

runx note: Windows firewall settings can forbid application access
  to the X server. If no application window appears, but no obvious error
  is shown, please check your firewall settings.
  Compare:   https://github.com/mviereck/x11docker/issues/108

runx note: If you get application error messages like 'Cannot open display'
  or 'Invalid MIT-MAGIC-COOKIE', the X authentication cookie might be broken.
  You can remove old cookies and stop running X servers with: runx --cleanup

DISPLAY=192.168.1.213:2547 XAUTHORITY=/home/kuser/runx_Xauthority

Testing with xterm only

DISPLAY=192.168.1.213:2547 XAUTHORITY=/home/kuser/runx_Xauthority xterm

[mviereck]

it prints correctly it seems like:

That looks right and x11docker in WSL2 should work as expected.

I modified the script

You modified the script? Did you have an outdated version of runx? Your initial post said runx version v0.4.2.

I've taken the code from current runx v0.4.2, did it look different in your runx?
Compare: https://github.com/mviereck/runx/blob/master/runx#L327-L331

[kiwidoggie]

Oh, I thought when you were asking to print the hostip, I was supposed to modify the script. I just found the

# Convert stdin if $1 is empty. Otherwise convert file $1. line

and added

Hostip=""
[ "$Hostip" ] || Hostip="$(ipconfig.exe | rmcr | grep 'IPv4' | grep -o '192\.168\.[0-9]*\.[0-9]*'       | head -n1 )"
[ "$Hostip" ] || Hostip="$(ipconfig.exe | rmcr | grep 'IPv4' | grep -o '10\.0\.[0-9]*\.[0-9]*'          | head -n1 )"
[ "$Hostip" ] || Hostip="$(ipconfig.exe | rmcr | grep 'IPv4' | grep -o '[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*' | head -n1 )"
  
echo "IP: $Hostip"

That's the only modification that I did, but I will revert it. There's no changes otherwise.

[mviereck]

There has been a related ticket in runx: mviereck/runx#6
I've made a fix in x11docker, too. But it is in master branch only, not in stable release.
Sorry, it is my fault, I should have thought of this before.

Please update x11docker with sudo x11docker --update-master. Then it will likely work as expected.
I'll publish a new release now.

[mviereck]

I've published release v6.7.0 containing the IP fix in x11docker.
You can run as well sudo x11docker --update now.

Commands like this should work now in WSL2:

x11docker --desktop x11docker/fvwm

[kiwidoggie]

Tyvm <3 It seems to launch and load just fine now :D