Cannot install lxd snap in WSL


#1

I can’t seem to get the LXD snap to install; it fails repeatedly at the install hook stage, with the following message:

$ sudo snap install lxd
error: cannot perform the following tasks:
- Run install hook of "lxd" snap if present (run hook "install": dropping privs did not work: No data available)
[1]    2885 exit 1     sudo snap install lxd

I’ve not seen this problem on any other snaps thus far. I’ve also done various searches for this error, but so far, no joy in finding things that could be relevant to this case. Any thoughts on where I should be looking for the problem?

Versions as follows:

$ snap --version
snap    2.39.3
snapd   2.39.3
series  16
debian  10
kernel  4.19.52-microsoft-custom-g7fec2bd4a7fd

#2

Does installing hello-world work? Once installed can you run hello-world ?


#3

Yes, it installs just fine. There is the minor permissions glitch I mention here: Snap install permissions glitch , but once that’s tweaked, it also runs fine.

In specific others I can confirm as working are chromium, dwarf-fortress, glances, hello, mqtt-explorer, robo3t-snap, snap-store, snapcraft, and wormhole; each of these also suffered from that minor permissions glitch but the same chgrp cleared that right up. It’s only lxd, as far as I can tell, that has this install hook problem.


#4

I wonder if this has anything to do with Snap install permissions glitch. Note that the lxd snap is quite special in what it is allowed to do via its lxd-support interface and it isn’t surprising that other snaps work fine where it might not. In general, you’ll need very specific kernel configurations for container managers like lxd to work correctly, so that could be something else to check. You might look at /snap/lxd/current/snap/hooks/* to see where it is failing.


#5

You could also try adding SNAPD_DEBUG=1 to the snapd daemon’s environment and run again, that might include useful output for debugging


#6

That was exactly it. Not surprising, really, once I realized the extent of the breakage. :grinning:


#7

How did you get a kernel with squashfs enabled? The currently available kernel installed as part of the subsystem doesn’t have it, and I can’t find any details on how to use a custom kernel… (note that the upstream MS repo on github does have the configuration enabled from about a week after the date of compilation of the currently available pre-built kernel)

uname:

4.19.43-microsoft-standard

#8

This isn’t an official/supported method yet (although per conversations in the WSL github, there’s going to be an official method soon), but it’s possible to replace the WSL kernel right now. Details here: