yum problem with glibc

Home » CentOS » yum problem with glibc
CentOS 12 Comments

On 05/22/2012 05:05 AM, Timothy Murphy wrote:
> Is anyone getting a yum update problem with glibc and glibc-common?
> I’m getting the error message
> ——————————-
> Error: Protected multilib versions: glibc-2.12-1.47.el6_2.12.x86_64 !=
> glibc-2.12-1.47.el6_2.9.i686
> ** Found 3 pre-existing rpmdb problem(s), ‘yum check’ output follows:
> bash-4.1.2-9.el6_2.x86_64 is a duplicate with bash-4.1.2-8.el6.centos.x86_64
> glibc-common-2.12-1.47.el6_2.12.x86_64 is a duplicate with glibc-
> common-2.12-1.47.el6_2.9.x86_64
> glibc-common-2.12-1.47.el6_2.12.x86_64 has missing requires of glibc = (‘0’,
> ‘2.12’, ‘1.47.el6_2.12’)
> ——————————-
> I’ve tried “rpm –rebuilddb” but that did not seem to help.
>
> Any suggestions or advice gratefully received.
>

You have both the i686 and x86_64 versions of glibc installed. That
error means that the repo you are trying to update from has a different
version of i686 glibc and x86_64 glibc … or you are trying to upgrade
one (the x86_64 version) and not the other (the i686 version).

Since multilib installs share some files (all the Documentation, etc.),
that means you must install the same version of each arch if you install
both i686 and x86_64 packages.

