Bug 143495 - Unable to update GFS packages because of unresolvable chain of dependencies
Unable to update GFS packages because of unresolvable chain of dependencies
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: up2date (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bret McMillan
Red Hat Satellite QA List
:
Depends On:
Blocks: 191074 191079
  Show dependency treegraph
 
Reported: 2004-12-21 12:26 EST by Chris Feist
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-30 16:50:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chris Feist 2004-12-21 12:26:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
It appears that the dependency checking logic is not working in up2date.

There are 2 packages which need to be installed for gfs: GFS &
GFS-modules[-smp].

GFS-modules[-smp] requires the same version of GFS as
GFS-modules[-smp].  When I do an upgrade, GFS-modules & GFS should be
upgraded at the same time.  When I manually do a rpm -Uvh GFS-* both
are upgraded without any errors.



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

How reproducible:
Always

Steps to Reproduce:
1.  Have GFS 6.0.0-15 & GFS-modules-smp-6.0.0-15 installed
2.  Attempt to run up2date -fu GFS GFS-modules-smp kernel-smp

    

Actual Results:  [root@ganon root]# up2date -fu GFS GFS-modules-smp
kernel-smp

Fetching Obsoletes list for channel: rhel-i386-as-3...

Fetching Obsoletes list for channel: rhel-i386-as-3-extras...

Fetching Obsoletes list for channel: rhel-i386-as-3-cluster...

Fetching Obsoletes list for channel: rhel-i386-as-3-gfs-6...

Fetching Obsoletes list for channel: rhel-3-as-i386-rhaps-1...

Fetching Obsoletes list for channel: rhel-3-as-i386-rhds-2...

Name                                    Version        Rel     
----------------------------------------------------------
GFS                                     6.0.2          17            
   i686  
GFS-modules-smp                         6.0.2          17            
   i686  
kernel-smp                              2.4.21         27.EL         
   i686  


Testing package set / solving RPM inter-dependencies...
There was a package dependency problem. The message was:

Unresolvable chain of dependencies:
GFS-modules-smp-6.0.0-15                 requires GFS = 6.0.0-15



Expected Results:  up2date should have seamlessly updated GFS &
GFS-modules

Additional info:

Users are unable to upgrade to a newer version of GFS until this is
fixed, or a work-around is devised.
Comment 1 Adrian Likins 2005-01-11 12:59:52 EST
Where can  I find these GFS packages to take a look at them?

What arches of GFS-modules-smp are installed?
Comment 3 Chris Feist 2005-01-12 12:00:18 EST
You can grab the new GFS packages from: 
http://porkchop.devel.redhat.com/dist/3.0E-gfs-U4/GFS/6.0.2-17/i686/

And you can get the old GFS packages from:
http://porkchop.devel.redhat.com/dist/3.0E-gfs-U3/GFS/6.0.0-10/i686/

I don't know where 6.0.0-15 went, but 6.0.0-10 should have the same
deps  as 6.0.0-15.

I was doing this all on i686.  It also appears that the problem
happens when going from 6.0.2-17 to 6.0.2-24 as well.
Comment 4 David Aquilina 2005-01-12 12:43:18 EST
I'm also seeing this when attempting to go from 6.0.0-1.2 to 6.0.2-24.
I have a couple machines which are exhibiting this behavior, let me
know if you'd like access to them. 
Comment 5 Chris Feist 2005-03-21 08:37:49 EST
Any status?  We continue to have users have problems with this.

One thing to note is if a user does a 'rpm -Uvh' with GFS & GFS-modules as
argumenets the install works without errors.
Comment 8 Fanny Augustin 2006-04-10 20:36:28 EDT
Blocking rhnupr4u4 and rhnupr3u8 to track the progress of the release
Comment 9 Fanny Augustin 2006-04-13 15:43:25 EDT
Moving bugs to the CanFix List
Comment 10 Bret McMillan 2006-04-30 16:50:43 EDT
So, I've dug into this some more, and replicated the issue when attempting to go
from a system that has these:

[root@localhost root]# rpm -q GFS GFS-modules --qf
"%{NAME}-%{VERSION}-%{RELEASE}:%{EPOCH}.%{ARCH}\n"
GFS-6.0.0-1.2:(none).i686
GFS-modules-6.0.0-1.2:(none).i686

to these:
[root@localhost root]# up2date -l | grep GFS
GFS                                     6.0.2.30       0                 i686
GFS-modules                             6.0.2.30       0                 i686


up2date attempts to build the following transaction set:
upgrade GFS-6.0.2.30-0.i386
upgrade GFS-6.0.2.30-0.i686
install GFS-modules-6.0.2.30-0.i386
install GFS-modules-6.0.2.30-0.i686

(Don't worry about the i386 bit now, it's a red herring b/c of another problem)

It is intsalling (vs upgrading) the GFS-modules packages because they have a
"kernel-modules" provide within them, and up2date has "kernel-modules" in its
configurable list of packages to always install-instead-of-update:

[root@localhost root]# cat /etc/sysconfig/rhn/up2date | grep NotUpdate
pkgsToInstallNotUpdate[comment]=A list of provides names or package names of
packages to install not update
pkgsToInstallNotUpdate=kernel;kernel-modules;kernel-devel;


The whole point, iirc, of the pkgsToInstallNotUpdate rules are so that
kernel-specific modules can be installed side-by-side, to allow for the
multiple-installed-kernel situation, etc.  Unfortunately, the GFS rpms seem to
have a packaging problem  GFS-modules-6.0.0-1.2 requires GFS-6.0.0-1.2, instead
of just requiring GFS, or GFS >= 6.0.0-1.2

The reason that matters is the transaction set that up2date creates above. 
up2date's transaction set is replacing GFS-6.0.0-1.2 with by upgrading it to
GFS-6.0.2.30-0.i686, but it is simply installing the new version of GFS-modules
side-by-side with the old one.  Unfortunately, the old one has a hard
requirement on the old version of GFS.

So, after up2date correctly adds the new i686 versions of GFS & GFS-modules to
is transaction set, it has an unmet dependency upon the old GFS.  It tries
adding in the i386 versions of the new GFS & GFS-modules packages in a vain
attempt to satisfy that dep, but ultimately fails.

The up2date code appears to be doing the right thing.  GFS-modules tells it: 
"I'm a package to install, not upgrade", and up2date listens to it.

I believe the correct fix is for the GFS packages to have the following general
requirements:

GFS-x.y.z-foo requires GFS-modules-x.y.z-foo
GFS-modules-x.y.z-foo requires GFS

Unfortunately, the packages in the field already won't be updatable given the
current situation.  Until something changes with the GFS packaging, the best
workaround I can recommend is removing 'kernel-modules' from the
/etc/sysconfig/rhn/up2date config file:

pkgsToInstallNotUpdate[comment]=A list of provides names or package names of
packages to install not update
#pkgsToInstallNotUpdate=kernel;kernel-modules;kernel-devel;
pkgsToInstallNotUpdate=kernel;kernel-devel;

The downside to this will be that any kernel-module packages will be
written-over upon upgrade :/

If there's anything I've missed, please re-open this bug report.
Comment 11 Fanny Augustin 2006-05-08 15:24:07 EDT
This bug did not make the code freeze and it will not be fiixed during this
release cycle.  Re-aligning bug to the next release
Comment 12 Fanny Augustin 2006-05-08 16:08:13 EDT
This bug did not make the code freeze.  It will not be fixed in this releasee 
Reea ligning to the next one.

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