Sudo: unable to resolve host {hostname}: Name or service not known

I am stuck in a circle and have no idea how to escape.

When updating Pi or restarting services I get
“sudo: unable to resolve host pihole-server: Name or service not known”

The hostname file contains one entry
"pihole-server"

The hosts file:
"127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

127.0.1.1 webserver"

If I add hostname line to hosts file to:

"127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

127.0.1.1 webserver
127.0.0.1 pihole-server "

This nag goes away and I get another warning

"Warning in DNSMASQ core:
not giving name pihole-server.lan to the DHCP lease of 192.168.1.251 because the name exists in /etc/hosts with address 127.0.0.1

Warning in DNSMASQ core:

not giving name pihole-server to the DHCP lease of 192.168.1.251 because the name exists in /etc/hosts with address 127.0.0.1"

To get rid of this warning I remove

"127.0.0.1 pihole-server" from the Hosts file

…and then the “..unable to resolve host….” warning returns.

Can any kind soul please give me a shove in the right direction?

Many thanks!

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

Aha!

https://tricorder.pi-hole.net/yPAs9w7h/

I'm not sure if this is enough information or whether it has expired and I have to resend a new URL?

Please send us a new token. The old one has expired.

https://tricorder.pi-hole.net/U525fN24/

Is this the right place to post these links?

This message is typical for a Raspberry Pi connected via both ethernet and wifi if one of the interfaces doesnt have a static IP configuration.
This interface will try to acquire an IP from Pi-hole's own DHCP service, and during the DHCP lease transaction, will advertise its own hostname to the DHCP server (Pi-hole).
The DHCP service is refusing this name thats advertised via DHCP because it already exists in the /etc/hosts file.

Thank you for that,. It sort of helps inasmuch that I have now disabled wifi.

However the issue remains when updating Pi or restarting services I get
“sudo: unable to resolve host pihole-server: Name or service not known”

Re static IP addresses:

The Pi eth0: is configured as 192.168.1.133/24.

I really would like to know if this is the right place to post the debug log url which I have refreshed again - see below
https://tricorder.pi-hole.net/rYOhYkyQ/

Many thanks for your kind patience!.

1 Like

Figure out your hostname:

pi@ph5b:~ $ hostname
ph5b

Figure out your DNS search/suffix domain:

pi@ph5b:~ $ pihole-FTL dhcp-discover
[..]
   domain-name: "home.dehakkelaar.nl"

Edit below file so it resembles:

pi@ph5b:~ $ sudo nano /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       ph5b.home.dehakkelaar.nl  ph5b

Check:

pi@ph5b:~ $ hostname -f
ph5b.home.dehakkelaar.nl
1 Like

Hi,

Thank you for taking the time to respond. I followed your wise guidance and rebooted.

I subsequently discovered that I had foolishly not amended the dhcpdc file to reflect the hostname under

"# Inform the DHCP server of our hostname for DDNS.
webserver"

[new hostname webserver applied in hostname and hosts files .]

This has been done and the problems described appear to have gone away.

However, if I then run pihole-FTL dhcp-discover I get a new warning....

"Warning in dnsmasq core: no address range available for DHCP request via lo"

I understand this is something to do with 'loopback' [?] Interestingly running the inbuilt generate debug log also fires up dhcp-discover and generates the same error [as one would expect]

Everything appears to be working so do I just ignore the lo warning, or does it suggest something in my setup needs attention?

Pi-hole is operating alongside Apache2 [Port 80]. lighttpd has an additional external.conf file with "server.port = 8080". I'm not sure if lightpd is being used?

A fresh log is now available
https://tricorder.pi-hole.net/mEpri7yD/

1 Like

Dont do that!

pi@ph5a:~ $ man dhcpcd
[..]
     -h, --hostname hostname
             Sends hostname to the DHCP server so it can be registered
             in DNS.  If hostname is an empty string then the current
             system hostname is sent.  If hostname is a FQDN (i.e., con‐
             tains a .) then it will be encoded as such.

This setting is intended for if the host were to acquire an IP via DHCP.
If correct, your Pi doesnt acquire an IP via DHCP anymore and instead, those details are set statically:

pi@ph5a:~ $ tail /etc/dhcpcd.conf
[..]
interface eth0
  static ip_address=10.0.0.2/24
  static routers=10.0.0.1
  static domain_name_servers=10.0.0.1

Best to restore that line to default:

# Inform the DHCP server of our hostname for DDNS.
hostname

Nothing to worry about, I have the same message when do a dhcp-discovery:

pi@ph5a:~ $ pihole -t
[..]
00:26:25 dnsmasq-dhcp[6589]: DHCPDISCOVER(eth0) b8:27:eb:xx:xx:xx
00:26:25 dnsmasq-dhcp[6589]: DHCPOFFER(eth0) 10.0.0.33 b8:27:eb:xx:xx:xx
00:26:25 dnsmasq-dhcp[6589]: no address range available for DHCP request via lo

Its highly unusual to assign an IP address to the loopback interface named lo via DHCP.
Addresses (EDIT: IPv4 + IPv6) for the lo interface are already set during boot:

pi@ph5a:~ $ ip -br address show lo
lo               UNKNOWN        127.0.0.1/8 ::1/128

Ps. when copy & paste code output to here, best to select/highlight the code output with your mouse, and click on the </> button so the output gets displayed like in my examples above:

image

deHakkelaar,

Thank you for your very kind and wise guidance.

I have reinstated the dhcpdc file to read

