Windows Subsystem for Linux

yes it is still the case for WSL2

I have got snapd running successfully under WSL 2.

It does, however, require the use of one additional tool of mine, and one distinctly unsupported (although hopefully soon to be unnecessary) piece of hackery.

genie ( https://github.com/arkane-systems/genie ) takes care of the systemd blocker by creating a pid namespace “bottle” in which systemd is happy to run as pid 1 (and brings its various services along with it), and taking care of automatically entering it for you.

The hackery - well, at the moment it’s unofficial, but it is possible to recompile and replace the kernel WSL 2 uses. (Instructions here: https://gist.github.com/cerebrate/d40c89d3fa89594e1b1538b2ce9d2720 .) As you can see from the supplied .config, I’ve used this to add squashfs and apparmor support.

With both of those set up, snapd runs just fine:

10 Likes

(With regard to the being unofficial “at the moment”, customizing WSL kernels is being investigated, per https://github.com/microsoft/WSL/issues/4173 ; and squashfs support is in any case arriving in an upcoming Insider build: https://github.com/microsoft/WSL/issues/4123 .)

3 Likes

Excellent! Combine that with an X server and we can start running graphical snaps on Windows!

One Package Manager to rule them all, One Package Manager to find them,
One Package Manager to bring them all, and in the darkness bind them,
In the Land of Canonical where the Best Devs lie.

1 Like

The graphical snaps I’ve tried so far (chromium, dwarf-fortress, mqtt-explorer, robo3t-snap, snap-store) all work nicely under WSL with X410. :smiley:

5 Likes

Nice work, I would love to see you work closer with other snapd developers. Perhaps you would consider joining us on free node IRC channel #snappy?

2 Likes

That’s an impressive amount of detective work! awesome!

1 Like

Ok - perhaps a dumb question, but is anyone working to remove the systemd dependency from snap? Seems like this is an anti-pattern that others have refactored around. It’s an issue blocking WSL but it also affects docker, which is a huge deal. Rather than take this dependency on systemd, and be dependent upon herculean workarounds, why not remove this dependency and make everyone’s life easier? (Asking for a friend.)

1 Like

I agree with aaronsteers. WSL2 is not a replacement for WSL1 which does not rely on the Linux kernel. Same goes for running Ubuntu without a Linux kernel under Mac. Or native linux containers LXC/LXD and LXE (kubernetes). None support systemd.