WSL2/Ubuntu20.04, all snaps broken after each reboot, even snapd

snapd
1

Hello, I am not familiar with linux. I just enabled WSL2/Ubuntu20.04 on windows10. I tried out snap, installed microk8s, everything seems to work easily, great! Then I found out, after each ubuntu reboot, all the snaps are broken:
$ snap list
Name Version Rev Tracking Publisher Notes
core 11167 latest/stable canonical✓ broken
core18 2066 latest/stable canonical✓ broken
lxd 4.0.6 20326 4.0/stable/… canonical✓ -
microk8s 2213 1.20/stable canonical✓ disabled,broken
snapd 12057 latest/stable canonical✓ broken

I followed some posts and checked the mounted files as below, all snaps seem to have not been mounted:
$ cat /proc/self/mountinfo
107 99 8:16 / / rw,relatime - ext4 /dev/sdb rw,discard,errors=remount-ro,data=ordered
108 107 0:19 /init /init ro,relatime - 9p tools ro,dirsync,aname=tools;fmask=022,loose,access=client,trans=fd,rfd=6,wfd=6
109 107 0:6 / /dev rw,nosuid,relatime - devtmpfs none rw,size=6512884k,nr_inodes=1628221,mode=755
110 109 0:23 / /dev/pts rw,nosuid,noexec,noatime - devpts devpts rw,gid=5,mode=620,ptmxmode=000
111 107 0:17 / /sys rw,nosuid,nodev,noexec,noatime - sysfs sysfs rw
112 111 0:28 / /sys/fs/cgroup ro,nosuid,nodev,noexec - tmpfs tmpfs ro,mode=755
113 112 0:29 / /sys/fs/cgroup/unified rw,nosuid,nodev,noexec,relatime - cgroup2 cgroup2 rw,nsdelegate
114 112 0:30 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpuset
115 112 0:31 / /sys/fs/cgroup/cpu rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpu
116 112 0:32 / /sys/fs/cgroup/cpuacct rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpuacct
117 112 0:33 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,blkio
118 112 0:34 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,memory
119 112 0:35 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,devices
120 112 0:36 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,freezer
121 112 0:37 / /sys/fs/cgroup/net_cls rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,net_cls
122 112 0:38 / /sys/fs/cgroup/perf_event rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,perf_event
123 112 0:39 / /sys/fs/cgroup/net_prio rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,net_prio
124 112 0:40 / /sys/fs/cgroup/hugetlb rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,hugetlb
125 112 0:41 / /sys/fs/cgroup/pids rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,pids
126 112 0:42 / /sys/fs/cgroup/rdma rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,rdma
127 107 0:22 / /proc rw,nosuid,nodev,noexec,noatime - proc proc rw
128 127 0:20 / /proc/sys/fs/binfmt_misc rw,relatime - binfmt_misc binfmt_misc rw
129 107 0:24 / /run rw,nosuid,noexec,noatime - tmpfs none rw,mode=755
130 129 0:25 / /run/lock rw,nosuid,nodev,noexec,noatime - tmpfs none rw
131 129 0:26 / /run/shm rw,nosuid,nodev,noatime - tmpfs none rw
132 129 0:27 / /run/user rw,nosuid,nodev,noexec,noatime - tmpfs none rw,mode=755
133 107 0:18 / /mnt/wsl rw,relatime - tmpfs tmpfs rw
134 107 0:43 / /mnt/c rw,noatime - 9p C:\134 rw,dirsync,aname=drvfs;path=C:;uid=1000;gid=1000;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8
136 127 0:44 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
137 136 0:20 / /proc/sys/fs/binfmt_misc rw,relatime - binfmt_misc binfmt_misc rw
138 112 0:45 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,xattr,name=systemd
139 109 0:46 / /dev/hugepages rw,relatime - hugetlbfs hugetlbfs rw,pagesize=2M
140 109 0:21 / /dev/mqueue rw,nosuid,nodev,noexec,relatime - mqueue mqueue rw
141 111 0:7 / /sys/kernel/debug rw,nosuid,nodev,noexec,relatime - debugfs debugfs rw
142 111 0:10 / /sys/kernel/tracing rw,nosuid,nodev,noexec,relatime - tracefs tracefs rw
143 111 0:47 / /sys/fs/fuse/connections rw,nosuid,nodev,noexec,relatime - fusectl fusectl rw
312 107 8:16 /snap /snap rw,relatime shared:82 - ext4 /dev/sdb rw,discard,errors=remount-ro,data=ordered
313 312 0:48 / /snap/lxd/20326 ro,nodev,relatime shared:83 - fuse.snapfuse snapfuse ro,user_id=0,group_id=0,allow_other
414 132 0:49 / /run/user/1000 rw,nosuid,nodev,relatime - tmpfs tmpfs rw,size=1303032k,mode=700,uid=1000,gid=1000

