The (or "a", depending on the context) "system distribution" in WSL is a bit oddly named, but probably meant to be the converse of a "user distribution". It's also a bit difficult to explain. There's an overview in the original WSLg Architecture devblog post from about 2 years ago.
For most users, there's really no need to understand or use the system distribution, other than curiosity. However, it can be useful for:
- Debugging WSLg/GUI issues in WSL
- If desired, modifying or replacing WSLg functionality.
- Understanding what that weird
--system argument is for in the WSL help ;-)
First, some additional "terminology". To understand what the "system distribution" is, we first need to really understand what a "distribution" is in WSL. Short summary - A distribution is a namespace isolated environment (container) running inside the WSL2 VM. See this answer for more detail.
There are actually multiple system distributions:
A template, root filesystem (based on CBL Mariner, as noted in @Panki's answer) which is provided with WSL itself. This root filesystem is then used to create ...
A system distribution (namespace container) for each of your other running user distributions (e.g. Ubuntu, Alpine, Kali, Arch, etc.). This system distribution is where Wayland (with RDP/RAILS), Xwayland, Weston, and PulseAudio run. The sockets for these services are then mounted, bind-mounted and/or symlinked (the techniques have changed over time) into the user distribution when it is started. This system distribution has the same lifecycle as the sibling user distribution.
A default WSL installation uses Ubuntu (currently 20.04) as the distribution. In this case, when you start WSL/Ubuntu, a corresponding system distribution is started, the services are started, and the symlinks/mounts are created from the system distribution back to Ubuntu. The architecture is common to all Linux distributions that run under WSL. Some distributions (I'm looking at you, GNU Guix ;-)), however, may deviate too far from the "norm" and require additional work in order to use WSLg to run GUI applications.
The main mount is /mnt/wslg (which, as you mentioned, should be /dev/sda -- I'd never actually noticed that before). The /tmp/.X11 directory where the X11 socket(s) live is (now) a read-only, bind-mount back to /mnt/wslg/.X11-unix.
Similar bind-mounts or symlinks are created for Wayland and PulseAudio, although I haven't fully explored all the nooks and crannies of the architecture.
So, when you start WSL, you can then separately start:
wsl --system
You'll see that your default user is wslg there. You could, however, access it as wsl --system -u root as well.
You could also start with wsl --system and you would find (with wsl -l -v) that your default distribution had also been started.
Because the "per-distribution" system distribution is created "on demand" each time a WSL distribution starts, it is ephemeral. Any changes you make while in wsl --system (or wsl --system -d <user_distro_name>) will be lost when the user distribution is stopped.
To make the changes permanent, you can build your own system distro using the WSLg repository on Github and replace the one that WSLg uses with a .wslconfig file. I'm honestly not aware of anyone outside of Microsoft finding the need to do this in the almost two years since WSLg has been available, but it's certainly an interesting capability. At the least, it allows you to upgrade (or even rollback) a component like Weston without having to wait for Microsoft to make the change.
