Bug 442047 - no good way to pull in multilib runtime that isn't explicit dependencies
no good way to pull in multilib runtime that isn't explicit dependencies
Status: NEW
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Václav Pavlín
: FutureFeature
: 460188 508481 509357 512351 (view as bug list)
Depends On:
Blocks: 663269
  Show dependency treegraph
 
Reported: 2008-04-11 09:47 EDT by Bill Nottingham
Modified: 2016-11-05 09:22 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2008-04-11 09:47:44 EDT
Description of problem:

As a consequence of our switch to 'multilib_policy=best', we don't have a good
way to pull in any parts of the multilib runtime that aren't explicit
dependencies of 32-bit apps.

Examples would be:
- NSS modules
- PAM modules
- SASL modules
- ALSA plugins (pulseaudio)
- GTK/QT input methods

Figured this should at least be filed and noted, even if there's not an obvious
fix at the moment.

Version-Release number of selected component (if applicable):

F9 beta and later
Comment 1 Seth Vidal 2008-04-11 15:34:40 EDT
Adding Panu,
  I think we need to make it important for us to add arch-specific deps. We can
do it now but we have to do it manually.
Comment 2 Bill Nottingham 2008-04-11 15:37:50 EDT
I'm not sure how arch-specific deps help you here. It's the sort of thing where
if you have pam_krb5 installed, you need all arches, but no app is going to
require pam_krb5.
Comment 3 Seth Vidal 2008-04-11 15:44:44 EDT
Then you'll need someway of tagging these in the rpm. Either way - adding panu
is a good idea. :)
Comment 4 Bug Zapper 2008-05-14 05:18:33 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Bug Zapper 2009-06-09 20:08:30 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 WONTFIX if it remains open with a Fedora 
'version' of '9'.

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 prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 Panu Matilainen 2009-06-10 01:48:08 EDT
*** Bug 460188 has been marked as a duplicate of this bug. ***
Comment 7 Julian Sikorski 2009-06-27 12:36:09 EDT
I just got bitten by this issue: wine which is currently in updates-testing pulled nss-mdns.i386. This caused yum to fail (I'm on x86_64 system). Can get preetty serious, it seems.
Comment 8 Clive Messer 2009-06-29 07:50:22 EDT
Yes, wine-core-1.1.24-2.fc11.1.i586 pulls in nss-mdns-0.10-7.fc11.i586 as a dependency. On a x86_64 (mulitlib) install, if the x86_64 nss-mdns is not installed, name resolution fails because of the change to nsswitch.conf. "Install the nss-mdns x86_64 package" is going to become a faq.
Comment 9 Bill Nottingham 2009-06-29 10:33:07 EDT
Hm, that almost sounds like a bug in the wine package.
Comment 10 Clive Messer 2009-06-29 11:41:07 EDT
Sorry, Bill - what's the bug? The fact that wine-core has a dependency on nss-mdns, or the fact that not installing the x86_64 nss-mdns package will result in broken resolving behaviour after the script from the nss-mdns.i586 changes the nsswitch.conf to, "hosts:      files mdns4_minimal [NOTFOUND=return] dns" without the 64 bit versions of libnss_mdns*.so.* having been installed.
Comment 11 Clive Messer 2009-06-29 12:03:42 EDT
Sorry, for the noise - nss-mdns(x86-32) has been added as a 'hard' dependency to wine-core. See #492700. (And someone has raised the fact under that bug that installing nss-mdns.i586 without the x86_64 package will break name resolution on x86_64).
Comment 12 Julian Sikorski 2009-06-29 12:30:33 EDT
Yeah, it's by no means bug in wine. Wine needs nss-mdns to work correctly, so it requires it.
Comment 13 Bill Nottingham 2009-06-29 12:36:32 EDT
It's a 'bug' in that introducing the update shouldn't break the system. However, I'm not sure how to solve it.
Comment 14 Adam Goode 2009-06-29 13:00:30 EDT
One way to solve it would be to add support to glibc to do something like /etc/nsswitch.d/... instead of packages doing sed on /etc/nsswitch.conf. Then of course it would have to be per-arch.

Or, add the RPM dependency handling that allows this:

(in package nss-mdns.x86_64)
 Requires: nss-mdns.i586 if installed glibc.i586

(in package nss-mdns.i586)
 Requires: nss-mdns.x86_64 if installed glibc.x86_64

Both of these solutions are potentially messy and complicated.

Maybe the way forward is to eliminate nss modules in favor of a daemon process running that provides lookups, like what SSSD is starting to do? http://fedoraproject.org/wiki/Features/SSSD (The daemon has the plugins, not the C library.)
Comment 15 Panu Matilainen 2009-07-01 15:18:37 EDT
*** Bug 508481 has been marked as a duplicate of this bug. ***
Comment 16 Yanko Kaneti 2009-07-01 16:17:59 EDT
glibc not finding /lib64/libnss_mdns4_minimal.so.2 and treating the result as NOTFOUND instead of UNAVAIL sounds like a bug to me
Comment 17 Lennart Poettering 2009-07-22 19:30:29 EDT
*** Bug 512351 has been marked as a duplicate of this bug. ***
Comment 18 Lennart Poettering 2009-07-22 19:31:12 EDT
*** Bug 509357 has been marked as a duplicate of this bug. ***
Comment 19 seth vidal 2009-07-24 15:29:03 EDT
I think I agree with comment 16 -  glibc needs to handle the failure better.
Comment 20 Luke Hutchison 2009-07-30 19:30:34 EDT
(In reply to comment #13)
> It's a 'bug' in that introducing the update shouldn't break the system.
> However, I'm not sure how to solve it.  

Actually after the system breaks in this way, yum stops working.  This is very serious for a lot of users as they can't "unbreak" it.

I have seen this break on two systems now.  I just installed a brand new Fedora 11 x86_64 system with default "software development" package set, got all updates, the installed Chromium via the spot yum repository:
http://www.fergytech.com/2009/07/a-chromium-rpm-on-fedora-11/
After these steps (and nothing else), numerous programs in the system (yum, wget, ...) couldn't resolve hostnames.  I don't know if it was updates or installing Chromium that did it, but the point is that numerous unrelated core parts of the system broke.  On one of the systems Firefox also broke, on both Chromium also broke -- this makes it hard to find a solution to the problem too.
Comment 21 Bill Nottingham 2009-08-03 11:33:08 EDT
https://admin.fedoraproject.org/updates/glibc-2.10.1-3

may be of interest here.
Comment 22 Eddie Lania 2010-08-16 11:44:06 EDT
Question: Is this bug solved yet? I experience dns timeouts and unresolvable host on a clean Fedora 13 also. I wonder if it's related?
Comment 23 Luke Hutchison 2010-08-17 12:35:08 EDT
Eddie: Is this on wifi?  Check dmesg, there's a kernel bug in .35/.36 that causes those sorts of errors on wifi with a certain combination of wireless chipset and AP.  "service NetworkManager restart" as root may cure it for 30 seconds or so until it buckles under load again.  There's a patch going upstream for this.  I don't have either the error message or bug report reference handy unfortunately.
Comment 24 Eddie Lania 2010-08-17 13:39:31 EDT
Hello Luke,

It's not on wireless. I installed a fresh Fedora 13 here on a pc with a wired lan connection to serve my lan dns, dhcp and other intranet services. It is a replacement for an older Fedora Core 4 server. That older server never caused me any problems with dns resolving hosts on the internet but it seems that now the newer Bind version has come in place of the old one I have problems all the time.

It could be my Zyxel P-2602R-D1A modem/router's firewall that is the culprit but that is what I am trying to find out.

Hence my question.

I hope this is explanation makes it a bit more clear?

Regards,

Eddie.
Comment 25 Eddie Lania 2010-08-17 13:46:48 EDT
Oh, and BTW, I don't use the NetworkManager on that new server. I disabled NetworkManager and configured eth0 with static addresses and use service "network" to enable networking at boot time.
Comment 26 Luke Hutchison 2010-08-17 14:02:39 EDT
I guess the first thing to do is try plugging directly into the Internet, bypassing the router.

This bug is on a completely different topic though, you should file a separate bug report if you are still having problems.
Comment 27 Stephen Gallagher 2011-01-25 07:38:51 EST
I'd like to chime in here and mention that this bug is becoming much more highly-visible as people begin to use SSSD instead of nscd for caching identity lookups.

A classic example is bug 663269, where acroread fails on x86_64 systems with SSSD unless sssd-client.i686 is installed.

nsswitch modules (and PAM modules) really need to be able to specify "SSSD requires sssd-client.x86_64. It also requires sssd-client.i686 if glibc.i686 is installed"
Comment 28 Fujisan 2011-07-13 03:35:05 EDT
I recently upgraded some (not all) desktops from F14 to F15 and I did several updates of F15.
On the F14 desktops, I cannot use wget without getting the error message "failed: Name or service not known."
(but yum is working fine), while on the F15 desktops, that problem seems to have been solved. 

on F14:

$ wget http://download.fedoraproject.org/pub/fedora/linux/releases/15/Live/i686/Fedora-15-i686-Live-Desktop.iso
--2011-07-13 09:27:07--  http://download.fedoraproject.org/pub/fedora/linux/releases/15/Live/i686/Fedora-15-i686-Live-Desktop.iso
Resolving download.fedoraproject.org... failed: Name or service not known.
wget: unable to resolve host address “download.fedoraproject.org”

$ cvlc http://vipicecast.yacast.net/europe1
VLC media player 1.1.10 The Luggage (revision exported)
Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS")
Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE")
[0xca2c50] dummy interface: using the dummy interface module...
[0x7f0ad80014c0] main access error: cannot resolve vipicecast.yacast.net port 80 : Name or service not known
[0x7f0ad80014c0] access_http access error: cannot connect to vipicecast.yacast.net:80
[0x7f0ad80014c0] main access error: cannot resolve vipicecast.yacast.net port 80 : Name or service not known
[0x7f0ad80014c0] access_mms access error: cannot connect to vipicecast.yacast.net:80
[0x7f0ae0000c90] main input error: open of `http://vipicecast.yacast.net/europe1' failed: (null)
[0x7f0ae0000c90] main input error: Your input can't be opened
[0x7f0ae0000c90] main input error: VLC is unable to open the MRL 'http://vipicecast.yacast.net/europe1'. Check the log for details.
^C[0xc76d60] signals interface error: Caught Interrupt signal, exiting...



on F15:


[09:28][beauduin@rigoletto ~]$ wget http://download.fedoraproject.org/pub/fedora/linux/releases/15/Live/i686/Fedora-15-i686-Live-Desktop.iso
--2011-07-13 09:28:52--  http://download.fedoraproject.org/pub/fedora/linux/releases/15/Live/i686/Fedora-15-i686-Live-Desktop.iso
Resolving download.fedoraproject.org... 80.239.156.215, 85.236.55.6, 209.132.181.16, ...
Connecting to download.fedoraproject.org|80.239.156.215|:80... connected.
HTTP request sent, awaiting response... 302 FOUND
Location: http://mirrors.ircam.fr/pub/fedora/linux/releases/15/Live/i686/Fedora-15-i686-Live-Desktop.iso [following]
--2011-07-13 09:28:57--  http://mirrors.ircam.fr/pub/fedora/linux/releases/15/Live/i686/Fedora-15-i686-Live-Desktop.iso
Resolving mirrors.ircam.fr... 129.102.1.37, 2001:660:3004:4003::37:80
Connecting to mirrors.ircam.fr|129.102.1.37|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 592445440 (565M) [application/octet-stream]
Saving to: “Fedora-15-i686-Live-Desktop.iso”

 0% [                                                            ] 4,404,523   1.70M/s              ^C

$ cvlc http://vipicecast.yacast.net/europe1
VLC media player 1.1.10 The Luggage (revision exported)
Blocked: call to unsetenv("DBUS_ACTIVATION_ADDRESS")
Blocked: call to unsetenv("DBUS_ACTIVATION_BUS_TYPE")
[0x8fd1e0] dummy interface: using the dummy interface module...
[0x7f56300014c0] access_http access: Raw-audio server found, mp3 demuxer selected
[0x7f562c000ac0] pulse audio output error: cannot connect to server: Connection refused
ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: Connection refused
[0x7f562c000ac0] oss audio output error: cannot open audio device (/dev/dsp)
ALSA lib pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: Connection refused
[0x8d8550] signals interface error: Caught Interrupt signal, exiting...
Comment 29 Adam Goode 2011-08-12 10:36:00 EDT
Is this now solved with F15?
Comment 30 Bill Nottingham 2011-08-15 15:27:23 EDT
Not sure comment #28 is really related. The original issue hasn't undergone any change.
Comment 31 Steve 2011-11-04 17:05:07 EDT
(In reply to comment #29)
> Is this now solved with F15?

No. A friend of mine had this problem with fedora 15, one day ago. He installed Ubuntu now and the problem is gone.
Comment 32 Ales Kozumplik 2012-09-12 10:57:30 EDT
This bug has been discussed on packaging tools team IRC meeting today. The outcome of the discussion:

Since NSS/sssd is not a dependency of the glibc(32) library, it should never rely on it existing on the system, configuration options created by any other package (sssd(64) in this case) notwithstanding. It was suggested glibc checks for the presence of NSS and in case it is missing it fallbacks on whatever it would do without NSS.

It was also mentioned this is the case in more recent glibc and suggested this bug is closed in that case.
Comment 33 Stephen Gallagher 2012-09-13 03:53:20 EDT
I'm having difficulty parsing this response. First of all, NSS (name-service switch) is *part* of glibc. It is included in the 'glibc' package and is a necessary component of any Linux system (it's how the system looks up usernames, DNS entries and a host of other things).

The core of the problem is that NSS runs in-process by necessity. All C applications are linked against glibc directly and therefore run NSS modules (automatically loaded when needed) from the user process. It's not a system daemon of any kind. This means that in order for a user to look up an entry while running a 64-bit application, there must be a 64-bit plugin available for NSS. On multilib platforms (e,g. i686 runtime on x86_64 kernel), NSS also must have a 32-bit plugin available for glibc so that 32-bit applications can access name-service data.

This is a problem for ALL name-service providers, including SSSD, winbind and nss-pam-ldapd. If the corresponding 32-bit version of a plugin is not installed, 32-bit applications (such as any third-party apps with no 64-bit available) will not be able to access name-service data and will generally either fail or behave erratically.

This problem is NOT limited to NSS either. The same issue occurs with PAM, if an i686 application's PAM stack relies on e.g. pam_winbind.so but only the samba-winbind-clients.x86_64 package is installed, authentication will fail.

We do not want to force SSSD and winbind to have an explicit requires on both the 32-bit and 64-bit client libraries, because that would force the presence of the 32-bit runtime on any system wishing to perform centralized user management. This is far too heavy-handed and is why we would prefer an RPM/yum solution to ensure that the appropriate NSS and PAM plugins are pulled in for systems with both runtimes available.
Comment 34 Ales Kozumplik 2012-09-13 06:47:48 EDT
First of all sorry the issue was presented in a simplified version on the meeting. I see now it's more complex than blaming misconfiguration.

(In reply to comment #33)
> This problem is NOT limited to NSS either. The same issue occurs with PAM,
> if an i686 application's PAM stack relies on e.g. pam_winbind.so but only
> the samba-winbind-clients.x86_64 package is installed, authentication will
> fail.
> 

I agree this is a valid issue, e.g. admin knows what package needs to be installed on the particular machine, installs them and then finds some 32 bit apps can not be authenticated.

Before we discuss this on a future meeting again, a quick idea: wouldn't it be enough if every 64-bit client library depended on the 32-bit counterpart? Maybe we could introduce some per-package 'multilib-policy: all'.
Comment 35 Stephen Gallagher 2012-09-13 08:17:22 EDT
(In reply to comment #34)
> First of all sorry the issue was presented in a simplified version on the
> meeting. I see now it's more complex than blaming misconfiguration.
> 
> (In reply to comment #33)
> > This problem is NOT limited to NSS either. The same issue occurs with PAM,
> > if an i686 application's PAM stack relies on e.g. pam_winbind.so but only
> > the samba-winbind-clients.x86_64 package is installed, authentication will
> > fail.
> > 
> 
> I agree this is a valid issue, e.g. admin knows what package needs to be
> installed on the particular machine, installs them and then finds some 32
> bit apps can not be authenticated.
> 
> Before we discuss this on a future meeting again, a quick idea: wouldn't it
> be enough if every 64-bit client library depended on the 32-bit counterpart?
> Maybe we could introduce some per-package 'multilib-policy: all'.

"We do not want to force SSSD and winbind to have an explicit requires on both the 32-bit and 64-bit client libraries, because that would force the presence of the 32-bit runtime on any system wishing to perform centralized user management."

This solution isn't acceptable because it forces a minimum of 14MB of additional data (the installed size of the glibc.i686 package) onto the x86_64 minimal install (including LiveCDs).

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