DesktopECHO/kWSL

Apt update resolve problem

h13World opened this issue · 7 comments

The installation script gets stuck in a loop because the network is not able to resolve the apt sources. This problem is the same as in the issue #25

:APTRELY
START /MIN /WAIT "Git Clone kWSL" %GO% "cd /tmp ; rm -rf kWSL ; git clone -b %BRANCH% --depth=1 https://github.com/%GITORG%/%GITPRJ%.git ; cp /tmp/kWSL/keyrings/*.gpg /etc/apt/trusted.gpg.d/"
START /MIN /WAIT "apt-get update" %GO% "apt-get update 2> /tmp/apterr"
START /MIN /WAIT "apt-get update" %GO% "add-apt-repository -y ppa:videolan/master-daily 2>> /tmp/apterr"
FOR /F %%A in ("%DISTROFULL%\rootfs\tmp\apterr") do If %%~zA NEQ 0 GOTO APTRELY
START /MIN /WAIT "apt-fast" %GO% "DEBIAN_FRONTEND=noninteractive dpkg -i /tmp/kWSL/deb/aria2*.deb /tmp/kWSL/deb/libaria2-0*.deb /tmp/kWSL/deb/libssh2-1*.deb /tmp/kWSL/deb/libc-ares2*.deb ; chmod +x /tmp/kWSL/dist/usr/local/bin/apt-fast ; cp -p /tmp/kWSL/dist/usr/local/bin/apt-fast /usr/local/bin" > NUL

There is a problem with the network connection and the apt update is not able to resolve the hostnames from the apt sources list.

Ign:1 http://security.ubuntu.com/ubuntu jammy-security InRelease
Ign:2 http://archive.ubuntu.com/ubuntu jammy InRelease
Ign:3 http://archive.neon.kde.org/user jammy InRelease
Ign:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
Ign:1 http://security.ubuntu.com/ubuntu jammy-security InRelease
Ign:2 http://archive.ubuntu.com/ubuntu jammy InRelease
Ign:3 http://archive.neon.kde.org/user jammy InRelease
Ign:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
Ign:2 http://archive.ubuntu.com/ubuntu jammy InRelease
Ign:1 http://security.ubuntu.com/ubuntu jammy-security InRelease
Ign:3 http://archive.neon.kde.org/user jammy InRelease
Ign:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
Err:2 http://archive.ubuntu.com/ubuntu jammy InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Err:3 http://archive.neon.kde.org/user jammy InRelease
  Temporary failure resolving 'archive.neon.kde.org'
Err:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease
  Temporary failure resolving 'archive.ubuntu.com'
Err:1 http://security.ubuntu.com/ubuntu jammy-security InRelease
  Temporary failure resolving 'security.ubuntu.com'
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/jammy-security/InRelease  Temporary failure resolving 'security.ubuntu.com'
W: Failed to fetch http://archive.neon.kde.org/user/dists/jammy/InRelease  Temporary failure resolving 'archive.neon.kde.org'
W: Some index files failed to download. They have been ignored, or old ones used instead.

So, this command always jumps via APTRELY back to the top:
FOR /F %%A in ("%DISTROFULL%\rootfs\tmp\apterr") do If %%~zA NEQ 0 GOTO APTRELY

From a Windows command prompt, does ping archive.neon.kde.org resolve?

Yes it does.

>ping archive.neon.kde.org

Ping wird ausgeführt für 1613612302.rsc.cdn77.org [156.146.61.130] mit 32 Bytes Daten:
Antwort von 156.146.61.130: Bytes=32 Zeit=37ms TTL=53
Antwort von 156.146.61.130: Bytes=32 Zeit=35ms TTL=53
Antwort von 156.146.61.130: Bytes=32 Zeit=28ms TTL=53
Antwort von 156.146.61.130: Bytes=32 Zeit=28ms TTL=53

Ping-Statistik für 156.146.61.130:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 28ms, Maximum = 37ms, Mittelwert = 32ms

nslookup from the wsl distribution:

nslookup archive.neon.kde.org
;; UDP setup with fec0:0:0:ffff::1#53(fec0:0:0:ffff::1) for archive.neon.kde.org failed: invalid file.
;; UDP setup with fec0:0:0:ffff::1#53(fec0:0:0:ffff::1) for archive.neon.kde.org failed: invalid file.
;; UDP setup with fec0:0:0:ffff::1#53(fec0:0:0:ffff::1) for archive.neon.kde.org failed: invalid file.
;; UDP setup with fec0:0:0:ffff::2#53(fec0:0:0:ffff::2) for archive.neon.kde.org failed: invalid file.
;; UDP setup with fec0:0:0:ffff::3#53(fec0:0:0:ffff::3) for archive.neon.kde.org failed: invalid file.

After I add the hostname config to the /etc/hosts file the ping from the wsl distribution succeeds
156.146.61.130 archive.neon.kde.org. archive.neon.kde.org

Can you temporarily disable IPv6 in Windows?

;; UDP setup with fec0:0:0:ffff::3#53(fec0:0:0:ffff::3) for archive.neon.kde.org failed: invalid file.

This indicates you have IPv6 DNS set in Windows, but the DNS server is not replying to IPv6 queries.

Sorry for the late reply.

I tried to disable IPv6 in Windows, but I even if I manually set the IPv4 DNS and disable IPv6 DNS at my ethernet adapter it still isn't able to resolve the hostnames.

I found out that I have the problem in all wsl distributions and it is an issue with my client and not an error in kWSL.

The file /etc/resolv.conf in all distributions:

nameserver fec0:0:0:ffff::1
nameserver fec0:0:0:ffff::2
nameserver fec0:0:0:ffff::3

When I edit /etc/wsl.conf and change the parameter generateResolvConf to false and then create the file /etc/resolv.conf myself with the IPv4-DNS then the hostname resolution works again as it should.

Tried to do the same in kWSL (Change parameter in dist/etc/wsl.conf and create dist/etc/resolv.conf), but here I still have the same problem. Am I missing something or is this resolution not possible in kWSL?

@h13World Do you maybe have TailScale installed? That was what caused the resolv.conf issues for me.
I exited tailscaled and disabled the tunnel like here after which it worked

@NullDev thank you very much for the hint. TailScale caused the issue for me also.
But I was able to resolve the issue differently. I didn't disable the tunnel, I just disabled IPv6 in configuration.

kWSL3

What I still don't fully understand is why I don't have the same problem with another client that also has TailScale installed.

Interesting! Its good to know that disabling IPv6 instead of the entire tunnel is sufficient because I was afraid of re-enabling it so far 😅