Bug 448772 - circular obsoletes in RHEL Desktop Workstation v. 5 channel
Summary: circular obsoletes in RHEL Desktop Workstation v. 5 channel
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openib
Version: 5.2
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Doug Ledford
QA Contact:
: 448826 (view as bug list)
Depends On:
Blocks: 451638 523135
TreeView+ depends on / blocked
Reported: 2008-05-28 18:24 UTC by Philippe Brieu
Modified: 2018-10-20 02:46 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 523135 (view as bug list)
Last Closed: 2009-01-20 21:41:17 UTC
Target Upstream Version:

Attachments (Terms of Use)
output from first pass of 'yum update' (3.06 KB, text/plain)
2008-05-29 17:12 UTC, Philippe Brieu
no flags Details
output from second pass of 'yum update' (2.98 KB, text/plain)
2008-05-29 17:12 UTC, Philippe Brieu
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0170 0 normal SHIPPED_LIVE openib bug fix update 2009-01-20 16:05:30 UTC

Description Philippe Brieu 2008-05-28 18:24:22 UTC
Description of problem: The packages openib-mstflint and mstflint obsolete each
other; as do openib-perftest and perftest, and openib-tvflash and tvflash.  This
causes 'yum update' to cycle between both sets at each iteration.  (It also
causes Anaconda to crash during dependency processing, making it impossible to
install RHEL 5 Client, but that may be specific to my local setup.)

Version-Release number of selected component (if applicable):  This started with
the release of 5.2 a week ago.

How reproducible: Happened automatically for several days on several i386/x86_64
systems where all packages had been installed prior to the 5.2 release.

Steps to Reproduce:
1. Install RHEL 5.1 Client with all the packages from the Desktop Workstation
2. Run 'yum update'.
3. Immediately run 'yum update' again.
Actual results: One time the packages openib-mstflint, openib-perftest, and
openib-tvflash will be installed; the next time, they will be replaced with
mstflint, perftest, and tvflash; the following time, it's back to the first
sequence; and so on.

Expected results: The new packages (mstflint, perftest, tvflash) should replace
the old ones (openib-mstflint, openib-perftest, openib-tvflash) (or vice-versa)

Additional info: This should be easy to fix by not making both sets of package
obsolete each other.  Or it could be just because the RHN proxy is still
carrying both sets.

Comment 1 Alexander Todorov 2008-05-29 08:28:40 UTC
can you clarify something please.

2. Run 'yum update' - Does this work fine ? Exit code is 0, right?
3. Immediately run 'yum update' again - here you expect to see that all packages
are already up-to-date, right? Instead you see yum trying to install tvflash,
perftest and mstflint which fails, right?

If the latter is the case I've seen this in our testing environment of RHN but
with RHEL4. The problem was that up2date thinks it has to install the packages
rather show no packages available for upgrade. In my case the packages that were
in the way were not necessary and we simply removed them from the RHN channels.

Can you give full package names + NVR and if possible which release they come from?


Comment 4 Doug Ledford 2008-05-29 15:28:18 UTC
*** Bug 448826 has been marked as a duplicate of this bug. ***

Comment 5 Philippe Brieu 2008-05-29 17:11:38 UTC
2. Yes, if you run 'yum update', it exits normally whether you choose to install
the packages or not (in both iterations).

3. Right, without this problem, once 'yum update' has been run, running it again
immediately should show no new packages.  If you tell it to install either set
of those 3 packages, it succeeds.

This is basically the same thing as
https://bugzilla.redhat.com/show_bug.cgi?id=447707 (where they told me to open a
new case for RHEL 5).

I'm not sure how we would remove the packages from our RHN proxy server, but we
have a case open with Red Hat Global Support Services for that (#1830760).

Maybe the output of 'yum update' run twice in a row will illustrate this better
with full package and channel information, so I'm attaching yum1.txt and
yum2.txt next.  Each run then alternates between case 1 and case 2 endlessy.

Comment 6 Philippe Brieu 2008-05-29 17:12:12 UTC
Created attachment 307112 [details]
output from first pass of 'yum update'

Comment 7 Philippe Brieu 2008-05-29 17:12:39 UTC
Created attachment 307113 [details]
output from second pass of 'yum update'

Comment 8 James Ralston 2008-06-04 16:16:49 UTC
It's not just the workstation channel that's affected; this affects the server
channel as well.

Any progress on this?

Comment 9 James Ralston 2008-06-04 16:38:17 UTC
Even more irritating, it would appear that you can't use yum-versionlock to work
around this problem; see bug 449989.

Comment 10 Doug Ledford 2008-06-05 18:57:46 UTC
I've filed a ticket with release-engineering and we should be able to get this
resolved soon.

Comment 11 RHEL Program Management 2008-06-05 19:14:31 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 20 Philippe Brieu 2008-07-08 23:33:02 UTC
I was wondering if we could get an update from the group working on this, as
it's been over a month now...  Thanks.

Comment 21 Philippe Brieu 2008-07-08 23:33:15 UTC
I was wondering if we could get an update from the group working on this, as
it's been over a month now...  Thanks.

Comment 22 Doug Ledford 2008-07-08 23:38:21 UTC
Bug #451638 was cloned from this bug and is the bug being used to track the
rhel5.2 z-stream fix.  In other words, this bug merely represents that I've
checked in the changes so that when rhel5.3 comes out it will be resolved there,
the other bug is the one being used to track an async errata that we are going
to push out to resolve the issue in regards to the rhel5.2 repos.  That bug is
in ON_QA status and undergoing qa testing right now.

Comment 41 errata-xmlrpc 2009-01-20 21:41:17 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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