Running Snaps on WSL2 (Insiders only for now)

Hi there, thanks for creating and sharing a great script!
I’ve sent three pull requests for minor improvements to https://github.com/DamionGans/ubuntu-wsl2-systemd-script.

I run LXD and docker on systemd successfully.
I confirmed that the default kernel would do for running docker (The custom kernel is not needed).

I wrote a blog post to set up LXD and docker at


(in Japanese though).
No special steps are needed.
Just as usual installation steps for LXD or docker once systemd is running.
Wonderful!
So thanks again for a great script!

I’ve added an automatic installation and updater script for the custom kernel (if you want to use it) at https://github.com/diddlesnaps/WSL2-Linux-Kernel/wiki/Installation-and-Automatic-updater

2 Likes

I followed all the steps in your post, including installing prerequisites (daemonize, etc.)

Now when I try to run Ubuntu I get:

“/usr/sbin/enter-systemd-namespace: line 10: /usr/sbin/daemonize: No such file or directory”

I’m new to WSL2 but not Linux. I don’t know how to edit Ubuntu’s configuration files without starting it first, but it won’t start. Any ideas? Where is the filesystem? I’ve searched Windows and files are not found so I guess it must be an image file. Hopefully in a standard format I can mount some alternative way (from VirtualBox or something, which I haven’t yet installed on this new Windows 10 PC as I’ve only been using WSL2) and not some Microsoft specific image format. Ideas?

Also, are there default values for the two environment variables set? I didn’t check before I set them. I’ve removed them and the error persists so I’m guessing the value for BASH_ENV is the default, as /etc/bash.bashrc already existed and I verified what was added to it before I exited and tried to restart Ubuntu.

I just installed WSL2 within the past month or so as soon as it became available in Windows Update.

Hi,

You can “break in” to your distro to find out what’s wrong, or revert the changes, by running the following in powershell or cmd.exe:

wsl.exe -e bash --norc

# or

wsl.exe -e sh

If your distro is not the default in WSL then you can specify the correct one with the -d switch:

wsl.exe -d Ubuntu-20.04 -e bash --norc
1 Like

As to the environment variables, they are not present by default until the script added them.

I’ve also worked up a different method that you might want to try instead, but I’ve not created an install script for it yet:

https://snapcraft.ninja/2020/08/06/starting-systemd-in-wsl-when-you-login-to-windows-youll-be-astounded-by-the-speed-improvement/

1 Like

Thanks. Got in. Commented out the new line in bash.bashrc for now. Have to go through the scripts and see what’s not working.

Hi! :grinning:

I am trying to activate systemd and I almost did it.

I followed the instructions from here: https://github.com/DamionGans/ubuntu-wsl2-systemd-script.

After installing this script and running wsl for the first time, the command: “snap version” gives this result:

> snap version                                                                                                 
snap 2.45.1+20.04.2
snapd unavailable
series -

The systemctl command produces this result:

> systemctl                                                                                                     
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

But if I execute a command after that in the current session:

> neofetch

or

> wslfetch

then the message “Sleeping for 1 second to let systemd settle” will appear for a short time (~ 1 or 2 seconds).

Then a welcome message will be displayed:

Sleeping for 1 second to let systemd settle
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 4.19.121-microsoftstandard x86_64)
 * Documentation: https://help.ubuntu.com
 * Management: https://landscape.canonical.com
 * Support: https://ubuntu.com/advantage
  System information as of Wed Aug 26 20:12:21 MSK 2020
  System load: 0.0 Processes: 89
  Usage of /: 6.7% of 250.98GB Users logged in: 0
  Memory usage: 5% IPv4 address for eth0: 172.26.42.54
  Swap usage: 0%
 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic
   https://microk8s.io/ has docs and details.
