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

WSLg does not work correctly with the "docker-desktop" system distro #14403

Open
anttikes opened this issue Nov 4, 2024 · 0 comments
Open

WSLg does not work correctly with the "docker-desktop" system distro #14403

anttikes opened this issue Nov 4, 2024 · 0 comments

Comments

@anttikes
Copy link

anttikes commented Nov 4, 2024

Description

System information (x86-84 PC):

wsl --version

WSL version: 2.3.24.0
Kernel version: 5.15.153.1-2
WSLg version: 1.0.65
MSRDC version: 1.2.5620
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.22631.4317

wsl -l -v

Default Name Stater Version
* Debian Stopped 2
docker-desktop Stopped 2

Visual Studio Code version: 1.95.1 (user setup)

Ensure that Docker Desktop integration with the WSL2 default distribution is set to enabled. Other settings, including Visual Studio Code's, can be left to their defaults.

Issue was reproduced using the attached simplistic Qt application: qt-test.zip

Reproduce

  1. Ensure your WSL2 default distribution is set to debian.
  2. Start Docker Desktop
  3. Start Visual Studio Code
  4. Open the folder containing the example application
  5. Re-open the folder in a container, and let the container image build
  6. Once the container has started set the "x86-64 Debug" CMake preset active and build the application
  7. Run the application; observe that it starts up fine, and shows a simple UI
  8. Close the connection to the Visual Studio Code container ("Reopen Folder Locally")
  9. From a Windows command-line prompt, issue wsl --set-default docker-desktop to change the default distribution
  10. Re-open the folder in a container, build the application, and run it again

Expected behavior

The application is expected to start correctly but it does not. Instead an error is printed to the console stating that the Qt XCB Platform Abstration plugin could not connect to the display.

If we look at the folders and environment variables required by WSLg support we can see that in the docker-desktop distribution the environment variables are set but the /mnt/wslg folder does not exist. Instead there is /mnt/host/wslg. In the Debian distribution the folder /mnt/wslg contains the exact same files and folders.

docker version

Client:
Version: 27.2.0
API version: 1.47
Go version: go1.21.13
Git commit: 3ab4256
Built: Tue Aug 27 14:17:17 2024
OS/Arch: windows/amd64
Context: desktop-linux

Server: Docker Desktop 4.34.3 (170107)
Engine:
Version: 27.2.0
API version: 1.47 (minimum version 1.24)
Go version: go1.21.13
Git commit: 3ab5c7d
Built: Tue Aug 27 14:15:15 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.20
GitCommit: 8fc6bcff51318944179630522a095cc9dbf9f353
runc:
Version: 1.1.13
GitCommit: v1.1.13-0-g58aa920
docker-init:
Version: 0.19.0
GitCommit: de40ad0

docker info

Client:
Version: 27.2.0
Context: desktop-linux
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.16.2-desktop.1
Path: C:\Program Files\Docker\cli-plugins\docker-buildx.exe
compose: Docker Compose (Docker Inc.)
Version: v2.29.2-desktop.2
Path: C:\Program Files\Docker\cli-plugins\docker-compose.exe
debug: Get a shell into any image or container (Docker Inc.)
Version: 0.0.34
Path: C:\Program Files\Docker\cli-plugins\docker-debug.exe
desktop: Docker Desktop commands (Alpha) (Docker Inc.)
Version: v0.0.15
Path: C:\Program Files\Docker\cli-plugins\docker-desktop.exe
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.2
Path: C:\Program Files\Docker\cli-plugins\docker-dev.exe
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.25
Path: C:\Program Files\Docker\cli-plugins\docker-extension.exe
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: v1.0.5
Path: C:\Program Files\Docker\cli-plugins\docker-feedback.exe
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v1.3.0
Path: C:\Program Files\Docker\cli-plugins\docker-init.exe
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: C:\Program Files\Docker\cli-plugins\docker-sbom.exe
scout: Docker Scout (Docker Inc.)
Version: v1.13.0
Path: C:\Program Files\Docker\cli-plugins\docker-scout.exe

Server:
Containers: 10
Running: 1
Paused: 0
Stopped: 9
Images: 4
Server Version: 27.2.0
Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 nvidia runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 8fc6bcff51318944179630522a095cc9dbf9f353
runc version: v1.1.13-0-g58aa920
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
Kernel Version: 5.15.153.1-microsoft-standard-WSL2
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 12
Total Memory: 15.58GiB
Name: docker-desktop
ID: 53bb19a4-c83a-4157-b671-98b4a7b35581
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Labels:
com.docker.desktop.address=npipe://\.\pipe\docker_cli
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false

WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: daemon is not using the default seccomp profile

Diagnostics ID

69DCE53E-AB04-4C05-8F06-543C97053490/20241104160454

Additional Info

It is unclear whether this is a bug in Visual Studio Code's "Dev Containers" extension or in the docker-desktop system distribution. Perhaps there are some valid reasons why the WSLg folders are placed to /mnt/host/wslg on the system distribution instead of the expected /mnt/wslg.

@anttikes anttikes changed the title Paths and environment variables related to WSLg do not work with the system distro WSLg does not work correctly with the "docker-desktop" system distro Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant