Running Snaps on WSL2 (Insiders only for now)

snapd
22

You’re correct that it seems there is an unescaped pair of parentheses which is causing BASH to complain. I’ve not given the docker tech preview a try yet, but I’ll download and see what I can discover :slight_smile: Thanks for your continuing help debugging and suggestions.

23

I’ve got docker for wsl2 tech preview running!

You need to edit /usr/sbin/enter-systemd-namespace and change line 20 to:

/bin/bash -c 'set -a; source "$HOME/.systemd-env"; set +a; exec bash -c '"$(printf "%q" "$@")"

Edit: this has broken VSCode again :frowning: still working on it Edit2: fixed - both docker for wsl2 tech preview and vscode remote extension are working for me with the line above (I’ve amended the original post to show the full file that I’m using)

1 Like
24

That fixed it I’m up and running with WSL2, with VSCode, and Snap. Docker and docker-compose are working. Now I am trying to get Snap working with a docker build. Thank you @lucyllewy.

2 Likes
25

With systemd enabled using this guide (complete with the custom kernel, it might works too without it). I able to use docker in WSL2 natively in Ubuntu without Docker Desktop Tech Preview. Using Docker Desktop Tech Preview with this setup, gives me an error that the daemon cannot start. Just don’t forget to “docker login” first in Ubuntu WSL2 befor using “docker run” or “docker pull” command. Thanks so much Daniel!.

3 Likes
26

Working great, was able run snaps now.
Is there some way to disable the system information echo, when starting a new bash session?

27

This does enable Snaps for me, however I hit a few snags along the way:

I was unable to compile my own Kernel from the repo listed - I got a bunch of compile errors.
I followed along with the precompiled kernel instead which did get me to the end result of working Snaps, however my WSL2 terminal now starts as Root, rather than my user.

28

Also ran into a problem were opening additional shells will crash with
“ConEmuC: Root process was alive less than 10 sec, ExitCode=0.
Press Enter or Esc to close console…”
Anyone seen this before?

29

Hello there, I want to thank you @lucyllewy for getting systemd to work on Ubuntu for WSL2! It certainly has made my WSL2 adventures more easy. I wanted to notice you that I made a script of it on GitHub :slight_smile: You can find it here: https://github.com/DamionGans/ubuntu-wsl2-systemd-script Again thanks a lot and I wish you the best!

1 Like
30

Hi Damion- have been using this for a while but kept hitting an issue- using VSCode remotely, my terminal always opened in my home directory. I figured that’s happening because the command in enter namespace is using bash --login. I tried some workaround, but not knowing this stuff that well, am not sure if I broke something else that I just haven’t noticed yet-

if [ -n "$SYSTEMD_PID" ] && [ "$SYSTEMD_PID" != "1" ]; then
        if [ -n "$1" ] && [ "$1" != "bash --login" ] && [ "$1" != "/bin/bash --login" ]; then
                exec /usr/bin/nsenter -t "$SYSTEMD_PID" -a /usr/bin/sudo -H -u "$SUDO_USER" /bin/bash -c 'set -a; source "$HOME/.systemd-env"; set +a; exec bash -c '"$(printf "%q" "$@")"
        elif [ -n "$1" ] && [ "$1" == "bash --login" ] || [ "$1" == "/bin/bash --login" ]; then
                exec /usr/bin/nsenter -t "$SYSTEMD_PID" -a /bin/login -p -f "$SUDO_USER" $(/bin/cat "$HOME/.systemd-env" | grep -v "^PATH=")
        else
                exec /usr/bin/nsenter -t "$SYSTEMD_PID"  --preserve-credentials -a /bin/bash -c 'set -a; source $HOME/.systemd-env; set +a;'"cd ${PWD}; exec bash"
        fi
fi

Trying to skip the login if we are already in the namespace and --login wasn’t specified.

31

Hey, thanks a lot for your reply. It looks like something I can fix, but I will not do now. That is because I will need to test it somewhat thoroughly, for which I don’t have the resources right now. I will try to fix it later, though. If it’s not fixed by someone else, I will give it a shot :slight_smile:

32

No worries, just figured this was a good place to share in case anyone else had the same issue.

I did find an issue with the previous command- nsenter drops supplemental groupids, so the traditional docker group wasn’t working. I got that working by using this-
/usr/bin/nsenter -t "$SYSTEMD_PID" --mount -p /bin/bash -c 'set -a; source $HOME/.systemd-env; set +a;'"cd ${PWD}; su $SUDO_USER"

33

I’ve followed the latest instructions and even used the precompiled kernal. When I run snap version and snap debug confinement I get the expected results. But when I run sudo snap install hello-world I am getting: error: access denied (see 'snap help login'). I created an Ubuntu One account and tried to login, but after putting in my password I get the same exact message. The output of snap version is:

➜  dev-files snap version
snap    2.42.1+18.04
snapd   2.42.1+18.04
series  16
ubuntu  18.04
kernel  4.19.72-microsoft-standard+

I am zsh via oh my zsh!. I doubt that is the issue, though…

34

I figured out something (weird to me, but probably not others) that if I run /usr/bin/env bash after wsl boots, it puts me into the right context to now use something as simple as sudo snap list. Maybe this does have something to do with ZSH?

35

Hi Guys,
Do we have version of this scripts for running in ZSH ?

36

I have noticed something that messes up the scripts when on 20.04. The fix is to have the “ps -ef” commands be “ps -efw”. Without that “-w” the output is truncated, one of the calls will fail to find in start, the other will succeed and will not spawn anything, which causes my gnome-terminal sessions to instantly close after the first one.

Adding the -w to both ps commands fixed it for me.

1 Like
37

Additionally, I have managed to fix a few issues that happened on my system.

First, in start-systemd-namespace I have also added $(pwd) and in my copy I said something like export SAVED_PWD="$(pwd)". Of course, you probably would do something like export PRE_NAMESPACE_PWD="$(pwd)". At the end of the script I also did a cd to that variable.

Second, in enter-systemd-namespace I have had serious issues with the environment due to an interesting issue – your literal “$HOME” in the /bin/login case actually evaluates to /root on my system (or /home/root if root’s homedir is moved there) rather than the correct one. I have replaced $HOME with $(eval echo ~$SUDO_USER). Now it’s reliable enough.

Finally, for some reason that -w issue from before stopped affecting me after a reinstall? Not sure. (EDIT: scratch this one, my terminal was simply wider)

EDIT 2: Also unset the variables once they’re used. This way if I just do ctrl-shift-t in a gnome-terminal they are not overridden.

1 Like
38

Unfortunately, I cannot edit the forum post above anymore, because it’s too old so the forum has locked it. I’m helping to maintain the code at https://github.com/damionGans/ubuntu-wsl2-systemd-script now

Edit: I’m marking this comment as “The Solution” so that passers-by hopefully see the link…

2 Likes
39

Alright, I will send pull requests addressing the issues. Thanks for notifying.

1 Like
40

Double check that they’re required, as I recently made a substantial change to improve things like the home directory…

41

Sure, I’ve already sent some other minor improvements which I do believe are still applicable. I’ll

check if the home directory handling still needs fixing before sending anything related to that.

Thanks.

Mail](https://go.microsoft.com/fwlink/?LinkId=550986) for Windows 10

A755AF79EA1F4C6691B4E7BDC582DE56.png

1 Like