3 updates can be installed immediately.
0 of these updates are security updates.
To see these additional updates run: apt list --upgradable
Last login: Wed Aug 26 20:10:40 MSK 2020 on pts/0
And after that the "systemctl" command will display a list of available units, their status and states (I'm just giving the end of a large list here): 
LOAD = Reflects if the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
183 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
lines 150-191/191 (END)

The “snap version” command shows that snap and snapd are available:

> snap version                                                                                                  
snap 2.45.1+20.04.2
snapd 2.45.3.1
series 16
ubuntu 20.04
kernel 4.19.121-microsoftstandard

The list of snap packages will be available as well as the packages themselves - I can run the snap packages available to me (GUI applications using VcXsrv or just console applications). But snap packages will only be available to me in the current session of the terminal: if I open a new session of the terminal - snap packets will not be available again.

But when I execute commands again in the new session:

> neofetch

or

> wslfetch

— then again the message “Sleeping for 1 second to let systemd settle” will appear for a short time (~ 1 or 2 seconds).

Then a welcome message will be displayed:

Sleeping for 1 second to let systemd settle
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 4.19.121-microsoftstandard x86_64)
 * Documentation: https://help.ubuntu.com
 * Management: https://landscape.canonical.com
 * Support: https://ubuntu.com/advantage
  System information as of Wed Aug 26 20:12:21 MSK 2020
  System load: 0.0 Processes: 89
  Usage of /: 6.7% of 250.98GB Users logged in: 0
  Memory usage: 5% IPv4 address for eth0: 172.26.42.54
  Swap usage: 0%
 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic
   https://microk8s.io/ has docs and details.
3 updates can be installed immediately.
0 of these updates are security updates.
To see these additional updates run: apt list --upgradable
Last login: Wed Aug 26 20:10:40 MSK 2020 on pts/0

And I can use snap packages again.

Another strange thing is that when I get access to snap packages, or in other words when systemd is activated, it somehow modifies the $PATH environment variable, and then I cannot call windows applications from current wsl session (but in new session I can). For example: “code” to run vs code or “exlorer.exe .” to run the windows explorer:

> exlorer.exe .
zsh: command not found: explorer.exe

But in the new session, I lose the availability of snap packages (or systemd) and can run windows applications from wsl again.

And if print the value of the environment variable $PATH in the session where snap packages are available (or in other words, systemd is activated) will be something:

> echo $PATH
/home/haosmos/.nvm/versions/node/v14.8.0/bin:/home/haosmos/haosmos/.local/bin:/home/haosmos/bin:/usr/local/bin:/home/haosmos/. local/share/umake/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

If output the environment variable $PATH - in a session where snap packages are NOT available (or in other words, systemd is NOT activated) there will be something:

> echo $PATH
/home/haosmos/.nvm/versions/node/v14.8.0/bin:/home/haosmos/haosmos/.local/bin:/home/haosmos/bin:/usr/local/bin:/home/haosmos/.local/share/umake/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Program Files (x86)/NetSarang/Xlpd 6/:/mnt/c/Program Files (x86)/NetSarang/Xftp 6/:/mnt/c/Program Files (x86)/NetSarang/Xshell 6/:/mnt/c/Program Files (x86)/NetSarang/Xmanager 6/:/mnt/c/tools/dart-sass:/mnt/c/Users/Haosmos/AppData/Local/hyper/app-3.0.2/resources/bin:/mnt/c/Windows/System32:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files/dotnet/:/mnt/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Program Files/Dart/dart-sdk/bin:/mnt/c/WINDOWS/System32/wsl:/mnt/c/Users/Haosmos/AppData/Roaming/nvm:/mnt/c/Program Files/nodejs:/mnt/c/Program Files/PowerShell/7/:/mnt/c/Program Files (x86)/Common Files/Acronis/VirtualFile/:/mnt/c/Program Files (x86)/Common Files/Acronis/VirtualFile64/:/mnt/c/Program Files (x86)/Common Files/Acronis/FileProtector/:/mnt/c/Program Files (x86)/Common Files/Acronis/FileProtector64/:/mnt/c/Program Files (x86)/Common Files/Acronis/SnapAPI/:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files/Git/cmd:/mnt/c/Users/Haosmos/AppData/Local/Microsoft/WindowsApps:/mnt/c/Program Files/Microsoft VS Code/bin:/mnt/c/Users/Haosmos/AppData/Local/GitHubDesktop/bin:/mnt/c/Users/Haosmos/AppData/Local/Programs/Microsoft VS Code/bin:/mnt/c/Program Files (x86)/Python38-32:/mnt/c/Program Files (x86)/Python38-32/Scripts:/mnt/c/ProgramData/chocolatey/bin:/mnt/c/tools/dart-sdk/bin:/mnt/c/Users/Haosmos/AppData/Roaming/Pub/Cache/bin:/mnt/c/Program Files/JetBrains/WebStorm 2020.2/bin:/mnt/c/Program Files/JetBrains/PhpStorm 2020.1.2/bin:/mnt/c/Users/Haosmos/AppData/Local/Microsoft/WindowsApps:/mnt/c/Program Files/JetBrains/WebStorm 2020.1/bin:/mnt/c/Program Files (x86)/Microsoft/Edge/Application/msedge.exe:/mnt/c/Program Files/Firefox Developer Edition/firefox.exe:/mnt/c/Program Files/Internet Explorer/iexplore.exe

