2

I upgraded a few machines to Debian Buster and everything went well so far—although when running apt upgrade before apt full-upgrade I ran into a Temporary failure in name resolution. This was fixable and only an issue during the process and did not occur when doing a one-step apt dist-upgrade. However one machine shows this behaviour in spite of being fully upgraded. I get

~# LANG=C ping google.com
ping: google.com: Temporary failure in name resolution

When I add google.com to /etc/hosts everything is fine. My /etc/nsswitch looks like

~# cat /etc/nsswitch.conf 

passwd:         files systemd
group:          files systemd
shadow:         files
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

My /etc/resolv.conf points to googles nameserver at the moment and the very server is pingable

~# cat /etc/resolv.conf 

nameserver 8.8.8.8

~# ping -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=22.8 ms

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 22.800/22.800/22.800/0.000 ms

systemd-resolved is inactive and should not be an issue if I am interpreting the content of my /etc/nsswitch correctly.

Could there be another point I missed?

3

Installing nslookup pointed me to the source of the problem: resolv.conf was simply not parseable. I copied the contents from the original file into a new one and everything works. Same content, same permissions. But diff shows a difference where is none. Apparently there is some invisible character breaking the file since it is 1 Byte larger

/etc# diff resolv.conf.odd resolv.conf.dem
1c1
< nameserver 8.8.8.8
---
> nameserver 8.8.8.8
/etc# cat resolv.conf.odd && cat resolv.conf.dem
nameserver 8.8.8.8
nameserver 8.8.8.8
/etc# ls -l resolv.conf.*|cut -d' ' -f5,9
19 resolv.conf.dem
20 resolv.conf.odd

Update: As cas thankfully pointed out it was a trailing \r causing the mayhem and had nothing to do with the Buster Update itself. A coworker had pushed the file with wrong line wrappings

$ hd resolv.conf.odd
00000000  6e 61 6d 65 73 65 72 76  65 72 20 38 2e 38 2e 38  |nameserver 8.8.8|
00000010  2e 38 0d 0a                                       |.8..|
3
  • if you're still curious now that you've fixed it, you can find out what the problematic byte is with cat -V or a hexdumper like hd or xxd. My guess is it's probably a carriage-return character (0x0d or \r).
    – cas
    Aug 23 '19 at 23:48
  • thank you, cas—It was indeed the carriage return.
    – karlsebal
    Aug 27 '19 at 7:24
  • thank you, just if someone is looking for a quick fix: a=$(printf "nameserver 8.8.8.8\r"); echo $a >/etc/resolv.conf Dec 3 '21 at 10:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.