Bug 508481 - mdns4_minimal [NOTFOUND=return] nsswitch.conf fragment breaks nostname resolution
mdns4_minimal [NOTFOUND=return] nsswitch.conf fragment breaks nostname resol...
Status: CLOSED DUPLICATE of bug 442047
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
: 504951 509530 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-06-27 14:22 EDT by Yanko Kaneti
Modified: 2009-07-22 19:08 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-01 15:18:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch for spec accompanying in nss-mdns-0.10-7.fc11.src.rpm (325 bytes, text/plain)
2009-06-29 18:51 EDT, Björn Sund
no flags Details

  None (edit)
Description Yanko Kaneti 2009-06-27 14:22:46 EDT
Description of problem:
nss-mdns.i[35]86 installed on a x86_64 system without installed nss-mdns.x86_64 breaks x86_64 glibc's name resolution.

Specifically the lookup process modification of [NOTFOUND=return]
Without it even if glibc fails to find mdns4_minimal it still continues on the lookup in dns.
Comment 1 Björn Sund 2009-06-28 11:14:05 EDT
Got bit by this one when installing wine from updates-testing in F11 on a x86_64 system.
Comment 2 Lennart Poettering 2009-06-29 14:43:50 EDT
One of the many reasons why multilib is broken. 

I don't see how this could be fixed.
Comment 3 Yanko Kaneti 2009-06-29 14:55:08 EDT
Just remove the [NOTFOUND=return] part? Why is it needed?
Comment 4 Björn Sund 2009-06-29 16:02:17 EDT
Yes something needs to be done since it break loads of dns lookups on the system just by doing a simple thing like installing wine on a multilib system. 

I got round it by pinging hosts for resolve and then copy/paste my way to bugzilla. :)

Maybe more of a Fedora bug than a mdns one, but it is nasty.
Comment 5 Björn Sund 2009-06-29 17:11:29 EDT
Hmm, I tried to reproduce with no success.

Works fine now, so I blame those solar storms

[bsund@woot ~]$ rpm -qa|grep mdns
[bsund@woot ~]$ grep mdns /etc/nsswitch.conf
hosts:      files mdns4_minimal [NOTFOUND=return] dns
Comment 6 Björn Sund 2009-06-29 18:51:21 EDT
Created attachment 349888 [details]
patch for spec accompanying in nss-mdns-0.10-7.fc11.src.rpm

Nope it's still here, it differs from applications.

Attaching a simple patch stripping the return from the .spec, I don't know my regex but it seems to do it's job ;)

No idea if it hurts mdns in any way though.
Comment 7 Parag Nemade 2009-06-30 07:30:05 EDT
Aah. So this is that package which made my rawhide machine broken since 3 days.
Please fix this as soon as possible its just one line change. I applied change given in comment#5 and  I got networking working again.
Comment 8 Parag Nemade 2009-06-30 07:31:30 EDT
I don't understand about this package. I see that
Build Date: Thu 26 Feb 2009 03:14:03 PM IST
but it got installed on my machine on 26 June 2009.
Comment 9 Lennart Poettering 2009-07-01 12:37:42 EDT
(In reply to comment #3)
> Just remove the [NOTFOUND=return] part? Why is it needed?  

Because nss-mdns needs to be authoritative for for the .local domain.

That posted patch is not useful, since it breaks this.

This problem is not fixable with RPM as it stands right now. What would be necessary is that the 64bit version of nss-mdns pulls in the 32bit version if other 32bit binaries are installed, and vice versa. But you cannot express that with RPM dependencies.

So I fear this will stay unfixed and you have to manually make sure you have installed both versions of nss-mdns,

I will now reassign this to rpm, because this needs to be fixed in RPM.
Comment 10 Panu Matilainen 2009-07-01 15:18:37 EDT

*** This bug has been marked as a duplicate of bug 442047 ***
Comment 11 Matěj Cepl 2009-07-03 16:48:04 EDT
*** Bug 509530 has been marked as a duplicate of this bug. ***
Comment 12 Lennart Poettering 2009-07-22 19:08:15 EDT
*** Bug 504951 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.