Description of problem: After upgrade from Fedora 25 to 26 .local domains are not being resolving any more. Problem solved by changing one line in /etc/nsswitch.conf - hosts: files dns + hosts: files mdns4_minimal [NOTFOUND=return] dns Version-Release number of selected component (if applicable): avahi 0.6.32-7.fc26 glibc 2.25-7.fc26 How reproducible: Every time. Steps to Reproduce: 1. ping somehost.local Actual results: host not found Expected results: host resolved Additional info: I am using network manager with dnsmasq extension.
Additional info: On my system "dnf reinstall nss-mdns" made the necessary change to /etc/nsswitch.conf.
Can this be closed?
(In reply to Adam Goode from comment #2) > Can this be closed? I can not check how it works in current version because I have no Fedora on my computers right now.
I have a strong recollection that comment #1 is correct. Feel free to re-open if problems persist.
Affects me in Fedora 28, reinstalling nss-mdns fixed it.
I just ran into this problem on a fresh F28 installation. → cat /etc/nsswitch.conf [...] hosts: files dns myhostname [...] → dnf info nss-mdns Installed Packages Name : nss-mdns Version : 0.14.1 Release : 1.fc28 Arch : x86_64 Size : 136 k Source : nss-mdns-0.14.1-1.fc28.src.rpm Repo : @System From repo : anaconda [...] → sudo dnf reinstall nss-mdns Fixed the issue, so I would say the problem indeed still persists.
If re-installing nss-mdns , it's likely only because of it's scriptlets: %post /sbin/ldconfig # sed-fu to add mdns4_minimal to the hosts line of /etc/nsswitch.conf if [ -f /etc/nsswitch.conf ] ; then sed -i.bak ' /^hosts:/ !b /\<mdns\(4\|6\)\?\(_minimal\)\?\>/ b s/\([[:blank:]]\+\)dns\>/\1mdns4_minimal [NOTFOUND=return] dns/g ' /etc/nsswitch.conf fi which is essentially what linked bug #1577243 is about
The post is probably missing a requires on glibc already being installed. If you still have the install logs (usually in /root) you should see that nss-mdns gets installed before glibc.
This appears to have broken printing on a Fedora 27 -> 28 -> 29 dnf system upgrade. Cups was no longer able to find printers via mdns. Adding "hosts: ... mdns [NOTFOUND=return] ..." to /etc/nsswitch.conf fixed it.
For reference, the cupsd error was: Unable to connect to XXX.local:631: Name or service not known
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
The same issue happened to me during Fedora 30 - 31 upgrade. Editing nsswitch.conf fixed printing for me.
The F31 -> F32 upgrade problems are tracked in bug #1811935.
Hopefully bug #1811935 also covers your F30 -> F31 problems, but if not, please open a new bug. Thanks!
I'm not sure this is the cause, but after a recent upgrade from updates-testing, mDNS hostname resolving and zero conf service discovery broke almost completely. I could a week ago see all the computers in the local network, now only localhost and only sometimes a subset of the service exported by a raspberry pi, but not a single host name is resolvable anymore.
The upgrade may have changed your /etc/nsswitch.conf. You might want to verify that it is as expected. For reference, I have this line: hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
(In reply to Adam Goode from comment #17) > The upgrade may have changed your /etc/nsswitch.conf. You might want to > verify that it is as expected. > > For reference, I have this line: > > hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname My nsswitch.conf correctly includes the line: hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname Note that avahi-browse -a doesn't list anything other than what's on the local machine either, so it's not necessarily nss-mdns related, only that it was one of the packages that got upgraded in the transaction that broke things.
I'm having the same problem, I've scoured the internet for a solution and nothing yet. I've tried everything. I have been having this problem since at least as far back as FC27 (I have had to resort to using a script that dynamically creates an iptables rule so cups can print). Here are the lines I have tried in nsswitch.conf: hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname #hosts: files dns mdns4_minimal myhostname #hosts: files mdns4 [NOTFOUND=return] dns myhostname #hosts: files mdns4_minimal mdns4 mdns dns myhostname #hosts: files mdns4 dns myhostname #hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname #hosts: files mdns4_minimal mdns4 dns myhostname #hosts: files mdns4_minimal dns myhostname #hosts: files dns myhostname I tested each by running a script that does: ( set -x avahi-resolve -n $DOMAIN getent hosts $DOMAIN getent --service=mdns4 hosts $DOMAIN getent --service=mdns4_minimal hosts $DOMAIN host -t SOA $DOMAIN nslookup $DOMAIN ) and the results are: --------- ++ avahi-resolve -n MYPRINTERNODE.local MYPRINTERNODE.local 192.168.0.105 ++ getent hosts MYPRINTERNODE.local ++ getent --service=mdns4 hosts MYPRINTERNODE.local ++ getent --service=mdns4_minimal hosts MYPRINTERNODE.local ++ host -t SOA MYPRINTERNODE.local Host MYPRINTERNODE.local not found: 3(NXDOMAIN) ++ nslookup MYPRINTERNODE.local Server: 192.168.0.1 Address: 192.168.0.1#53 ** server can't find MYPRINTERNODE.local: NXDOMAIN --------- As you can see, avahi finds and resolves my printer correctly, but `getent hosts` (and therefore ping, cups, and everything else that relies on it do not work). I also created an "mdns.allow" file with lines for ".local" and ".local." as per instructions elsewhere, and that didn't fix it either. I'm currently running FC31 x86_64. And due to a wine dependency, I have some 32bit libraries (and the nss-mdns-0.14.1-9.fc31.i686 package) installed that I read somewhere might potentially be causing the issue, but no clue how to fix that on my end. An strace of getent shows it is using the 64bit libraries, first it tries /lib64/libnss_mdns4_minimal.so.2 then /lib64/libresolv.so.2 Ugh, actually, while typing that up, I noticed that strace was printing this line: connect(3, {sa_family=AF_UNIX, sun_path="/var/run/avahi-daemon/socket"}, 110) = -1 ENOENT (No such file or directory) and sure enough, /var/run/avahi-daemon/socket doesn't exist, but /run/avahi-daemon/socket does.. as specified in /usr/lib/systemd/system/avahi-daemon.socket at ListenStream= I ran ln -s /run/avahi-daemon /var/run/avahi-daemon and now it immediately works. Great. strings /lib64/libnss_* /lib/libnss_mdns*|grep avahi shows that /var/run/avahi-daemon is hard-coded in all the .so files. I guess that's the bug that should be filed?
/var/run should be a symlink to ../run, and that should work. Do you have that symlink?
(In reply to Adam Goode from comment #20) > /var/run should be a symlink to ../run, and that should work. > > Do you have that symlink? I do not. I have been upgrading fedora since my Red Hat 9 installation (which itself might have been an upgrade from 7.3 -- yes, lots of fun stories, including how I "upgraded" from 32bit to 64bit), so there was at some point a move from /var/run to /run.. but I guess I didn't end up with that symlink. I'll look into fixing that missing symlink next time I plan on restarting my system. For now, I filed the bug 1959209 to let the devs know about how it affects avahi.
I just updated nss-mdns to support a socket directly in /run but it won't work yet in fedora because of bug 1937406.