Red Hat Bugzilla – Bug 143495
Unable to update GFS packages because of unresolvable chain of dependencies
Last modified: 2007-11-30 17:07:05 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.
Where can I find these GFS packages to take a look at them? What arches of GFS-modules-smp are installed?
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.
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.
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.
Blocking rhnupr4u4 and rhnupr3u8 to track the progress of the release
Moving bugs to the CanFix List
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.
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
This bug did not make the code freeze. It will not be fixed in this releasee Reea ligning to the next one.