Open cktechie2012 opened 5 months ago
Network seems to be there, since the pin test(s) succeeded. But DNS resolution seems to not work. Can you check this manually:
getent hosts dns9.quad9.net
getent hosts dietpi.com
If it fails, please check your DNS nameserver entries:
cat /etc/resolv.conf
Please see the below output:
@.:~$ getent hosts dns9.quad9.net @.:~$ getent hosts dietpi.com @.:~$ @.:~$ @.***:~$ cat /etc/resolv.conf
#
to
domains. #
only
symlink. #
of
nameserver 127.0.0.1 search .
On Mon, Jun 17, 2024 at 2:54 PM MichaIng @.***> wrote:
Network seems to be there, since the pin test(s) succeeded. But DNS resolution seems to not work. Can you check this manually:
getent hosts dns9.quad9.net getent hosts dietpi.com
If it fails, please check your DNS nameserver entries:
cat /etc/resolv.conf
— Reply to this email directly, view it on GitHub https://github.com/MichaIng/DietPi/issues/7114#issuecomment-2174496869, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMGEAVXAOKNL2CQPWCG5KRTZH5LKJAVCNFSM6AAAAABJOYOMQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZUGQ4TMOBWHE . You are receiving this because you authored the thread.Message ID: @.***>
I tried adding the manual entries in the resolv.conf, and then the dietpi is able to ping and get the results
however the moment i run the dietpi-update, the resolv.conf gets reset only to 127.0.0.1 for nameserver dns
curl: (6) Could not resolve host: raw.githubusercontent.com
---------------------------------------------------------------------
[FAILED] DietPi-Update | Unable to continue, DietPi-Update will now
terminate.
***@***.***:~$ ping google.com
ping: google.com: Temporary failure in name resolution
***@***.***:~$ sudo nano /etc/resolv.conf
***@***.***:~$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients directly
to
# all known uplink DNS servers. This file lists all configured search
domains.
#
# Third party programs should typically not access this file directly, but
only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different
symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes
of
# operation for /etc/resolv.conf.
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 127.0.0.1
search .
***@***.***:~$
***@***.***:~$ ping google.com
PING google.com (172.217.12.110) 56(84) bytes of data.
64 bytes from atl26s14-in-f14.1e100.net (172.217.12.110): icmp_seq=1
ttl=115 time=31.3 ms
64 bytes from atl26s14-in-f14.1e100.net (172.217.12.110): icmp_seq=2
ttl=115 time=28.2 ms
^C
--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 28.198/29.747/31.296/1.549 ms
***@***.***:~$ getent hosts dietpi.com
2606:4700:20::ac43:4565 dietpi.com
2606:4700:20::681a:4f3 dietpi.com
2606:4700:20::681a:5f3 dietpi.com
***@***.***:~$ getent hosts dns9.quad9.net
2620:fe::9 dns9.quad9.net
2620:fe::fe:9 dns9.quad9.net
***@***.***:~$
On Mon, Jun 17, 2024 at 4:21 PM CK Techie ***@***.***> wrote:
> Please see the below output:
>
>
> ***@***.***:~$ getent hosts dns9.quad9.net
> ***@***.***:~$ getent hosts dietpi.com
> ***@***.***:~$
> ***@***.***:~$
> ***@***.***:~$ cat /etc/resolv.conf
> # This file is managed by man:systemd-resolved(8). Do not edit.
> #
> # This is a dynamic resolv.conf file for connecting local clients directly
> to
> # all known uplink DNS servers. This file lists all configured search
> domains.
> #
> # Third party programs should typically not access this file directly, but
> only
> # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in
> a
> # different way, replace this symlink by a static file or a different
> symlink.
> #
> # See man:systemd-resolved.service(8) for details about the supported
> modes of
> # operation for /etc/resolv.conf.
>
> nameserver 127.0.0.1
> search .
>
>
> On Mon, Jun 17, 2024 at 2:54 PM MichaIng ***@***.***> wrote:
>
>> Network seems to be there, since the pin test(s) succeeded. But DNS
>> resolution seems to not work. Can you check this manually:
>>
>> getent hosts dns9.quad9.net
>> getent hosts dietpi.com
>>
>> If it fails, please check your DNS nameserver entries:
>>
>> cat /etc/resolv.conf
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <https://github.com/MichaIng/DietPi/issues/7114#issuecomment-2174496869>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/AMGEAVXAOKNL2CQPWCG5KRTZH5LKJAVCNFSM6AAAAABJOYOMQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZUGQ4TMOBWHE>
>> .
>> You are receiving this because you authored the thread.Message ID:
>> ***@***.***>
>>
>
nameserver 127.0.0.1
Are you using Pi-hole, AdGuard Home, Unbound or some other local DNS resolver? It seems to not work. It is generally no good idea to use a DNS resolver for its own host system. Better use a public DNS, like the upstream DNS nameserver used by your local resolver directly. Ad blocking is not required for a server system.
I tried adding the manual entries in the resolv.conf, and then the dietpi is able to ping and get the results
however the moment i run the dietpi-update, the resolv.conf gets reset only to 127.0.0.1 for nameserver dns
Is some software controlling the content?
realpath /etc/resolv.conf
this is the output
dietpi@DietPi:~$ realpath /etc/resolv.conf
/run/systemd/resolve/resolv.conf
dietpi@DietPi:~$
Not using any tool like pihole or adguard
This is the output
dietpi@DietPi:$ realpath /etc/resolv.conf
/run/systemd/resolve/resolv.conf
dietpi@DietPi:$
Not using any tool like pihole or adguard
systemd-resolved
. If you did not install/use this intentionally, get rid of it:
G_SUDO G_AGP systemd-resolved
sudo rm -f /etc/resolv.conf
echo 'nameserver 1.1.1.1' | sudo tee /etc/resolv.conf
getent hosts dietpi.com
If you for whatever reason need to use it, you need to configure it to use a proper upstream DNS.
PSA: don't upgrade now if you're on Armbian bookworm, as they are having issues with their apt repo: https://github.com/armbian/build/issues/6762
I'm not sure if this is related to OP's issue but I figured people running into this will look at this issue first.
Thanks for the heads up. Next release will remove the Armbian repository from DietPi systems, so those kind of issues will then be gone, as long as we do not cause such with our own APT repo 🙂.
Creating a bug report/issue
Required Information
Details:
Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
getent hosts DOMAIN
Steps to reproduce:
Expected behaviour:
Actual behaviour:
Extra details:
Additional logs: