This seems to work:

export DISPLAY=$(ip route | grep default | awk '{print $3}'):0.0

Credit - GPT4o

from wsl.

Weird. I have DISPLAY set as:

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0

which currently results in DISPLAY=10.255.255.254:0. I assume this was the same value when all was good but I don't know. With DISPLAY set thusly I am getting the behaviour decribed above.

But...if I get the IP address of the ethernet adapter using ipconfig I get 192.168.0.223. And setting DISPLAY=192.168.0.223:0 makes the X GUI apps work OK again.

I wonder why this is.

from wsl.

Folks you are likely seeing this as we change and upgrade networking in WSL. In the latest WSL versions we turned on DNStunneling by default which I think is affecting this path.

As others have put in the thread please update your variable to be the logic above instead (Thank you to @Maxim-Mazurok and others who posted their working configs!!).

We had that old string in our docs page which is why folks might be using it (It's also floating around on GitHub somewhere) but we've gone ahead and updated our docs to use the latest working string.

Since this doesn't have any actionable items for the WSL team I'm going to close it out, thank you for filing this! :)

from wsl.

Weird. I have DISPLAY set as:

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0

which currently results in DISPLAY=10.255.255.254:0. I assume this was the same value when all was good but I don't know. With DISPLAY set thusly I am getting the behaviour decribed above.

But...if I get the IP address of the ethernet adapter using ipconfig I get 192.168.0.223. And setting DISPLAY=192.168.0.223:0 makes the X GUI apps work OK again.

Same behavior here, using X410.
My suspicion is that the problem was introduced by 'Windows 11 Version 23H2 for x64-based Systems (KB5039212)'.

from wsl.

Having the same issue.
DISPLAY=10.255.255.254:0.0 - doesn't work
DISPLAY=172.20.144.1:0.0 - works.

I'm pretty sure that nameserver in /etc/resolve.conf used to be 172.20.144.1.
The 10.255.255.254 address looks new and unexpected to me.

Both me and two of my teammates are having the same issue since recent Windows upgrade.

My Windows system info:

Edition	Windows 11 Enterprise
Version	23H2
Installed on	‎04-‎May-‎2023
OS build	22631.3737
Experience	Windows Feature Experience Pack 1000.22700.1009.0

WSL info:

WSL version: 2.2.4.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.61
MSRDC version: 1.2.5326
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26091.1-240325-1447.ge-release
Windows version: 10.0.22631.3737

from wsl.

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Closed similar issues:

• WSL version: 1.0.3.0: no longer able to use external X server with Windows 10 (20H2) (#9541), similarity score: 0.74
• wslg cannot open display if wsl started with Task Scheduler (#8217), similarity score: 0.74
• wslg not working on windows 11 (#9206), similarity score: 0.71
• WSL2 Windows 11 suddenly cannot open display (#7950), similarity score: 0.71
• X Windows broken on fast ring WSL2 (?) (#5106), similarity score: 0.70

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

from wsl.

The log file doesn't contain any WSL traces. Please make sure that you reproduced the issue while the log collection was running.

Issue was edited and new log file was found: https://github.com/user-attachments/files/15840842/WslLogs-2024-06-14_17-10-15.zip
Detected appx version: 2.2.4.0
Found no WSL traces in the logs

from wsl.

Logs added.

from wsl.

export DISPLAY=$(ip route | grep default | awk '{print $3}'):0.0

Maxim's solution seems to work. And the interpretation is given by bobf32.
ip route will give the right ip, while /etc/resolv.conf will not.

from wsl.