12 thoughts on - yum problem with glibc

  • Johnny Hughes wrote:

    Thank you very much for your response.

    But I’m afraid I’m not clear what action I can take.
    I don’t like to remove any glibc or glibc-common packages,
    as I’m afraid it might have a disastrous effect,
    since they seem to be required by so many other packages,
    including the kernel.

    I’m slightly puzzled how the system got in this position,
    as I have never said anything except “yum upgrade”,
    and the repos I have enabled all seem harmless,
    though there are several of them:
    [adobe-linux-x86_64, CentOS-CR (cr), epel, kbs-CentOS-Extras, rpmforge.

    The system (which is in another country) seems to be running fine.
    If I leave it will it sort itself out in time?

  • Based on your errors, what I would do is this:

    1. You only need 1 version of glibc-common.x86_64. The only way you
    could have gotten into this position is either your machine died in the
    middle of a yum update or someone force installed the later glibc-common
    via the rpm -i command.

    I would first try to install the yum-utils package with this command:

    yum install yum-utils

    once that is installed, I would try:

    yum-complete-transaction

    If you do not have any incomplete transactions, then you have some bad
    packages force installed.

    I would figure out exactly what packages I had installed for glibc and
    get them all on one version … you need to be careful with glibc (and
    its sub packages) … it is the most important package on your machine.

    How I would do this is that I would download all the RPMs for the latest
    version of all the packages you have installed … for me that would be:

    glibc-devel-2.12-1.47.el6_2.12.x86_64.rpm
    glibc-headers-2.12-1.47.el6_2.12.x86_64.rpm
    glibc-2.12-1.47.el6_2.12.i686.rpm
    glibc-common-2.12-1.47.el6_2.12.x86_64.rpm
    glibc-2.12-1.47.el6_2.12.x86_64.rpm
    nscd-2.12-1.47.el6_2.12.x86_64.rpm

    You may have others.

    Once I had them all in the same directory, I would try a:

    rpm -Uvh *.rpm

    then I would look at the errors

    based on those errors (if it does not install) then I would likely do:

    rpm -Uvh –force *.rpm

    that will LIKELY clean up your rpm issues for glibc … but if you don’t
    understand the errors, post those here.

    2. For bash, I would:

    rpm -e bash-4.1.2-8.el6.centos.x86_64

    then I would reinstall the other bash

    yum reinstall bash-4.1.2-9.el6_2.x86_64

    3. The real issue here is to make sure you figure out HOW you got in
    this position and how NOT to get into it again.

  • Johnny Hughes wrote:

    First, thanks very much for continuing to help me.

    I do have this package installed.

    When I run this, an enormous list of packages (I think over 300)
    that will be deleted appears, eg
    ——————————-

  • Tim,

    Timothy Murphy wrote:

    I think you have bigger problems. I don’t think that out of yum
    is the problem.

    One dumb question: what’s the output of uname -a – *are* you running a
    64-bit kernel?

    Have you tried yum clean all?

    mark

  • m.roth@5-cent.us wrote:

    Thanks for your response.

    [tim@alfred glibc]$ uname -a
    Linux alfred.gayleard.eu 2.6.32-220.17.1.el6.x86_64 #1 SMP Wed May 16
    00:01:37 BST 2012 x86_64 x86_64 x86_64 GNU/Linux

    I have.
    More than once.

  • Johnny Hughes wrote:

    Thanking you again for all your help.
    I have one last question, and then I promise to ask no more!
    Could the rpm –force suggestion you make possibly stop the server working?

    I’ve downloaded all these to /tmp/glibc/

    I get the same error as before:
    —————————

  • No you can NOT and don’t ever assume that. That’s a mistake thinking
    that.

    Wait and schedule a downtime window for it. That’s the heart and soul
    of linux. That’s playing in the devils den if it’s a production
    machine.

    It’s the same in one as the NSS libs on the machine. They break then
    you will have to install things by hand. RPM and Yum will not work
    period.

    If the machine in question has like a Fencing Device (like a drac card )
    with an IP addy that’s public then maybe (that is card dependent).

    John

  • John Stanley wrote:

    The command in question was: rpm -Uvh –force *.rpm
    where the RPMs were glibc and glibc-common.

    Aren’t you exaggerating a little?
    There are a lot of commands I would feel perfectly safe giving remotely,
    eg “sudo yum update” which I’ve said a couple of times a week
    for the last 3 years without any disasters resulting.

    The trouble with the command above is that I am not sure
    if a change in glibc would affect a running kernel?
    I suspect that it would not.

    I don’t know what a “downtime window” is in this context.
    I’m either in the same place as the server, or I am not.

    I’m not really in that kind of environment.
    It isn’t the end of the world if the machine goes down;
    just a little annoying.

  • No I’m not. Just being honest. You break glibc and then if you exit
    the SSH session PAM want let you back in.

    Trust me it will bite you eventually. Nothing is fool proof. But yes
    there is a lot of commands I would feel safe running also but not in
    your situation. I’m just giving you experienced advice.

    Downtime Window: It’s when you schedule a specific time to update the
    machine or make repairs to that it needs. It’s also for time when the
    machine is halfway around the world and your not sure what will happen
    when you perform a command ie; you would have a hands on person
    available there also.

    If it’s not a needed production machine then do it but you say it’s
    annoying if it happens and you seem worried (previous mails) so that is
    why I gave the stern reply to not assume anything. One thing i’m not
    going to tell someone in your situation is go ahead and do it. You
    asked a valid question and I gave a valid response to you.

    I really don’t think any one on this list would say go and do it. You
    have good info to go on and what can happen.

    John

  • John Stanley wrote:

    I wasn’t assuming anything.
    I was asking for an estimate of the probability that the command will fail.
    In every such situation there is a certain probability p of success,
    and a probability 1-p of failure.

    Johnny Hughes suggested the command, so on that basis alone
    I would give it a high probability of success.

    As I said, that doesn’t make sense in my context.

    Actually, my question was: what is the probability of failure?
    If someone tells me a horse has a 90% chance of winning,
    and I back it and it falls down, I don’t blame my tipster.

    Well, all you have said is that from your experience
    (which you have not specified) you would not recommend my doing this.

    That’s not quite fair.
    You also said that if glibc “breaks” PAM will fail and so SSH will fail.
    That is certainly a possibility I had not considered.

  • The better equivalent is to have the service running on multiple
    machines in the first place so no one will notice if one breaks for
    any reason.

    I’ve had yum sessions fail (probably mostly from starting them in a
    freenx session…) but never to the point where
    yum-complete-transaction did not fix it, so I don’t have a good
    feeling for what is actually happening. However, I wouldn’t expect a
    forced install of any reasonably close glibc version to break
    anything.

    I’d say those are actually more likely than breaking the kernel, but
    what is your plan if the drives or motherboard fails? Worst case
    software wise won’t be any worse than that.

  • Les Mikesell wrote:

    You’re tempting me!
    Actually, it would be silly of me to try,
    as the server is running fine at the moment,
    sending back pictures and watering the garden.

    That would only be slightly worse,
    as I do have a spare machine in the other place.
    But it’s years since I had a motherboard go sick.
    Does that happen less than it used to?

    I do have Fedora-16 and Windows XP on the machine,
    and was thinking of a complicated system to re-boot into Fedora
    if CentOS failed.

LEAVE A COMMENT