Bug 487479 - RPM Dependency Problem between module-init-tools and kmod-xenpv
RPM Dependency Problem between module-init-tools and kmod-xenpv
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel-xen (Show other bugs)
4.7
All Linux
low Severity medium
: rc
: ---
Assigned To: Don Dutile
Red Hat Kernel QE team
: Reopened
Depends On:
Blocks: 458302
  Show dependency treegraph
 
Reported: 2009-02-26 03:25 EST by Carsten Clasohm
Modified: 2010-07-16 04:22 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-06 13:46:16 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 Carsten Clasohm 2009-02-26 03:25:33 EST
Description of problem:

The module-init-tools RPM obsoletes modversions, but kmod-xenpv still depends on it.

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

module-init-tools-3.1-0.pre5.3.10
kmod-xenpv-0.1-10.el4
modversions-1.0-4.el4_6.1

How reproducible:

always

Steps to Reproduce:
1. On a fully virtualized RHEL 4.7 guest, try to install kmod-xenpv with up2date.

2. This fails because it requires modversions, which is obsoleted by the already installed module-init-tools.

  
Actual results:

Installation of kmod-xenpv with up2date is not possible.


Additional info:

It is possible to install modversions with "rpm -i", and then install kmod-xenpv. Also see BZ 458173 for the way up2date behaves in this situation.
Comment 1 Chris Lalancette 2009-02-26 04:37:14 EST
Actually, in point of fact, this isn't really a bug, since you don't need to use kmod-xenpv in 4.7 anymore.  That is, since 4.7, the PV-on-HVM drivers are built into the kernel, and all further development on them is being done there.  I'm going to close this as "NOTABUG" for now; if you disagree, feel free to reopen.

Chris Lalancette
Comment 2 Don Dutile 2009-02-26 13:26:15 EST
Re-opening this bz.

The reporter is 100% correct.

When upgrading from 4.6 to 4.7 (or soon, 4.8) with the kmod-xenpv
pkg installed, the module.dep has incorrect module dependencies
created due to a bug in modversions shipped in 4.6.  
The end result is that the kmod-xenpv .ko's are listed in the modules.dep
file instead of the in-kernel-pkg version of the xenpv drivers.

The solution is to install the 4.7 (or 4.8) module-init-tools, then
upgrade the kernel.  To do it automagically, the kernel spec file needs
to have a Requires: module-init-tools >= 3.1-0.pre5.3.10
added to it, *and* the kmod-xenpv-<>.el4 pkg has to have its
Requires change from modversions to this module-init-tools version
(to cover the multiple ways to update: just the kernel, just the kmod-xenpv,
 & both).

The kmod-rhel4 pkg is getting ready to be rev'd so it has this new dependency,
*and* the kernel spec needs to be changed for rhel4.8, as well as backported
to 4.7(.z), so updates from 4.6+xenpv => 4.7.x create a proper modules.dep.

Will leave this bz open until the changes are made to the kernel specs files
as well as the kmod-xenpv-<>.el4 pkg.

- Don Dutile
Comment 5 Don Dutile 2010-07-06 13:46:16 EDT
The final solution to this problem is to de-install the kmod-xenpv pkg _before_ installing/upgrading rhel4.7.

This means that if one wants to keep a 4.6 kernel + kmod_xenpv setup and a rhel4.7 kernel on the same (guest) system, one would have to save the
/lib/modules/<version>/kernel/drivers/xenpvhvm subdirectory to the side,
remove the kmod-xenpv pkg, do the rhel4.7 update, then put the saved
directory back.  It may also require saving the 4.6 initrd before the 
kmod-xenpv pkg removal.

This manual process is necessary due to the compound problem of the kmod-xenpv support being included in the rhel4.7 kernel package, the inclusion of modversions into the module-init-tools pkg, and the upgrading of kernels & kmod's and their dependencies btwn old and new kernels.  The m-i-t pkg wasn't designed to handle this odd combination (on rhel4), and the risk to upgrade it to do so puts other, more std, kmod-<> pkgs in jeopardy when rhel4 is upgraded again.
Comment 6 Paolo Bonzini 2010-07-16 04:22:19 EDT
We may need to write a kbase article on this.

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