Bug 834672

Summary:

package conflict when updating atlas on x86_64

Product:

Red Hat Enterprise Linux 6

Reporter:

Fred Bacon <bacon>

Component:

releng

Assignee:

Lubos Kocman <lkocman>

Status:

CLOSED NOTABUG

QA Contact:

Release Test Team <release-test-team-automation>

Severity:

high

Docs Contact:

Priority:

unspecified

Version:

6.3

CC:

dgregor, fkluknav

Target Milestone:

Target Release:

---

Hardware:

x86_64

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2015-01-30 13:48:41 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
the original atlas placement from RHEL-6.0	none
atlas placement from RHEL-6.3	none

Description Fred Bacon 2012-06-22 18:25:13 UTC

Description of problem:

Attempting to update atlas.x86_64 from RHEL 6.2 to 6.3 causes yum to add atlas.i686 to the installation.  But the versions don't match.  The x86_64 package version is atlas-3.8.4-2.el6.x86_64, but the i686 version is atlas-3.8.4-1.el6.i686.  Yum shouldn't be trying to install atlas.i686 at all, since there are no other i686 packages installed on the system.

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

atlas-3.8.4-2.el6.x86_64
atlas-3.8.4-1.el6.i686

How reproducible:

This occurs whenever I attempt to perform an upgrade which includes atlas.

Steps to Reproduce:
1. With atlas-3.8.4-1.el6.x86_64 and atlas-devel-3.8.4-1.el6.x86_64 installed (perhaps even without!)

2. run yum update atlas.x86_64

  
Actual results:

The package is not installed.  The following output is generated.

Loaded plugins: changelog, downloadonly, presto, product-id, refresh-packagekit, rhnplugin, security, subscription-manager, versionlock
Updating certificate-based repositories.
Unable to read consumer identity
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package atlas.x86_64 0:3.8.4-1.el6 will be updated
--> Processing Dependency: atlas = 3.8.4-1.el6 for package: atlas-devel-3.8.4-1.el6.x86_64
---> Package atlas.x86_64 0:3.8.4-2.el6 will be an update
--> Running transaction check
---> Package atlas.i686 0:3.8.4-1.el6 will be installed
--> Processing Dependency: libpthread.so.0(GLIBC_2.1) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libpthread.so.0(GLIBC_2.0) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libpthread.so.0 for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libm.so.6(GLIBC_2.0) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libm.so.6 for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libgfortran.so.3(GFORTRAN_1.0) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libgfortran.so.3 for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libc.so.6(GLIBC_2.4) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libc.so.6(GLIBC_2.3.2) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libc.so.6(GLIBC_2.1.3) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libc.so.6(GLIBC_2.1) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libc.so.6(GLIBC_2.0) for package: atlas-3.8.4-1.el6.i686
--> Processing Dependency: libc.so.6 for package: atlas-3.8.4-1.el6.i686
---> Package atlas.x86_64 0:3.8.4-1.el6 will be updated
--> Running transaction check
---> Package glibc.i686 0:2.12-1.80.el6 will be installed
--> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: glibc-2.12-1.80.el6.i686
--> Processing Dependency: libfreebl3.so for package: glibc-2.12-1.80.el6.i686
---> Package libgfortran.i686 0:4.4.6-4.el6 will be installed
--> Running transaction check
---> Package nss-softokn-freebl.i686 0:3.12.9-11.el6 will be installed
--> Finished Dependency Resolution
Error: Protected multilib versions: atlas-3.8.4-1.el6.i686 != atlas-3.8.4-2.el6.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest


Expected results:

The new atlas and atlas-devel packages should be installed.


Additional info:

Comment 2 Fred Bacon 2012-06-22 18:52:32 UTC

Well, apparently, someone at Redhat decided to rename the subscription channels for the new 6.3 release.  Atlas-devel was originally in the "Supplemental" channel and is now in the "Optional" channel.  This seems to have made the update difficult to perform since yum doesn't know about the new channel.

The resolution is to update everything except atlas and atlas-devel, add "Optional" to your channel subscriptions, and then perform the update for atlas.  That seems to have worked, but why the hell are atlas and atlas-devel in different channels to begin with?

Comment 3 Peter Schiffer 2012-06-25 12:38:44 UTC

Fred,

atlas-devel package should always be in the "Optional" subscription channel. "Supplementary" channel is for software with non-standard SLAs and/or licenses.

Are you sure you just didn't disabled the "Optional" sub. channel between installing atlas-devel and updating it?

Thanks,

peter

Comment 4 Fred Bacon 2012-06-25 14:42:24 UTC

Peter,

I didn't disable the optional channel, but I'm not the only admin with access to that account.  *sigh* It's possible that someone else did it, but it seems unlikely.  

Sorry for my irritable comment.  I spent five hours trying to strip off all of the i686 packages and staring at logs until I could figure out how to diagnose the problem with the update.  That's a lot of billable hours lost.

Fred

Comment 5 Peter Schiffer 2012-06-26 10:26:53 UTC

Fred,

that's OK, I understand. However, I am not sure how we could help you now. Can you somehow determine that atlas-devel package wasn't in optional sub. channel before?

Thanks,

peter

Comment 6 RHEL Program Management 2012-09-07 05:29:10 UTC

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 7 Frantisek Kluknavsky 2014-11-07 15:44:43 UTC

Recent yum gives a nice clue:
"""
Error:  Multilib version problems found. This often means that the root
       cause is something else and multilib version checking is just
       pointing out that there is a problem. Eg.:
       
         1. You have an upgrade for atlas which is missing some
            dependency that another package requires. Yum is trying to
            solve this by installing an older version of atlas of the
            different architecture. If you exclude the bad architecture
            yum will tell you what the root cause is (which package
            requires what). You can try redoing the upgrade with
            --exclude atlas.otherarch ... this should give you an error
            message showing the root cause of the problem.
"""

As far as I can tell, atlas-devel in optional channel. Release engineering might know more.

Comment 8 Lubos Kocman 2015-01-30 13:48:41 UTC

Hello,

I have to disagree about Supplementary channels. I just reviewed 6.0 and it was originally targeted for the optional channels and it was never part of Supplementary. See attachment of filelists from 6.0 and 6.3

$ find /mnt/redhat/released/RHEL-6-Supplementary --name "atlas*.rpm -type f
[lkocman@rcm-dev RHEL-6-Supplementary]$

I'd also like to note that optional vs RHEL Base can vary based on dependencies

Example: if something in RHEL Server requires atlas-devel then it will be in RHEL Server while it still might be in Client Optional ....


Closing as notabug. Since I can't think of anything else than accidental disabling optional channel.

Feel free to reopen this incident if you have further questions.

Thanks

Lubos
rel-eng

Comment 9 Lubos Kocman 2015-01-30 13:49:39 UTC

Created attachment 985993 [details]
the original atlas placement from RHEL-6.0

Comment 10 Lubos Kocman 2015-01-30 13:50:06 UTC

Created attachment 985995 [details]
atlas placement from RHEL-6.3