Hide Forgot
Description of problem: This occurs on i386 and x86_64 versions of YUM, but may be present on more. YUM fails to update a set of our packages because it does not correctly resolve dependencies during the upgrade. It is only happening on our kernel module packages (built via the DUP, so it has many more depends... Not sure if that's causing it). YUM's dependency resolution wants to keep both the old package and install the new, which won't work due to conflicting dependencies. It *should* remove the old package and install the new package (same package name, newer version). This problem is still present in 6.0, but appears to be fixed in 6.1, which is workable for us. Unfortunately this also impacts our set of RPMs on the 5.x series and we would like to request that the fix be either backported into it or an out-of-band YUM package be created for 5.x with the fix, giving us a solution to point our users at. Version-Release number of selected component (if applicable): the latest RHEL 5.x this occurs on is RHEL 5.7 with yum 3.2.22-33 How reproducible: 100% reproducible with our package set on 5.4, 5.6, 5.7, and 6.0. 100% works on RHEL 6.1 Steps to Reproduce: 1. Install our packages from the older repository 2. update to the newer If necessary, I can provide two repositories that cause this, but will need clearance to release them from my company... If there are logs I can upload that aid in debugging this, it would be better. Actual results: Actual results: Update fails due to a failed dependency resolution. YUM is not properly upgrading. Instead it is keeping the old package installed and attempting to also install the new package, which leads to conflicts. The old package relies on older versions of packages which are also being updated. The two versions cannot install side-by-side. Expected results: All packages would be upgraded Additional info: kmod-vmware-tools-vmblock has a hard dependency on vmware-tools-core = a specific version (8.5.1). When we upgrade, we are intending to install a new kmod-vmware-tools-vmblock, which will require a new version of vmware-tools-core (8.6.0) It seems that YUM is marking kmod-vmware-tools-vmblock for installation rather than for upgrade. It sucessfully resolves the dependencies for the new version, but then it *also* attempts to resolve the dependencies for the old version. The two are incompatible, so it will fail. Upgrade text follows from 5.7 beta: Script started on Tue 05 Jul 2011 07:32:40 PM PDT ~]# yum list \*vmware\*|grep "core\|foundation\|vmblock\|libraries-nox\|guestlib" kmod-vmware-tools-vmblock.x86_64 1.1.2.0-2.6.18.8.el5.0 installed vmware-tools-core.x86_64 8.5.1-0 installed vmware-tools-foundation.x86_64 8.5.1-3 installed vmware-tools-guestlib.x86_64 8.5.1-0 installed vmware-tools-libraries-nox.x86_64 8.5.1-0 installed vmware-tools-vmblock-common.x86_64 8.5.1-0 installed kmod-vmware-tools-vmblock.x86_64 1.1.2.0-2.6.18.8.el5.3 vmware-tools vmware-tools-core.x86_64 8.6.0-2 vmware-tools vmware-tools-foundation.x86_64 8.6.0-4 vmware-tools vmware-tools-guestlib.x86_64 8.6.0-3 vmware-tools vmware-tools-libraries-nox.x86_64 8.6.0-2 vmware-tools vmware-tools-vmblock-common.x86_64 8.6.0-3 vmware-tools ~]# yum update kmod-vmware-tools-vmblock Loaded plugins: product-id, security, subscription-manager Updating Red Hat repositories. Skipping security plugin, no data Setting up Update Process Resolving Dependencies Skipping security plugin, no data --> Running transaction check ---> Package kmod-vmware-tools-vmblock.x86_64 0:1.1.2.0-2.6.18.8.el5.3 set to be installed --> Processing Dependency: vmware-tools-core = 8.6.0 for package: kmod-vmware-tools-vmblock --> Processing Dependency: vmware-tools-foundation >= 8.6.0 for package: kmod-vmware-tools-vmblock --> Processing Dependency: vmware-tools-vmblock-common >= 8.6.0 for package: kmod-vmware-tools-vmblock --> Running transaction check --> Processing Dependency: vmware-tools-core = 8.5.1 for package: kmod-vmware-tools-vmblock ---> Package vmware-tools-core.x86_64 0:8.6.0-2 set to be updated --> Processing Dependency: vmware-tools-libraries-nox = 8.6.0 for package: vmware-tools-core --> Processing Dependency: vmware-tools-guestlib = 8.6.0 for package: vmware-tools-core ---> Package vmware-tools-foundation.x86_64 0:8.6.0-4 set to be updated ---> Package vmware-tools-vmblock-common.x86_64 0:8.6.0-3 set to be updated --> Running transaction check --> Processing Dependency: vmware-tools-core = 8.5.1 for package: kmod-vmware-tools-vmblock ---> Package vmware-tools-guestlib.x86_64 0:8.6.0-3 set to be updated ---> Package vmware-tools-libraries-nox.x86_64 0:8.6.0-2 set to be updated --> Finished Dependency Resolution kmod-vmware-tools-vmblock-1.1.2.0-2.6.18.8.el5.0.x86_64 from installed has depsolving problems --> Missing Dependency: vmware-tools-core = 8.5.1 is needed by package kmod-vmware-tools-vmblock-1.1.2.0-2.6.18.8.el5.0.x86_64 (installed) Error: Missing Dependency: vmware-tools-core = 8.5.1 is needed by package kmod-vmware-tools-vmblock-1.1.2.0-2.6.18.8.el5.0.x86_64 (installed) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest The program [1mpackage-cleanup[m is found in the yum-utils package. ~]# rpm -q --requires kmod-vmware-tools-vmblock rpmlib(VersionedDependencies) <= 3.0.3-1 vmware-tools-vmblock-common >= 0:8.5.1 vmware-tools-core = 0:8.5.1 vmware-tools-foundation /sbin/depmod /sbin/depmod /bin/sh /bin/sh /bin/sh rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 kernel(rhel5_fs_ga) = 1c422a6b84a2000991b1b99c61506cfd711a20d1 kernel(rhel5_kernel_ga) = 84d69198cf51b494e38d9d0a54e52607c8a507e2 kernel(rhel5_mm_ga) = d5edc1b3d2a4f2bf8ce28d7f4dbeab27cfeb19bd kernel(rhel5_vmlinux_ga) = 78f928da689a93ecf2e044fc0ced6b3eaedf5c19 kernel(rhel5_lib_ga) = ff25b583d6d314edd98f7c9533c5867194b3d30d kernel(rhel5_fs_proc_ga) = 30f9166e128d20c7305d5a9bc9ab69451c40a555 kernel(rhel5_kernel_module_ga) = a74a9d2bf87d13d6b9412698dc2728248ca92523 ~]# exit exit Script done on Tue 05 Jul 2011 07:34:02 PM PDT
The offical way kmods should work differs greatly between RHEL-5 and RHEL-6 ... I'm guessing you are using the RHEL-6 way in RHEL-5? In RHEL-5 most usages should have the kmod-* package depend on the kmod yum plugin, AIUI.
We're not depending on AIUI at all right now, so that could definitely be the cause. I'll look into this and get back to you. We do hit this error in 6.0 though, not just the 5.x series. Did YUM kmod support change between 6.0 and 6.1 or is that plugin now installed in a default install for 6.1?
Never mind... Read that wrong, and I'm apparently not up on my acronyms ;) Anyway, we're not depending on yum-kmod. I'll get back to you on whether this works...
Tested out on 5.4, 5.6, and 5.7 beta and it's looking good. I noticed that 5.0 doesn't come with yum-kmods on the installation DVD, but 5.1 does. Is that package available for 5.0, or will we not be able to support upgrades on 5.0? Only 5.1 and later (which really shouldn't be a problem... I'm just curious where the limits are) Also, in the 6.* series, 6.0 does not have yum-kmods available (at least on the install DVD) and fails. 6.1 has the package available, but works even when it is not installed. Any thoughts on this?
I think the kmod plugin was added only in RHEL-5.1 ... but I'm not 100% on that. For RHEL-6 you don't need/want the plugin, and it should "just work". However I know we did a zero-day fix for yum to not look at "kernel-module" provides, so if the zero-day yum works and the RHEL-6.0 GA doesn't ... that's known/expected. If not, there could have been another bug we fixed in RHEL-6.1 (but I don't know what it is). You should also have some kind of "engineering kernel module support" process that you can use to and make sure you are doing "the right thing" in both RHEL versions (other than me :). I know the guy at the end of the line there, but I'm pretty sure all our partners aren't supposed to email him directly :).
Excellent... Thank you very much for the help and the info. Looks like updates are working well now.
Problem was resolved, closing to cleanup BZ lists.