Bug 448772

Summary: circular obsoletes in RHEL Desktop Workstation v. 5 channel
Product: Red Hat Enterprise Linux 5 Reporter: Philippe Brieu <philippe+bugzilla>
Component: openibAssignee: Doug Ledford <dledford>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 5.2CC: atodorov, dgregor, gozen, james.antill, jburke, jhutar, jim, jlaska, jlee23, mgahagan, ralston, riek, syeghiay, tao, tis
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 523135 (view as bug list) Environment:
Last Closed: 2009-01-20 21:41:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 451638, 523135    
Attachments:
Description Flags
output from first pass of 'yum update'
none
output from second pass of 'yum update' none

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
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.

Comment 1 Alexander Todorov 2008-05-29 08:28:40 UTC
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.

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
http://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
release.

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.

http://rhn.redhat.com/errata/RHBA-2009-0170.html