CASE STUDY · WSL2

A Complete Linux Inside Windows - and How It Rescued a Model Training Run

A true story from one long night: torch on Windows segfaulted three times on the same line while loading a 26GB weights file - across three versions, on a hash-verified file. The fix wasn't new hardware. It was WSL2: the same machine, the same GPU, a second operating system running beside the first.

What WSL2 actually is

Windows Subsystem for Linux is real Linux - a real kernel, a real Ubuntu - running in a lightweight VM managed by Windows. Not dual-boot (no reboot to switch), not emulation (near-native speed), and nothing gets replaced.

Windows 11 - one host system

The usual apps

ComfyUI · the Studio · browser

WSL2 · Ubuntu

Linux kernel · venv · ai-toolkit

││

RTX 3060 - one card, shared by both (GPU passthrough, full CUDA)

Two worlds with a bridge: from Linux, the Windows drives appear under /mnt/c, /mnt/d - and from Windows you run Linux commands with wsl.

Why we needed it at all

The problem: loading 26.3GB of model weights segfaulted inside torch_cpu.dll - on torch 2.6, 2.7.1 and 2.8, with and without every flag we could throw at it. The file itself was fine (SHA-256 verified against the source). A bug in torch's Windows build, unfixable from the outside.

The reasoning: the exact same library is compiled separately for Linux - a completely different code path. If the bug lives in the build, another OS on the same hardware routes around it. And so it went: on Linux the same line produced an informative error instead of a crash - and from there it could be fixed.

Installing it - the path that actually worked

Three steps. Watch step 2 - the trap most guides never mention.

# 1 · Enable the features (PowerShell as admin) + reboot
dism /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
shutdown /r /t 5

# 2 · The trap: the built-in wsl.exe is a stub that wants an interactive window.
#     For remote/scripted installs, install the REAL package from GitHub:
#     github.com/microsoft/WSL/releases  ->  wsl.x.x.x.x64.msi
msiexec /i wsl_setup.msi /qn

# 3 · Install Ubuntu (no window, no Store)
wsl --install -d Ubuntu --no-launch

Getting in and working

What you want	How
A Linux terminal	`wsl -d Ubuntu`
A single command	`wsl -d Ubuntu -- ls /root`
A whole script	`wsl -d Ubuntu -- bash /mnt/d/script.sh`
Windows files from Linux	`/mnt/c/…` · `/mnt/d/…`
Linux files from Windows	`\\wsl$\Ubuntu\root\…` in Explorer
Full shutdown (frees RAM/GPU)	`wsl --shutdown`

A rule learned the hard way: nested commands (ssh -> cmd -> wsl -> bash) silently mangle quoting. Always write a script to a file, ship it over, and run bash /mnt/d/x.sh - never a chain of quote marks.

The tuning that made the difference

WSL's default: half your RAM. Not enough for loading a huge model - the file at C:\Users\<you>\.wslconfig controls resources:

[wsl2]
memory=26GB          # how much RAM the VM gets
swap=40GB            # swap file - spills to disk when RAM runs out
swapFile=D:\\wsl_swap.vhdx

(After changing it: wsl --shutdown for it to take effect.)

The limit you'll hit: the /mnt/d bridge (the 9p protocol) cannot memory-map huge files. Loading 26GB through it fails - the fix is a plain read into memory instead of mmap, or copying the file onto Linux's internal disk.

Forwarding environment variables (tokens etc.) from Windows to Linux - by name, without exposing the value: setx WSLENV HF_TOKEN/u - and from then on every WSL session sees the variable.

The bottom line

	Windows native	WSL2 on the same machine
Loading the model	segfault ×3	works
LoRA training	impossible	26s/step, 200MB VRAM headroom
Cost	-	$0 · two hours of setup

ComfyUI and the Studio keep running on Windows as usual; Linux wakes up only for training, borrows the GPU for a few hours, and hands it back. One machine, two worlds, zero compromises.