fix(gpu): add WSL2 GPU support via CDI mode

[tyeth]

This is a newly created issue to effectively re-open #411 as my vouched user.
It's probably a less than ideal technique and needs cleanup if it were to be used, it's also semi-tested-and-untested as my llm created this after manually patching containers etc.

Tested on a Frame.work 16" with AMD AI 7 350 CPU (+GPU), w/ NVIDIA RTX 5070 (8GB VRAM) + 96GB DDR5 unified/shared RAM.

See the original issue in NVidia/NemoClaw NVIDIA/NemoClaw#208 (comment)

Summary

• Detect WSL2 at gateway startup (/dev/dxg present) and automatically configure CDI-based GPU injection
• Fixes the complete nvidia-device-plugin failure chain on WSL2: NFD can't see PCI, NVML can't init without libdxcore.so, CDI spec missing per-GPU UUID entries
• All changes are in cluster-entrypoint.sh — no Rust, Dockerfile, or manifest changes needed

What it does

When GPU_ENABLED=true and /dev/dxg exists (WSL2), the entrypoint:

1. Generates CDI spec via nvidia-ctk cdi generate (auto-detects WSL mode)
2. Adds per-GPU UUID and index device entries (nvidia-ctk only generates name=all, but the device plugin assigns GPUs by UUID)
3. Bumps CDI spec version from 0.3.0 to 0.5.0 (library minimum)
4. Patches the spec to include libdxcore.so (upstream nvidia-ctk bug — nvidia-ctk cdi generate: libdxcore.so not found on WSL2 despite being present nvidia-container-toolkit#1739)
5. Switches nvidia-container-runtime from auto to cdi mode
6. Deploys a k3s Job to label the node with pci-10de.present=true (NFD can't detect NVIDIA PCI on WSL2's virtualised bus)

On non-WSL2 hosts, the new code path is never entered (/dev/dxg doesn't exist).

Testing

Verified on:

• Hardware: Framework 16 laptop, AMD CPU, NVIDIA RTX 5070 (8GB VRAM) + 96GB DDR5 shared
• OS: WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2)
• Driver: NVIDIA 595.71, CUDA 13.2
• Result: nvidia-device-plugin 1/1 Running, nvidia.com/gpu: 1 advertised, nvidia-smi works inside sandbox pods, full NemoClaw onboard + sandbox creation + local inference (ollama nemotron 70B) working end-to-end

Related

• Closes bug: GPU passthrough fails on WSL2 — NVML init fails without CDI mode and libdxcore.so #404
• Upstream bug: nvidia-ctk cdi generate: libdxcore.so not found on WSL2 despite being present nvidia-container-toolkit#1739 (nvidia-ctk cdi generate misses libdxcore.so on WSL2)
• Related to feat: Use CDI for GPU injection instead of nvidia-container-cli #398 (CDI migration) — WSL2 is a concrete platform where legacy injection is broken and CDI is the only viable path

Agent Investigation

Diagnosed using openshell doctor commands. Full diagnostic chain documented in #404.

🤖 Generated with Claude Code

[github-actions]

All contributors have signed the DCO ✍️ ✅
_{Posted by the DCO Assistant Lite bot.}

[tyeth]

I have read the DCO document and I hereby sign the DCO.

[tyeth]

recheck

[johntmyers]

Thanks @tyeth. Would it be possible for you to do a fresh smoke test since you mentioned the LLM did this after you already did some manual tuning?

[tyeth]

💯, but not for the next couple of days, my yak shaving missions got out of hand and now work must be the priority 😊

[klueska]

Would it be better to implement a wholistic approach to using CDI, as outlined in #398, rather than building something one-off for WSL2?

[johntmyers]

I would definitely be supportive of a more wholistic approach esp if we have some NVIDIANs willing to do it!

[tyeth]

Would it be better to implement a wholistic approach to using CDI, as outlined in #398, rather than building something on-off for WSL2?

100% agree. This was just going to be lost in the ether if I didn't pr it, and may unblock some GPU hungry souls in the meantime. More of a prod the bear PR to elicit an official solution.