There are several technical shortcomings, that I can think of, that make snapd not really work:
I can recall some people made an experiment where a fake systemd would be installed (just a bunch of scripts) that would unpack squashfs files and would fake some service startup but this was barely a demo, at best.
Yes, that is what we did (or Matteo) did for OpenWRT. See the scripts here https://github.com/teknoraver/snap-openwrt/tree/master/snapd/files for some more details. This should get you around the missing systemd but leaves the other two points (confinement, squashfs).
Hi All,
Thanks for all your replies. Perhaps not the answer I was hoping for but, at least, you have cleared up the situation.
Hi all,
@morphis, thanks! Your scripts are what I would try on Slackware. Are they work reliable for you on OpenWRT?
You’re going to have a bad time with this, as the functionality of Snaps have evolved considerably since those scripts were made and snapd expects more things from systemd.
You’d be better off setting up a deputy systemd under your current init. The reason it couldn’t be done for OpenWrt was because of the size constraint and the old kernels. Slackware should have no such restrictions.
Last I checked, there was also some SlackBuilds for setting up systemd on Slackware, so that’s an option, too.
Thanks @Conan_Kudo.
Unfortunately, Slackers hate systemd, so it’s seems no ready way to incorporate systemd there.
All I found is systemd packages in Dlackware - Dropline Gnome Slackware, which seems just swaps Slacware’s system init to systemd, for Gnome3 usage. But it is not what I want.
So, my current intention is to run systemd in Docker container in Slackware. Maybe I would have better luck with it.
But to be honest, Snaps dependency on systemd seems awkward for me…
Thanks anyway
Hi, I’m having the same problem. I’m running the very latest Windows 10 Preview and as far as I can see systemd is supported. However, I have the same error messages due to snapd not being started. I’ve started started snapd manually, which seems to work. However, now I have the mentioned issue with squashfs. Looking into that.
UPDATE: this is the error I get
unsquashfs -i -d /tmp/read-file468023474/unpack
/tmp/snapd-sideload-pkg-827422431 meta/snap.yaml" failed: exit status 1 ("Read on filesystem
failed because EOF
Systemd is not supported in WSL. Snapd is not installed since that (and many other things) are not available on Windows.
Does anyone have the current status of snap support on WSL2? AIUI, there are some missing patches for AppArmor in the kernel there and maybe missing squashfs support? Anything else missing?
systemd is not being used as the init process (PID 1). You can try to mess about to try to get it to operate as not-PID-1 but it is not easy.
I know this was the case for WSL1, is it still the case for WSL2?
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:
(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 .)
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.
The graphical snaps I’ve tried so far (chromium, dwarf-fortress, mqtt-explorer, robo3t-snap, snap-store) all work nicely under WSL with X410. 
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?
That’s an impressive amount of detective work! awesome!
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.)
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.
