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 channels. 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) permanently. 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.
Philippe, 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? Thanks.
*** 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 resolved soon.
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 release.
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. http://rhn.redhat.com/errata/RHBA-2009-0170.html