# Inform the DHCP server of our hostname for DDNS.
webserver

and we are back to square one-ish. I now get warnings;

Warning in dnsmasq core:
not giving name webserver.lan to the DHCP lease of 192.168.1.202 because the name exists in /etc/hosts with address 127.0.1.1
	
2022-01-18 18:22:17	DNSMASQ_WARN	Warning in dnsmasq core:
not giving name webserver to the DHCP lease of 192.168.1.202 because the name exists in /etc/hosts with address 127.0.1.1

I also find Pi intermittently flaky. On reboot, it would randomly reinstate wifi after disabling it in the GUI. I have hopefully permanently clobbered it with an entry in /boot/config under

[All]

dtoverlay=disable-wifi

Irritatingly I have to keep setting the Wifi country to GB, for it seems to intermittently forget, despite a correct entry in

/etc/wpa_supplicant/wpa_supplicant.conf

So we are almost back to square one. At least the sudo: unable to resolve host... has gone away, for now! Ha!

I'm not sure if this is useful info?

If I visit www.familysearch.org - it works fine. However clicking the
displayed link to www.familysearch.org/search/ - just one level down - nothing. Disable pi-hole and it is fine.

Adding the site to the whitelist as either Regex Whitelist or Exact Whitelist makes no difference.

Maybe it is time to remove pi-hole and start again.

1 Like

Above looks wrong and should look like below:

Above sounds as if the WiFi interface is still active and trying to acquire an IP via DHCP.
Is Raspbian/Pi-OS installed?

lsb_release -a

What model Pi do you have?

cat /proc/cpuinfo

What driver modules are loaded?

lsmod

Maybe you need the "dtoverlay=pi3-disable-wifi" from below instead of "dtoverlay=disable-wifi"?

If trying above, after a reboot, check with lsmod if a driver is missing now.
FYI, my Pi3 loads below driver for wifi:

pi@arcade:~ $ lsmod
Module                  Size  Used by
[..]
brcmfmac              307200  0
[..]
pi@arcade:~ $ modinfo brcmfmac
filename:       /lib/modules/4.14.34-v7+/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko
license:        Dual BSD/GPL
description:    Broadcom 802.11 wireless LAN fullmac driver.
[..]
pi@arcade:~ $ dmesg -T | grep brcmfmac
[Wed Jan 19 01:32:16 2022] brcmfmac: F1 signature read @0x18000000=0xXXXXX
[Wed Jan 19 01:32:16 2022] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430-sdio.bin for chip 0x00a9a6(43430) rev 0x000001
[Wed Jan 19 01:32:16 2022] usbcore: registered new interface driver brcmfmac
[Wed Jan 19 01:32:16 2022] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 23 2017 03:55:53 version 7.45.98.38 (r674442 CY) FWID 01-e58d219f
[Wed Jan 19 01:32:16 2022] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 7.11.15 Compiler: 1.24.2 ClmImport: 1.24.1 Creation: 2014-05-26 10:53:55 Inc Data: 9.10.39 Inc Compiler: 1.29.4 Inc ClmImport: 1.36.3 Creation: 2017-10-23 03:47:14
[Wed Jan 19 01:32:17 2022] brcmfmac: power management disabled

Some more tools for diagnosing, below one shows interface links (including MAC addresses):

ip -br l

Below one IP's:

ip -br a

Below one the journals for the dhcpcd network manager:

journalctl -u dhcpcd

Below one shows DHCP log entries:

grep dnsmasq-dhcp /var/log/pihole.log

Above sounds like another issue.
First fix the current ones and if still experience above issue, create a new help request/topic/thread pls?

EDIT: Come to think of it, you've posted similar mistakes in dhcpcd.conf twice already.
Makes me wonder if dhcpcd is just ignoring that dhcpcd.conf file bc of errors and does what it do default without configuration, acquire an IP via DHCP for all detected interfaces including the eth0 one.
Check the dhcpcd journals!
EDIT2: With below one you can restart dhcpcd if corrected the dhcpcd.conf file:

sudo service dhcpcd restart

And check journals after!

Apologies for the delay in responding, but I needed to make sure the problems really have gone away!

More apologies for it was a typo when I wrote .

# Inform the DHCP server of our hostname for DDNS.
webserver

I had already set it to

# Inform the DHCP server of our hostname for DDNS.
hostname

and rebooted.

Further info in response to your questions.

lsb_release -a

Description:    Raspbian GNU/Linux 10 (buster)

and

cat /proc/cpuinfo

Model           : Raspberry Pi 3 Model B Plus Rev 1.3

lsmod showed no presence of brcmfmac until I re-enabled wifi - which is what I would expect. Trying both " dtoverlay=pi3-disable-wifi " and " dtoverlay=disable-wifi " both disabled wifi nicely and reverting to " dtoverlay=disable-wifi" appears to be doing fine and brcmfmac is no longer listed.

I ran the various tools and nothing really stood out, but the truly weird thing is that all the issues have seeming gone away [for now....] and I cannot account for them because the only change made, was to run pihole -up update to Update local cache of available packages. Similarly no change has been made to the router settings.

So for now Pi-hole Diagnosis is empty and there are no nags coming from the Pi, but I fear this will not benefit others stumbling across this dialogue. However, it must be said that throughout this period, Pi-hole has been doing an admirable job!

Sincere thanks for the kind assistance!

1 Like

Thanks for the feedback!
I removed your serial number in above reply for privacy.
Could you mark one of the replies as a solution pls?
Happy ad hunting!

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.