Thanks daniel. I went through all the steps again and recreated those two scripts as suggested. I’m sure those are there and correct now.
I did mess up one step the first time I went through the steps. I pasted the cmd.exe ... in the Ubuntu terminal instead of the Windows terminal. So I have fixed that.
I am getting a diff error message this time, which is probably a good thing:
During startup of VSCode, as it is Opening Remote, I am still getting the Starting VS Code in WSL (ubuntu): Installing WSL components message in the corner.
Followed by this error:
[2019-10-21 14:02:37.046] Starting VS Code Server inside WSL (ubuntu) [2019-10-21 14:02:37.047] Extension version: 0.39.9, Windows build: 18980. Multi distro support: enabled. WSL path support: enabled [2019-10-21 14:02:37.509] Probing if server is already installed: C:\WINDOWS\System32\wsl.exe -d ubuntu -e sh -c "[ -d ~/.vscode-server-insiders/bin/82ca6ba87f450245f665ab7a5f3a686e2cd00045 ] && echo found || ([ -f /etc/alpine-release ] && echo alpine || echo x64)" [2019-10-21 14:02:37.885] No server install found in WSL, needs x64 [2019-10-21 14:02:37.887] Launching C:\WINDOWS\System32\wsl.exe -d ubuntu sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 82ca6ba87f450245f665ab7a5f3a686e2cd00045 insider .vscode-server-insiders 0 ' in c:\Users\Joel\.vscode-insiders\extensions\ms-vscode-remote.remote-wsl-0.39.9 [2019-10-21 14:02:38.222] your 131072x1 screen size is bogus. expect trouble [2019-10-21 14:04:10.895] VS Code Server for WSL failed to start. No messages received for 90s [2019-10-21 14:04:10.895] For help with startup problems, go to [2019-10-21 14:04:10.895] https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips
The only diff between those messages is
Before:
[2019-10-18 19:50:24.045] Server install found in WSL
After:
[2019-10-21 14:02:37.885] No server install found in WSL, needs x64
And this at the end:
[2019-10-21 14:04:10.895] VS Code Server for WSL failed to start. No messages received for 90s [2019-10-21 14:04:10.895] For help with startup problems, go to [2019-10-21 14:04:10.895] https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips
Do you have any other suggestions? Thank you for your time.
As a debugging step, can you open a terminal in your Ubuntu-based WSL. Separately, tell VSCode to connect so that you reproduce the timeout. Once you’ve hit the timeout run the following in the terminal you opened first:
$ grep WSLENV ~/.systemd-env
We’re looking for the output of grep to read similar to:
WSLENV=VSCODE_WSL_EXT_LOCATION/up:BASH_ENV/u
If it is there, run another grep:
$ grep VSCODE_WSL_EXT_LOCATION= ~/.systemd-env
This is expected to show something similar to below, with the path for your user folder instead of mine:
I screwed up by editing the visudo file in vim instead of visudo. After I fixed that, everything seems to be working. So, everything in the tutorial seems right on. Thank yoiu.
This tutorial is not about Docker so feel free to ignore this question, but when I try to open Docker in windows I get a message that says,
“This is a command line tool.
You need to open cmd.exe and run it from there.”
Edit: When I use a docker command like docker ps it says
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
After googling an hour I think it might be related to it looking for it in the old location, and we are sorta running in a different way.
Again, feel free to ignore this Docker question. It a little is off-topic. Thank you for your help.
Well… things are a little more borked that I thought. I can’t get the “WSL 2 Tech Preview” Docker 2.1.00 to run anymore. When I click the “start” button in the Tech Preview GUI It says
Error from Lifecycle Server
exit status 1
Here is the log from Docker Lifecycle:
Here is the log from Docker Daemon:
The PATH file does seem to have unescaped characters in it. It was not an issue before, and I don’t think they were introduced in these instructions.
Also worth noting. When I tried the troubleshooting greps, those enteries were all missing. I added them to the file manually. Not sure why they were missing or if other things were missing too. I tried to followed the instructions to a T.
Any help debugging would be helpful. I thought it would be helpful to add this comment for other people trying this.
I’ve been trying to debug it for a few hours. I had a co-worker who is much smarter than me try to help me fix this for an hour, and he gave up and suggested I nuke it all and remove any new files that were introduced. If I have lost the ability to use VSCode with WSL 2, its not worth the trade off. High stakes to get Snap.
This is all cutting edge experimental stuff with WSL 2. I’m sure its me and not the instructions. It is just part of being on the latest and greatest new stuff.
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 Thanks for your continuing help debugging and suggestions.
Edit: this has broken VSCode again 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)
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.
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!.
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.
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?
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
You can find it here: https://github.com/DamionGans/ubuntu-wsl2-systemd-script
Again thanks a lot and I wish you the best!
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.
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
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"
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…
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?
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.
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.
Thanks for your continuing help debugging and suggestions.
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)