Repository navigation
wslc: --gpus all aborts container creation on Alpine/musl images (GPU hook treats ldconfig exit code 1 as fatal) #41791
Description
Windows Version
Microsoft Windows [Version 10.0.26300.9457] (26H2)
WSL Version
WSL 3.0.1.0 (wslc 3.0.1.0)
Are you using WSL 1 or WSL 2?
- WSL 2
Kernel Version
6.18.40.1-1
Distro Version
Not applicable — the containers run inside the wslc session VM. Images used: alpine:3.20 (musl) and ubuntu:22.04 (glibc), both pulled from Docker Hub by wslc pull.
Other Software
- GPU: NVIDIA GeForce RTX 5060 Ti, Windows driver 616.92
- Docker Desktop 4.93.0 (engine 29.8.1) installed and running concurrently — used below only as a behavioural comparison, not part of the repro
Repro Steps
wslc pull alpine:3.20
wslc run --rm --gpus all alpine:3.20 nvidia-smiAny init command reproduces it — the failure happens during container creation, before the entrypoint runs:
wslc run --rm --gpus all alpine:3.20 sh -c "echo hello"Control case, same host / same session / same WSL build:
wslc pull ubuntu:22.04
wslc run --rm --gpus all ubuntu:22.04 bash -c "nvidia-smi -L"
# GPU 0: NVIDIA GeForce RTX 5060 Ti (UUID: GPU-...)Expected Behavior
Either:
- the container starts with the GPU devices/driver libraries injected (as it does for
ubuntu:22.04), or - if musl-based images are genuinely unsupported for
--gpus, the hook fails with an error that says so and names the requirement, instead of an opaqueE_FAIL+ source file/line.
In no case should a non-zero exit from ldconfig be fatal when ldconfig itself did everything it was asked to do.
Actual Behavior
failed to create task for container: failed to create shim task: OCI runtime create failed:
runc create failed: unable to start container process: error during container init:
error running createContainer hook #0: exit status 255, stdout: , stderr:
<3>WSL (8 - ) ERROR: UtilCreateProcessAndWait:735: /sbin/ldconfig failed with status 0x100
Exception: File exists @WSLCInit.cpp:156 (WslcGpuHookEntry): unknown
错误代码： E_FAIL
The container is never created. --gpus is therefore unusable on any Alpine-based image.
Root cause
status 0x100 is exit code 1 in the low byte, and Alpine's /sbin/ldconfig is not the glibc binary — it is a 393-byte POSIX shell shim that swallows options and only does work when it is given directories:
#!/bin/sh
scan_dirs() { ... }
# eat ldconfig options
while getopts "nNvXvf:C:r:" opt; do
:
done
shift $(( $OPTIND - 1 ))
[ $# -gt 0 ] && scan_dirs "$@"That last line means /sbin/ldconfig with no positional arguments exits 1 on Alpine, having done nothing wrong. Verified inside alpine:3.20:
/sbin/ldconfig -> rc=1 <-- what the hook observes
/sbin/ldconfig /usr/lib -> rc=0
/sbin/ldconfig -v /usr/lib -> rc=0
and inside ubuntu:22.04:
/sbin/ldconfig -> rc=0
So the hook appears to invoke /sbin/ldconfig without directory arguments and treats a non-zero exit as fatal. On glibc images that call is a no-op returning 0, which is why ubuntu:22.04 works and alpine:3.20 cannot start at all.
Suggested fix, any one of:
- pass the library directories explicitly (e.g.
/sbin/ldconfig /usr/lib64 ...), or - don't treat
ldconfig's exit status as fatal (the glibc binary can also return non-zero on a read-only cache), or - skip the
ldconfigstep when the image has no glibc/sbin/ldconfigbinary, and log why the driver cache was not refreshed.
Notes
- For comparison, on the same machine
docker run --rm --gpus all alpine:3.20 ...(Docker Desktop) does start the container, although the driver injection there is also incomplete for Alpine (/dev/nvidia*absent,/usr/bin/nvidia-smipresent but not executable). So this is not "musl GPU support works elsewhere" — it is that wslc fails hard at creation time, which makes the image unusable rather than degraded. - This looks like part of a broader musl gap: wslc:
host.wslc.internaldoes not resolve in musl-based containers, resolves in glibc-based containers #41769 reportshost.wslc.internalnot resolving in musl-based containers while it resolves in glibc ones. If musl images are out of scope for--gpus, it would help to say so in the WSL container docs, which currently only showubuntu/nginxexamples. - Happy to attach
collect-wsl-logs.ps1output; the repro is one command and reproduces on a freshly rebooted machine with a clean session.
Activity
github-actions commentedon Oct 3, 2026
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.
How to collect WSL logs
Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:
The script will output the path of the log file once done.
If this is a networking issue, please use
.\collect-wsl-logs.ps1 -LogProfile networkinginstead, following the instructions in Collect WSL logs for networking issuesOnce completed please upload the output files to this GitHub issue.
See Collect WSL logs (recommended method).
If you choose to email these logs instead of attaching them to the bug, please send them to [email protected] with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.
chenmohan123 commentedon Oct 4, 2026
Logs attached separately per the bot's instruction — emailed to
[email protected]with this comment's link in the body.Repro captured at 2026-10-04 10:28 local (Windows 10.0.26300.9457 / 26H2, WSL 3.0.1.0, wslc 3.0.1.0, kernel 6.18.40.1-1, RTX 5060 Ti, driver 616.92) with
collect-wsl-logs.ps1running in the default profile, so the WPR trace covers both the failing and the passing case:Two details that may help the trace review:
createContainerhook before the init process runs, so it is independent of the command passed towslc run(nvidia-smi,sh -c ..., anything).wslc-cli-<user>) and, in the run above, the elevated one (wslc-cli-admin-<user>), i.e. it is not session-store specific.One note on the bundle:
optional-components.txtis 0 bytes becauseGet-WindowsOptionalFeature -Onlinefails on this build with0x80040154("no registration class") — that is a pre-existing issue on this machine unrelated to wslc, and the collection script continued normally (wpr.exe -stopcompleted,logs.etlis 2.6 MB).chenmohan123 commentedon Oct 4, 2026
/emailed-logs
Logs sent to
[email protected]on 2026-10-04 10:39 (UTC+8).41791 - wslc --gpus all aborts container creation on Alpine/musl images--gpus allaborts container creation on Alpine/musl images (GPU hook treats ldconfig exit code 1 as fatal) #41791 (comment)wslc-41791-logs.tar.gz(365 KB) — bundle produced bycollect-wsl-logs.ps1(default profile), containinglogs.etl(2.6 MB WPR trace covering both the failingalpine:3.20case and the passingubuntu:22.04control) plus therepro-output.txtA/B transcript that I added into the archive.github-actions commentedon Oct 4, 2026
Diagnostic information