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.
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?
*** Bug 448826 has been marked as a duplicate of this bug. ***
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.
Created attachment 307112 [details]
output from first pass of 'yum update'
Created attachment 307113 [details]
output from second pass of 'yum update'
It's not just the workstation channel that's affected; this affects the server
channel as well.
Any progress on this?
Even more irritating, it would appear that you can't use yum-versionlock to work
around this problem; see bug 449989.
I've filed a ticket with release-engineering and we should be able to get this
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
I was wondering if we could get an update from the group working on this, as
it's been over a month now... Thanks.
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.
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.