I recorded a short video with a demonstration of what I have described above — https://yadi.sk/i/gRPIMDwaDqt6uw

Please tell me how to make snap packages (or more generally systemd) and commands to run windows applications always available in wsl 2?

My environment: Windows 10 OS version: 2004 OS build: 20197.1000 (insider preview “dev”) WSL: Ubuntu-20.04.1 Linux kernel: 4.19.121

Try executing those commands in bash with the bash command

i followed these steps and am now getting an “access denied” error trying to access WSL. has anyone else experienced this? tried to reinstall and got this error:

Installing, this may take a few minutes…
WslRegisterDistribution failed with error: 0x80070005
Error: 0x80070005 Access is denied.

nevermind - i’m dumb. just had to edit ~/.wslconfig to remove the kernel. i’m guessing it’s a permissions error to that folder

To the author

When I tried it according to the article, when I started UBUNTU-20.04, at the beginning,
/ bin / cat: /root/.systemd-env: No such file or directory
Will come out.
It may not be a problem, but what does this mean?
Is there a way to avoid the appearance of this wording?

For those who use zsh instead of bash, you need to to modify your /etc/zsh/zshrc file the same way as the /etc/bash.bashrc

You can use this command to do so

sudo sed -i 2a"# Start or enter a PID namespace in WSL2\nsource /usr/sbin/start-systemd-namespace\n" /etc/zsh/zshrc

I have created a small python script to achieve this. Yes, it is very hacky.

You can use it as follows:

pushd ~/
wget https://gist.githubusercontent.com/mavaddat/f4f83b23386111bedd7f8199949601af/raw/b408efa0b707b0a86a95c0863847f41277a70e0b/fixSnaps.py
sudo python3 fixSnaps.py
popd

Additionally, add sudo python3 fixSnaps.py to your ~/.bashrc to immediately fix broken snaps upon bash initialization.

Crazy question. How does one backout these changes? I rushed into this and realized it’s causing more problems for me than solving.

So far I move the two /usr/sbin files out of there, and commented out the bashrc line. Thinking I need to undo the BASH_ENV settings (not sure what the W11 defaults are) and maybe uninstall some packages?

So, I was trying to install VS Code:

sudo snap install code --classic

But I got the following error:

error: cannot communicate with server: Post
http://localhost/v2/snaps/code: dial unix /run/snapd.socket: connect:
no such file or directory

I have no idea what to do, I even deleted and reinstalled snap, but the error still appears…

I did:

sudo apt autoremove --purge snapd

and then:

sudo apt update && sudo apt upgrade
sudo apt install snapd

It doesn’t work!

Then I tried:

sudo service snapd start

The output:

snapd: unrecognized service

If I do:

snapd services

Output:

snap    2.54.3+20.04.1ubuntu0.2                                                                                         
snapd   unavailable                                                                                                     
series  -

With the command:

systemctl status snapd.service

I get the following:

System has not been booted with systemd as init system (PID 1). 
Can't operate.                                          
Failed to connect to bus: Host is down    

What is the reason this is happening? I’m using wsl2

@stinger don’t know if it’s still relevant, but you could check the service with systemctl status snapd.service and if there is an error with journalctl -xe. It might tell you something. The fixup script made by @mavaddat is also very good, I need it as well each time.

All of this is a bit hacky, but hey, running snaps in WSL is really cool :slight_smile:

Now when I run the initial instructions, @lucyllewy recommends using a custom kernel which would then fix the confinement of snapd. But it seems it doesn’t really do that anymore:

