snapd can't start in WSL (Windows Subsystem for Linux)

[Balint Reczey]

Snapd can't be started:

ubuntu@DESKTOP-V4DDKSS:~$ sudo /usr/lib/snapd/snapd
[sudo] password for ubuntu:
AppArmor status: apparmor not enabled
2019/03/27 10:36:05.383446 daemon.go:379: started snapd/2.37.4+18.10.1 (series 16; classic; devmode) ubuntu/18.10 (amd64) linux/4.4.0-17134-Microsoft.
2019/03/27 10:36:05.407044 main.go:123: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount: /tmp/sanity-mountpoint-175479274: mount failed: Operation not permitted.

2019/03/27 10:36:10.413624 daemon.go:611: gracefully waiting for running hooks
2019/03/27 10:36:10.413702 daemon.go:613: done waiting for running hooks
daemon stop requested to wait for socket activation

Please fall back to using bind mount instead of using squashfs when mounting squasfs images is not supported. (Bind mounts work in WSL.)

[Balint Reczey (rbalint)]

Snap command does not work either:

ubuntu@DESKTOP-V4DDKSS:~$ snap list lxd
Interacting with snapd is not yet supported on Windows Subsystem for Linux.
This command has been left available for documentation purposes only.

[John Lenton (chipaca)]

How would bind mounts let you read a squashfs?

[Balint Reczey (rbalint)]

On Wed, Mar 27, 2019, 21:05 John Lenton <email address hidden> wrote:

> How would bind mounts let you read a squashfs?
>

They would not themselves, but snapd could unsquashfs the contents
somewhere, then read-only bind mount the locations.

> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1821956
>
> Title:
> snapd can't start in WSL (Windows Subsystem for Linux)
>
> Status in snapd package in Ubuntu:
> New
>
> Bug description:
> Snapd can't be started:
>
> ubuntu@DESKTOP-V4DDKSS:~$ sudo /usr/lib/snapd/snapd
> [sudo] password for ubuntu:
> AppArmor status: apparmor not enabled
> 2019/03/27 10:36:05.383446 daemon.go:379: started snapd/2.37.4+18.10.1
> (series 16; classic; devmode) ubuntu/18.10 (amd64)
> linux/4.4.0-17134-Microsoft.
> 2019/03/27 10:36:05.407044 main.go:123: system does not fully support
> snapd: cannot mount squashfs image using "squashfs": mount:
> /tmp/sanity-mountpoint-175479274: mount failed: Operation not permitted.
>
> 2019/03/27 10:36:10.413624 daemon.go:611: gracefully waiting for running
> hooks
> 2019/03/27 10:36:10.413702 daemon.go:613: done waiting for running hooks
> daemon stop requested to wait for socket activation
>
> Please fall back to using bind mount instead of using squashfs when
> mounting squasfs images is not supported. (Bind mounts work in WSL.)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1821956/+subscriptions
>

[John Lenton (chipaca)]

WSL also does not (last I checked) support GUI apps, nor daemons, or even ship systemd (not sure if systemd can run on WSL), nor udev, nor does apparmor work (does seccomp work?).

Meaning that the only snaps that you could use on WSL are ones that don't have daemons, nor GUIs. And the confinement would be wack. And snapd would have to learn about mounting things itself instead of leaving it to systemd.

It's a lot of work, for very little gain, AFAICT.

[Balint Reczey (rbalint)]

@chipaca:

How To Run Graphical Interface [GUI] Of Linux Application in Windows 10 [Windows Subsystem]
https://www.youtube.com/watch?v=DT2XHtdGMOc

https://token2shell.com/howto/x410/enabling-sound-in-wsl-ubuntu-let-it-sing/

https://dev.to/ironfroggy/wsl-tips-starting-linux-background-services-on-windows-login-3o98

[Balint Reczey (rbalint)]

@chipaca:

I agree that confinement would not work yet, but let's make running snaps work then let Microsoft fix the kernel layer's missing security features.

[Zygmunt Krynicki (zyga)]

I understand the desire to support WSL but let one thing sink in: the snaps are not working *precisely* because the kernel layers is missing features.

[John Lenton (chipaca)]

For the mounting issue, try running snapd with SNAPPY_SQUASHFS_UNPACK_FOR_TESTS=1

[John Lenton (chipaca)]

(I doubt that alone would be enough...)

[Rafael David Tinoco (rafaeldtinoco)]

For WSL2:

I have installed systemd-genie (an initial namespace pid starting systemd basically) in order to get systemd working there. Unfortunately for WSL2, instead of the kernel compatibility layer, they have a real kernel that also has some support issues (since its not an Ubuntu Kernel). By having systemd and squashfs-fuse, we can make it work without any special kernel support.

Other kernels can be configured using wslconfig file, and specifying a new "Ubuntu" kernel. Unfortunately, afaik, that has to be built-in right now (couldn't find a way to get an initrd there).