After spending hours building a Yocto Linux image in WSL2, it is discouraging to see it crash with a deceptively simple error with surprisingly complex root causes:
No space left on device (errno = 28, ENOSPC) This error often shows up late in the build after you’ve already invested significant time, and it can come back even after cleaning up build files and artifacts. The reason is that WSL storage has one extra layer compared to a typical Linux workstation, and Yocto is excellent at stressing it.
This post walks through what ENOSPC really means in WSL2, why Yocto triggers it so reliably, how to diagnose the root cause, and the correct fixes that make your builds predictable again.
What ENOSPC Actually Means (and Why WSL2 Makes It Trickier)
On a traditional Linux machine, ENOSPC usually means one of two things:
- You’re out of disk space
- You’re out of inodes (metadata entries used to track files)
In WSL2, there’s a third common cause: the Linux filesystem lives inside a virtual hard disk file on Windows (typically ext4.vhdx). So, you effectively have two storages:
- Inside WSL2 (Linux view) – An ext4 filesystem with “available space”
- On Windows (host view) – A VHDX file that must be able to expand on the host disk
If the VHDX can’t grow (because the Windows host drive is full, or because you’ve hit a configured limit), Linux reports ENOSPC even if you clearly remember deleting a bunch of files yesterday.
Why Yocto Builds Hit the Wall So Fast
Yocto produces a large amount of output and (more importantly) a massive number of small files. A typical build tree can easily exceed 100GB once you include build artifacts, shared state, downloads, logs, and repeated iterations. A representative footprint looks like this:
| build/tmp | ~ 90 GB |
| sstate-cache | ~ 9 GB |
| downloads | ~ 2 GB |
Even a “single” build can push you into triple-digit GB usage quickly, especially with multiple machine configs, SDKs, images, or rebuild cycles. This is why even developers with large SSDs hit space issues faster than expected.
Why You Shouldn’t Put Yocto Under /mnt/…
It’s tempting to just place your Yocto workspace on a Windows host drive (/mnt/c/yocto/…), so it uses space on your physical SSD instead of the virtual hard disk file. But the Windows filesystem (NTFS) gets mounted into WLS via a translation layer. That cross-OS layer is convenient, but it’s not optimized for this style of compilations/builds that deal with hundreds of thousands of files.
Microsoft’s guidance for these situations is straightforward: for best performance, keep your build files inside the WSL filesystem. So, using the physical SSD won’t work in this case, and we should keep the Yocto tree under something like ~/yocto, and not under /mnt/c…
The Right Fix: Clean, Reclaim, and Put the VHDX on the Right Disk
Step 1: Clean Yocto Build Artifacts (Inside WSL)
If you need to get unblocked quickly, removing build outputs helps:
rm -rf build/tmp/*
rm -rf sstate-cache/*
rm -rf downloads/* This frees space inside ext4, which may be enough to complete a build.
Step 2: Shrink/Optimize the VHDX (So Windows Actually Gets Space Back)
Deleting files inside ext4 does not necessarily reduce the physical size of ext4.vhdx. It’s common for the VHDX to grow during heavy workloads and not automatically return that space to Windows.
To reclaim space on the Windows host, shut down WSL, then optimize the VHDX from PowerShell:
wsl --shutdown
Optimize-VHD -Path "D:\WSL\Ubuntu\ext4.vhdx" -Mode Full This approach is commonly recommended for compacting WSL VHDX files after cleanup.
Note: Optimize-VHD requires the Hyper-V VHD tooling (available on many Windows editions). If you don’t have it, you may need to enable the appropriate Windows features.
Step 3: Move the WSL Distribution to a Larger Drive
If your Yocto workflow is a long-term need, the most robust fix is to ensure the distro (and therefore the VHDX file) lives on a drive with plenty of headroom.
Method 0: Why “Moving Ubuntu” in Windows Settings Doesn’t Work
Windows has an app setting that appears to “move” Ubuntu. In practice, this often moves the application wrapper, not necessarily the underlying storage you care about (VHDX file). If you need more space, you typically need to move the distribution’s VHDX (or relocate the distro) to a larger drive using WSL-supported methods (covered below).
Method A: Export / Import (Reliable and Widely Supported)
wsl --export Ubuntu D:\backup\ubuntu.tar
wsl --unregister Ubuntu
wsl --import Ubuntu D:\WSL\Ubuntu D:\backup\ubuntu.tar --version 2 This moves the distro storage to D:\WSL\Ubuntu
Method B: wsl –manage –move (Newer, Simpler)
Newer WSL releases include a built-in move command:
wsl --update
wsl --manage Ubuntu --move D:\WSL\Ubuntu This is supported in WSL versions that include the –move option and is often the cleanest approach when available.
Conclusion
In WSL2, “No space left on device” often isn’t just about what df shows inside Linux. It’s about how WSL stores Linux data in a Windows-hosted VHDX that expands over time and may not automatically shrink.
The most reliable path to predictable Yocto builds is:
- Yocto is not a 20 GB project. Budget hundreds of GB.
- Keep Yocto workspaces on ext4 inside WSL (not /mnt/*).
- Clean build artifacts when needed.
- Compact the VHDX after cleanup.
- Move the VHDL file to a larger drive.
If you are working through WSL2 and/or Yocto setup challenges, or “works‑on‑my‑machine” issues across your team, DMC can help you design and set up a development environment that is stable, scalable, and fast.
Learn more about DMC’s embedded development and programming expertise and contact us today to get started.