╭─bneyr@XX-PChJXl9b ~
╰─$ snap version
snap    2.56.2
snapd   2.56.2
series  16
ubuntu  20.04
kernel  5.10.102.1-microsoft-snapd+
╭─bneyr@XX-PChJXl9b ~
╰─$ uname -a
Linux XX-PChJXl9b 5.10.102.1-microsoft-snapd+ #1 SMP Thu May 12 18:56:51 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
╭─bneyr@XX-PChJXl9b ~
╰─$ snap debug confinement
partial

╭─bneyr@XX-PChJXl9b ~
╰─$ snap debug sandbox-features
confinement-options:  classic devmode
dbus:                 mediated-bus-access
kmod:                 mediated-modprobe
mount:                freezer-cgroup-v1 layouts mount-namespace per-snap-persistency per-snap-profiles per-snap-updates per-snap-user-profiles stale-base-invalidation
seccomp:              bpf-actlog bpf-argument-filtering kernel:allow kernel:errno kernel:kill_process kernel:kill_thread kernel:log kernel:trace kernel:trap kernel:user_notif
udev:                 device-cgroup-v1 device-filtering tagging

It seems some features are missing in my current setup, most notably the apparmor stuff. Is there something I need to install?

Thanks to everyone contributing to this!

Brecht

Unfortunately the 5.10 series kernels had an issue during the build that I didn’t spot until it came to enabling apparmor in 5.15. This meant that the extra patches required for snapd strict confinement weren’t actually being added. The 5.15 kernels should work correctly again. You can get the latest kernel from https://github.com/diddlesnaps/WSL2-Linux-Kernel/releases/latest. This needs to be copied to <your user's home directory>\AppData\Roaming\wsl2-custom-kernel. This requires that your WSL2 be shutdown so that you can overwrite the original file, which you can force with wsl --shutdown.

I think there is an issue with the One Script WSL2 Systemd kernel updater, which I need to investigate, because this should happen automatically on login to Windows.

So we have a new wrinkle in using snaps under WSL, which I ran into while experimenting with the new native systemd support in recent WSL builds. Unfortunately, I don’t think they have anything to do with the native systemd support, as I had snaps running under it just fine (once solving the need to mount securityfs under it, which was not necessary under the systemd hacks) for a while.

But then this happened:

❯ snap list                                                                                                                                                                                                         
Interacting with snapd is not yet supported on Windows Subsystem for Linux.
This command has been left available for documentation purposes only.

I am very puzzled as to why this started happening now, as so far as I can tell it was introduced 'way back in the day, in this commit from 2018 - sanity: refuse to try to do things on WSL. · snapcore/snapd@1adae13 (github.com) - which we should in theory have been saying since all the way back in snapd 2.37. (My current Debian installation has 2.57.4, and when I checked, 2.37’s been in Debian since bullseye.

And yet happening now it is.

Ironically, while this prevents snap from running, and thus snaps being managed, and leaves systemd degraded because snap won’t run in snap.seeded.service, the snaps themselves actually work just fine.

❯ which hello                                                                                                                                                                                                       
/snap/bin/hello

❯ hello                                                                                                                                                                                                             
Hello, world!

There’s a PR open to remove this check - https://github.com/snapcore/snapd/pull/12179 - but if you see the problem in the meantime, that’s where it is.

1 Like

Workaround:

Ensure you have systemd-binfmt.service installed in your distro (in Ubuntu that means having the binfmt-support package installed via apt), then execute the following:

echo ":windowsexe:M::\x4d\x5a::/init:PF" | sudo tee -a /etc/binfmt.d/windowsexe.conf

This will replace the WSLInterop binfmt support with an identical configuration under a different name. To activate this, leave WSL and run wsl --shutdown in a PowerShell or CMD window. Next time you restart your distro it should replace the WSLInterop binfmt configuration with this renamed copy so that snapd can’t tell that it’s on WSL.

1 Like

Same here. After the announcement of systemd now working with WSL2 I installed and setup everything properly and tested using snap, installed some snaps and things worked fine. Now I just found out when trying to run snap refresh that this message is being shown, but I have no idea what changed that would trigger this now and not before. Installed snaps still run, just as you described.

But since the fix for this has been merged I’ll likely just wait for the updated snapd getting released.