And here is the snap version:
$ snap --version
snap 2.48.3+20.04
snapd 2.48.3+20.04
series 16
ubuntu 20.04
kernel 5.4.72-microsoft-standard-WSL2

Could you please kindly help?

Many thanks, Tao

2

snapd isn’t officially supported on WSL2, it can be made to work well enough, but it has several caveats.

Firstly, it’s important to say that WSL2 doesn’t actually reboot that often. Just closing the terminal doesn’t kill off the virtual machine its running in, you’d have to do that explicitly with wsl.exe --terminate, which is the equivilent of fully shutting down the VM. If you just close it, you’re not really resetting the VM state fully. This is just something to keep in mind if you’re experimenting with it.

Also, you can turn on “enable other updates from Microsoft”, in the Windows update settings, and that’ll update the Linux kernel WSL2 uses. Unlike the normal distributions, the kernel isn’t updated via the package manager. Again not related, but just nice to know. (Microsoft is on 5.10 now I believe and your system is still on 5.4)

Ultimately it sounds like you’ve exited the process namespace that snapd was running in. You need to re-enter this namespace everytime or you’ll likely find snapd won’t work. There’s some advice from a lot of members in the community on ways on making snapd in WSL2 “just work” by entering and leaving the namespace automatically, but without knowing how exactly you’ve set it up, it’s impossible to say what to do other than try rerun the setup you followed again.

But otherwise, https://snapcraft.ninja/2020/07/29/systemd-snap-packages-wsl2/
Can likely help you out for getting a magically working WSL2 with snaps working, thanks Daniel!

And finally, if you’re looking for a WSL like experience that is a bit more “proper” in the sense of being fully featured but retains the minimalism of just opening a shell and getting to work, give https://multipass.run a go!

3

Hi James-Carroll,

thank you so much for the reply. I setup systemd and snap by following Daniel´s post, but used the script version of Damion (https://github.com/DamionGans/ubuntu-wsl2-systemd-script). That´s basically all I have done.

I am drawn to snap by the youtube video " Kubernetes on Windows with WSL 2 and Microk8s" (https://www.youtube.com/watch?v=DmfuJzX6vJQ&ab_channel=celebrateubuntu).

snap is working great! Except for this very unfortunate problem: after reboot ubuntu, all snaps are broken, even “snapd”. For windows, reboot is inevitably no rare event.

$ snap list
Name Version Rev Tracking Publisher Notes
core 11167 latest/stable canonical✓ broken
core18 2066 latest/stable canonical✓ broken
core20 1026 latest/stable canonical✓ broken
lxd 4.14 20450 latest/stable canonical✓ -
microk8s 2213 1.20/stable canonical✓ broken
snapd 2.50.1 12057 latest/stable canonical✓ broken

Each time, I manually mounte snapd, then remove-install all other snaps.

Following your advices:

  • “enable other updates from Microsoft” has been turned on

  • "Ultimately it sounds like you’ve exited the process namespace that snapd was running in. You need to re-enter this namespace everytime or you’ll likely find snapd won’t work. —> I am not quite sure how to proceed on this. It would be really great if you could give me some detailed instructions.

Many thanks! Tao

4

Unfortunately I’m unfamiliar with the script to tell you exactly how to fix it. I’d try using ./ubuntu-wsl2-systemd-script.sh --force and see if it helps with the problem.

Re-entering the namespace should be done by the script itself, I can see the the code in the script that’s responsible for it, but I wouldn’t know why it isn’t properly being executed. It’s this bit of the script.

You can always attempt to reset WSL2 to a clean state by using wsl.exe --unregister ubuntu followed by ubuntu in the Windows terminal, this would start your WSL2 instance from scratch and allow you to attempt again, but be sure to backup any package lists or work if you resort to this.

But ultimately, I do think Multipass would be better for your usecase, it should work fine alongside WSL2 on Windows 10 Pro (on Windows 10 standard edition, you might have to remove WSL2 in order to install VirtualBox which is a dependency on the home editions of Windows). It supports snap properly, it functions like WSL2 in terms of simple and reliable Linux instances and it’s made by Canonical anyway. I’d expect you’d feel at home with it fairly quickly.

5

Thank you so much. I think I will give Multipass a try, considering that WSL also faces VPN issue :joy:.

6

My preferred, and most-updated, method is stored in my repo here:

7

I had the same problem. And this pull request solved my problem.