3

I'm trying to install nvm using curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash on WSL2, but I'm getting different errors. Initially, the curl command would return the following:

> $ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash                                        
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:09 --:--:--     0curl: (6) Could not resolve host: raw.githubusercontent.com

After running netsh int ip reset in Windows, which was suggested in another question, the same command started timing instead:

> $ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash                                        
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:04:59 --:--:--     0
curl: (28) Connection timed out after 300000 milliseconds

I've also tried manually saving the install.sh to my machine and running it locally (after setting its permissions with chmod +x install.sh), but that returns a similar error:

> $ ./install.sh                                                                                                           
=> Downloading nvm from git to '/home/mparra/.nvm'
=> Cloning into '/home/mparra/.nvm'...
fatal: unable to access 'https://github.com/nvm-sh/nvm.git/': Failed to connect to github.com port 443: Connection timed out
Failed to clone nvm repo. Please report this!

I can successfully ping github.com. ping -c 100 github.com returns the following:

--- github.com ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99156ms
rtt min/avg/max/mdev = 15.280/20.739/85.205/9.141 ms

This issue suggests that a Windows update resolved the issue, but that's not an option for me since it's a work machine and I can't update beyond build 18363.2039. I've also checked that my VPN is not enabled and I set my DNS to 8.8.8.8 and 8.8.4.4, which had no effect.

Mario Parra
  • 1,504
  • 3
  • 21
  • 46

2 Answers2

4

Please try the following in your WSL

sudo rm /etc/resolv.conf
sudo bash -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'
sudo bash -c 'echo "[network]" > /etc/wsl.conf'
sudo bash -c 'echo "generateResolvConf = false" >> /etc/wsl.conf'
sudo chattr +i /etc/resolv.conf

I can install with curl.

Tabares
  • 4,083
  • 5
  • 40
  • 47
  • 1
    **For those who are wondering what this does:** it deletes your resolve.config file thats automatically generated when u run WSL then creates a new file and puts "nameserver 8.8.8.8", then creates a wsl.conf file and adds [network] and generateResolveConf = false to prevent auto generation of that file – Matt Jaf Dec 01 '22 at 01:11
1

I have a feeling you are probably correct about this being the same issue mentioned on Github that was resolved in a Windows update.

If that's truly the case, you are probably going to continue to run into issues even after getting nvm installed. For instance, nvm probably will have trouble downloading Node releases.

The easiest solution that I can propose, if it works for you, is to simply convert to WSL1 instead of WSL2. WSL1 will handle most (but not all) Node use-cases just as well as WSL2. And WSL1 handles networking very differently than WSL2. If the Windows networking stack is working fine for you, then WSL1's should as well.

As noted in that Github issue, this seemed to be a problem that occurred only in Hyper-V instances. WSL2 runs in Hyper-V, but WSL1 does not.

If you go this route, you can either:

  • create a copy of your existing WSL2 distribution and convert that copy to WSL1. From PowerShell:

    wsl --shutdown
wsl -l -v # Confirm <distroname>
wsl --export <distroname> path\to\backup.tar
mkdir .\path\for\new\instance
wsl --import WSL1 .\path\for\new\instance path\to\backup.tar --version 1 # WSL1 can be whatever name you choose
wsl -d WSL1

    Note that you'll be root, by default. To change the default user, follow this answer.

  • Or, just convert the WSL2 instance to WSL1:

    wsl --shutdown
wsl -l -v # Confirm <distroname>
wsl --export <distroname> path\to\backup.tar # Just in case
wsl --set-version <distroname> 1

If WSL1 doesn't work for you (at least in the short term until your company pushes that update), then there may be another option similar to the one mentioned in this comment on that Github issue. Let me know if you need to go that route, and I'll see if I can simply that a bit.

NotTheDr01ds
  • 15,620
  • 5
  • 44
  • 70
  • 1
    Thanks for taking the time to explain and write all of this! I'm gonna play it safe and go the copy route. What directory do you recommend for the new instance? Not sure if it can be just anywhere. Thank you – Mario Parra Feb 02 '22 at 20:55
  • @MarioParra It's pretty flexible as far as the directory location goes. It can even be a separate drive. I don't suggest a removable, but I've tried it and it does work. I tend to set all my WSL instances up (and I have a lot) under something like `%userprofile%\Documents\WSL\instances\distroname` and I put my backup images (`.tar`s) in `%userprofile%\Documents\WSL\images`. – NotTheDr01ds Feb 02 '22 at 21:05
  • Thank you. I successfully made a copy and converted it to WSL1 and restarted my computer. I thought installing `nvm` with the `curl` command worked since it ran correctly as root (`wsl -d WSL1`), but `nvm` is still not found under zsh in VS Code, even after adding the `export` in `~/.zshrc`. Running the command under zsh still times out too. Did I miss something? – Mario Parra Feb 02 '22 at 21:51
  • @MarioParra Trying to "think fast" here since I have to run out the door in just a few minutes :-). In VSCode, confirm that you are in WSL1 instance using `echo $WSL_DISTRO_NAME`. Also (this probably isn't it since the networking has improved), double-check `wsl -l -v` to make sure the version is 1. You don't have the Windows `nvm` installed as well, right? I've known that to cause issues with the Linux `nvm`. Also check (going from memory here) `type nvm`. – NotTheDr01ds Feb 02 '22 at 21:59
  • You're on the right track. VS Code returns "Ubuntu", which is my WSL2. The Remote - WSL extension auto-starts WSL and `wsl -l -v` confirms that it's starting WSL, which wasn't before. I tried `wsl --set-default-version 1` earlier, but it didn't work, so it must just be a case of running the wrong instance. – Mario Parra Feb 02 '22 at 22:08
  • Okay, `wsl --setdefault WSL1` worked, but the Remote VS Code extension still runs WSL2 and returns an error loading my extensions. Weird. – Mario Parra Feb 02 '22 at 22:23
  • @MarioParra So I'm wondering ... VSCode saves the WSL instance as part of the workspace. Are you starting VSCode then opening a workspace? In that case, it is probably still using the WSL2 instance. If that's the problem, you can open the WSL1 one by either (a) starting in WSL1 and using `code .` or (b) Using the `Remote-WSL: New WSL Windows using Distro ...` command in VSCode (either from the toolbar's "Remote" menu or the command palette). – NotTheDr01ds Feb 03 '22 at 00:49
  • Hmm so when I run the `New WSL Windows using Distro...` command from the command palette (and it even shows that WSL1 is the default), the terminal in that new window runs within WSL1, `nvm` works, etc., but when I open VS Code after quitting it, it still starts WSL2 (Ubuntu). If I close the workspace and start a new one, nothing automatically starts, so I think it might've been associated with the workspace like you suggested. Thank you! – Mario Parra Feb 03 '22 at 01:46