runx does not detect WSL2 #2
Comments
Do you mean after executing vcxsrv or xwin manually? Or is built-in X support available in WSL2? |
|
Thank you for the report! So far I have no experience with WSL2. Probably runx would work in WSL2 if it could recognice it. Do you know how a linux program can detect WSL2? Could you show me Is the WSL2 file system accessible in Windows? E.g. somewhere visible in the file explorer? (WSL1 is somewhat hidden, but detectable). If not, runx could not provide cookie authentication and would run with Are the Windows partitions still mounted as
That is quite interesting. Did you do some setup for this? If not, can you please show me the output of: |
|
My pleasure, happy to help!
Yes
That works
Yes
This is how I need to set the display on WSL2 for it to work: 172.26.64.1:0 There is essentially no output for any of the other commands. My wsl.conf: Windows cmd.exe command I used to launch vcxsrv, the
|
Is that an answer to the first question or the second? |
|
the first ;)
…-------- Original Message --------
On Jan 11, 2020, 11:07 AM, eine wrote:
>> Do you mean after executing vcxsrv or xwin manually? Or is built-in X support available in WSL2?
>
> Yes
Is that an answer to the first question or the second?
—
You are receiving this because you authored the thread.
Reply to this email directly, [view it on GitHub](#2?email_source=notifications&email_token=AABVSSALKBLPPQWWEAFAWZLQ5HVELA5CNFSM4KFBK6P2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIWFC2I#issuecomment-573329769), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AABVSSCIU4GWQ535HLT3QN3Q5HVELANCNFSM4KFBK6PQ).
|
Great!
That's odd. In that case WSL would be detected and the reported error message should not appear:
Could you please show me the output of: ? |
|
|
|
Thanks. Ok, WSL2 shows |
You are using ipconfig.exe, maybe check that? |
|
It seems runx does not detect How/Where did you install VcXsrv?
runx/ipconfig.exe found the IP of the Windows docker daemon |
|
Oh, I'm not running windows docker daemon! You don't need to with WSL2. |
|
ok, cool. Than that works indeed. I'll have to implement support for this in x11docker.
It is odd that runx does not detect VcXsrv. Can you please check: Can you directly execute: |
|
Yes, I would like to use x11docker too. /c/Program Files/VcXsrv/vcxsrv.exe I can execute |
|
I am entirely confused why runx has an issue to detect vcxsrv.exe. Everything looks right. |
|
|
Ok, likely I found the issue: I've uploaded a fixed version. Hopefully I did not introduce any syntax error. |
|
Does runx work now? I've adjusted x11docker, too. Could you please check it, too? If it fails, please run it with |
|
I had time to try out I couldn't get this Emacs docker image to display a GUI with just |
Great!
The command example of this emacs image only regards |
|
I've opened a WSL2 ticket at x11docker: mviereck/x11docker#214 @eine: Could you please try out, too? Some checks in x11docker have been changed that also affect MSYS2/Cygwin/WSL1. I hope I did not break anything. Ideally you should not note any difference. If it works well in one of them, the others should be ok, too, so one check would be enough. |
|
Hi @mviereck! I just pulled latest master of runx and x11docker. As you expected, nothing seems to have changed on MSYS2. The following command works: $ /cygdrive/t/x11docker/x11docker --user=0 -i ghdl/ext bash
x11docker note: Using X server option --xwin
x11docker 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 issue #108 on github.
x11docker note: Option --user=root: Enabling option --sudouser.
x11docker WARNING: Option --sudouser severly reduces container security.
Container gains additional capabilities to allow sudo and su.
If an application breaks out of container, it can harm your system
in many ways without you noticing. Password: x11docker
x11docker note: Option --sudouser: Enabling option --newprivileges=yes.
You can avoid this with --newprivileges=no
x11docker WARNING: Option --newprivileges=yes: x11docker does not set
docker run option --security-opt=no-new-privileges.
That degrades container security.
However, this is still within a default docker setup.
x11docker ERROR: waitforlogentry(): dockerrc: Timeout waiting for entry "xinitrc is ready" in xinit.log
Last lines of xinit.log:
winPointerWarpCursor - Discarding first warp: 1920 1080
(--) 5 mouse buttons found
(--) Setting autorepeat to delay=500, rate=31
(--) Windows keyboard layout: "0000040A" (0000040a) "Spanish", type 4
(--) Found matching XKB configuration "Spanish (Spain,Traditional Sort)"
(--) Model = "pc105" Layout = "es" Variant = "none" Options = "none"
Rules = "base" Model = "pc105" Layout = "es" Variant = "none" Options = "none"
winInitMultiWindowWM - DISPLAY=:2188.0
winMultiWindowXMsgProc - DISPLAY=:2188.0
winProcEstablishConnection - Clipboard is not enabled, returning.
Type 'x11docker --help' for usage information
Debug options: '--verbose' (full log) or '--debug' (log excerpt).
Logfile will be: /home/eine/.cache/x11docker/x11docker.log
Please report issues at https://github.com/mviereck/x11dockerHitting $ /mnt/t/runx/runx --no-auth -- /mnt/t/x11docker/x11docker --user=0 -i ghdl/ext bash
runx note: Using random X display number :1623.
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 WARNING: Option --no-auth: Cookie authentication is disabled!
SECURITY RISC!
Your X server xwin 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=10.0.75.1:1623
x11docker ERROR: Cache root folder must not contain whitespaces.
'//wsl$/Debian/home/eine'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
C:/Users/eine/x11docker/cache
Type 'x11docker --help' for usage information
Debug options: '--verbose' (full log) or '--debug' (log excerpt).
Logfile will be:
Please report issues at https://github.com/mviereck/x11docker
SUCCESS: The process with PID 18716 has been terminated.In this case, the process is terminated alone and the X server is closed. Let me know if this makes any sense to you. I'll get a full debug log otherwise. |
|
@eine Thank you for the tests! Note that Do you have |
Done. No, I don't have winpty in any of Cygwin or WSL1. It is only available in MSYS2. |
|
I assume that |
I get this error after I followed your instructions on the README. I'm running
runxin a WSL2 in Windows Terminal. Running other GUI programs:startlxdeoremacswork without usingrunx.Windows systeminfo
Subsystem
VcXsrv
XWin
The text was updated successfully, but these errors were encountered: