No /dev/dri available on latest Kernel

[kfoxirl]

Windows Version

Microsoft Windows [Version 10.0.19045.5247]

WSL Version

2.4.11.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.6.75.1

Distro Version

Arch Latest

Other Software

No response

Repro Steps

export __GLX_VENDOR_LIBRARY_NAME=mesa
export __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/50_mesa.json
export GALLIUM_DRIVER=d3d12
export MESA_LOADER_DRIVER_OVERRIDE=d3d12
export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/dzn_icd.x86_64.json
export PICOM_DEBUG=always_rebind_pixmap
export PULSE_SERVER=unix:/run/user/1000/pulse

1. Build KConfig based on working config for 6.6.36 Kernel running.
2. Update .wslconfig to point to custom Kernel
3. Mount modules.vhdx in windows with wsl --mount --vhd d:\WSL\kernels\modules.vhdx --name kernel-modules
4. Create a systemd service to create a link to the modules.vhdx in /mnt/wsl/kernel-modules to /lib/modules/$(uname -r) after local-fs.target
5. Confirm modules are available on vhdx file.
6. Shutdown distro and shutdown wsl
7. Mount modules.vhdx
8. Start WSL and Start Distro

Expected Behavior

That the following nodes be available for rendering.

/dev/dri/card0
/dev/dri/card1
/dev/dri/renderD128

Actual Behavior

I can launch apps that dont use the rendernode like glxinfo and glxgears successfully but anything that looks for the cards or the render node at /dev/dri fails. Manually loading dxgkrnl or any driver Ive tried for that matter makes no difference.

Diagnostic Logs

No response

[github-actions]

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:

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

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to wsl-gh-logs@microsoft.com with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

[kfoxirl]

WslLogs-2025-02-25_04-01-29.zip

[github-actions]

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

Diagnostic information

.wslconfig found
	Custom kernel command line found: 'rnodes=1'
	Custom kernel found: 'd:\WSL\kernels\bzImage6.6.75'
Detected appx version: 2.4.11.0
Found no WSL traces in the logs

[kfoxirl]

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

I did.

[zcobol]

Karl Fox (@kfoxirl) dxgkrnl support is built into the kernel:

CONFIG_DXGKRNL=y

To get your /dev/dri entries you need to load vgem module, and it works if you find the correct path where vgem.ko is located.

The layout of the modules.vhdx is not packaged properly. This is the top listing:

zcobol@texas:~$ tree -L 1 /mnt/wsl/kernel-modules/
/mnt/wsl/kernel-modules/
├── lib
├── lost+found
├── modules.alias
├── modules.alias.bin
├── modules.builtin.alias.bin
├── modules.builtin.bin
├── modules.dep
├── modules.dep.bin
├── modules.devname
├── modules.softdep
├── modules.symbols
├── modules.symbols.bin
└── modules.weakdep

3 directories, 11 files 

When linking /mnt/wsl/kernel-modules to /lib/modules/$(uname -r) you end up with the modules under:

/lib/modules/6.6.75.1-microsoft-standard-WSL2/lib/modules

and the kernel won't find them. There must be an error in the script packaging the modules.vhdx. Didn't check yet!

[kfoxirl]

@kfoxirl dxgkrnl support is built into the kernel:

CONFIG_DXGKRNL=y

To get your /dev/dri entries you need to load vgem module, and it works if you find the correct path where vgem.ko is located.

The layout of the modules.vhdx is not packaged properly. This is the top listing:

zcobol@texas:~$ tree -L 1 /mnt/wsl/kernel-modules/
/mnt/wsl/kernel-modules/
├── lib
├── lost+found
├── modules.alias
├── modules.alias.bin
├── modules.builtin.alias.bin
├── modules.builtin.bin
├── modules.dep
├── modules.dep.bin
├── modules.devname
├── modules.softdep
├── modules.symbols
├── modules.symbols.bin
└── modules.weakdep

3 directories, 11 files 

When linking /mnt/wsl/kernel-modules to /lib/modules/$(uname -r) you end up with the modules under:

/lib/modules/6.6.75.1-microsoft-standard-WSL2/lib/modules

and the kernel won't find them. There must be an error in the script packaging the modules.vhdx. Didn't check yet!

Loading vgem did the trick with the missing /dev/dri nodes :)

[chessturo]

A fixed script and instructions are now available on the kernel repo; thank you for the report!