WSL2 installation is failing to complete due to name resolution problems

[thegbomb]

Is there an existing issue for this?

• I have searched the existing issues

Output of ddev debug test

Can't run `ddev debug test` as this is prior to ddev being installed

Expected Behavior

Follow the installation instructions and ddev should be ready to use.

Actual Behavior

Follow the installation instructions and the installation doe not complete .

Steps To Reproduce

On a Windows machine, follow the installation instructions at:
https://ddev.readthedocs.io/en/latest/users/install/ddev-installation/#windows

When running the command:
iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/ddev/ddev/master/scripts/install_ddev_wsl2_docker_inside.ps1'))

The installation stops without ddev being available to use.

The error seems to be coming from one of the apt update, upgrade or install steps, e.g.:
wsl -u root apt-get update
wsl -u root -e bash -c "apt update && apt install -y ddev docker-ce docker-ce-cli containerd.io wslu"
wsl -u root -e bash -c "apt-get upgrade -y >/dev/null"

It seems there is an issue with WSL resolving the server locations at the installation stage, not sure if it persists after the installation completes.

I have researched and found others having this problem which seems to be with the WSL installation rather than ddev, but the fix/workaround can be included to help here.
The issue is here: microsoft/WSL#8365

Anything else?

The general consensus from some of the duplicate tickets (e.g.: microsoft/WSL#4285) seems to be to add the google nameservers to the resolve.conf file to allow WSL to find the required repositories and then complete the update steps.

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

What I am not sure about is whether these changes are required to persist after the installation has been completed.
Hopefully, Windows will fix the issue with WSL and this will stop being an issue.

[rfay]

It is true that your WSL2 system is having trouble with upgrades, but changing its DNS resolution is not the only reason that can happen.

• Are you able to run wsl -u root apt-get update without your workaround? If not, what do you see?
• Did you disable proxy, firewall, and VPN in your testing?

There are in fact some problems with WSL2, especially time shifting, which I've seen recently, please take a look at https://github.com/ddev/ddev/pull/5629/files#diff-e90012dfb1748c653a4703bb70b16e723180d80dc21628001a9466c22c2320be

But we need to know what exactly is happening to you to pursue this. It may be name resolution, or basic connectivity, or time syncing. But thousands of people are using DDEV on WSL2 without your workaround.

[thegbomb]

wsl -u root apt-get update fails without the workaround at the moment.

This wasn't isolated, though. My team (who are mostly remote) have just moved to PC's and all are experiencing the same issue with the domain resolution.

There was no VPN involved, but it could be firewall or proxy related, so I will explore those options and will also explore whether this change is still needed after the initial apt update has been completed.

While I appreciate thousands of people are using DDEV on WSL2 without the workaround, there are 9 duplicated tickets linked in microsoft/WSL#8365 to indicate that it is not just me having issues with WSL networking.

The addition of the nameserver has been the only thing that worked to unblock the team.

Thanks for the response, and I'll let you know any results of further investigation.

[rfay]

You may want to see what your nameservers are currently set to, and try to resolve the relevant domain names inside WSL2

I'm using WSL2 on a random wifi in a cabin in Patagonian Chile waiting out a 3-day rainstorm right now. No problems, no need for this workaround, and I've done this on many different machines.

My (generated) resolv.conf has

nameserver 172.22.144.1

where that's the nameserver handed out by DHCP at the little cabin where I am. You can test the nameserver looking up various things, and you can test a plain vanilla Ubuntu WSL2 instance to see what might be going on. I use nslookup google.com for example.

[thegbomb]

Thanks, I'll see if I can get to the bottom of it.
I feel your pain with the rain storm, it feels like its been raining here in Scotland forever.

[rfay]

Closing for now, please let us know what you learn, happy to continue the conversation here or elsewhere.