Bug 620844 - kmod update fails with yum (works with rpm -U)
kmod update fails with yum (works with rpm -U)
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: redhat-rpm-config (Show other bugs)
6.1
All Linux
urgent Severity medium
: rc
: ---
Assigned To: Jon Masters
BaseOS QE Security Team
:
Depends On:
Blocks: 622986
  Show dependency treegraph
 
Reported: 2010-08-03 11:56 EDT by Martin Wilck
Modified: 2014-01-21 01:18 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 622986 (view as bug list)
Environment:
Last Closed: 2011-02-01 22:36:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sample DUD containing kmod (646.00 KB, application/x-cd-image)
2010-08-03 11:56 EDT, Martin Wilck
no flags Details
script session demonstrating the problem (44.13 KB, text/plain)
2010-08-03 11:57 EDT, Martin Wilck
no flags Details
redhat-rpm-config-9.0.3-RHEL6-kmodtool-change-kernel-modules-provide-to-kabi-modules-provide.patch (606 bytes, patch)
2010-08-10 20:54 EDT, Jon Masters
no flags Details | Diff

  None (edit)
Description Martin Wilck 2010-08-03 11:56:31 EDT
Created attachment 436306 [details]
sample DUD containing kmod

Description of problem:

The update of a kmod package fails with the following error message:


Error: Package: kmod-megasr-13.21.0614.2010-4.x86_64 (@m4)
           Requires: primergy-megasr = 13.21.0614.2010-4
           Removing: primergy-megasr-13.21.0614.2010-4.x86_64 (@m4)
               primergy-megasr = 13.21.0614.2010-4
           Updated By: primergy-megasr-13.21.0614.2010-5.x86_64 (m5)
               primergy-megasr = 13.21.0614.2010-5
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

The suggested --skip-broken option doesn't solve the problem.

However, downloading the RPMs and updating with rpm -U works fine.


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

RHEL6 beta2 snapshot 8

How reproducible:
always

Steps to Reproduce:
1. build a kmod (see additional comments below)
2. update the kmod

Actual results:
see above

Expected results:
update succeeds

Additional info:

This may be due to the structure of the FTS kmod that has been established for RHEL5. Under RHEL5 we used to have several kernel flavors. Some files (/etc/modprobe.d/xyz.conf, documentation, PCI ID updates) are flavor-independent. They were therefore moved into a separate package "primergy-xyz":

(arrows denote "Requires:" dependency)

kmod-xyz-1.0  -> primergy-xyz = 1.0
kmod-xyz-xen-1.0 -> primergy-xyz = 1.0
kmod-xyz-PAE-1.0 -> on primergy-xyz = 1.0

This works nicely under RHEL5.

I have kept this structure under RHEL6, although there is currently only a single relevant kernel flavor (after all, we may want to build a kmod for the debug kernel some time in the future, or RHEL6 may be forced to introduce a new kernel flavor due to new HW availablity, who knows).

What's going wrong in yum:

Yum doesn't "update" but "install" the updated kmod (kmod-xyz-1.1). The new kmod requires an updated primergy-xyz-1.1 package, but that would break the previous kmod version kmod-xyz-1.0 because that depends on primergy-xyz-1.0. The obvious solution to this problem is to remove kmod-xyz-1.0 (IOW: to do a real update on the kmod).

Btw, without this dependency the install (rather than update) would probably also fail because kmod-xyz-1.0 and kmod-xyz-1.1 have conflicting files.

It is possible to work around this problem by overriding the installonlypkgs option in yum.conf:

installonlypkgs=kernel,kernel-bigmem,kernel-enterprise,kernel-smp,kernel-debug,kernel-unsupported,kernel-source,kernel-devel,kernel-PAE,kernel-PAE-debug

(see bug #502140 for a similar problem under RHEL5 - we didn't have that problem on RHEL5; don't ask me why).

This workaround doesn't have adverse effects AFAICT, so please change the default settings of yum.
Comment 1 Martin Wilck 2010-08-03 11:57:48 EDT
Created attachment 436307 [details]
script session demonstrating the problem
Comment 3 RHEL Product and Program Management 2010-08-03 12:28:00 EDT
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 4 Jon Masters 2010-08-06 13:22:23 EDT
Thanks for the report. I think the problem here is with the structure of the specific Fujitsu packages. Can you possibly send me the packages? I'm ok with binaries if needed - email is fine too.

Jon.
Comment 5 Jon Masters 2010-08-09 18:27:04 EDT
Ok. I've gone through all of the details here again. We should come up with a solution to this that also targets RHEL5. We want kmods generally to be upgraded, and not installed. I will sync up with James Antill.

Jon.
Comment 10 Jon Masters 2010-08-10 00:15:59 EDT
So it looks like we'll just drop "kernel-modules" as an automatic provide and make it kabi-modules or something. Should not be any impact other than it will make it clearer that you don't have multiple versions of the same kmod at once.

Jon.
Comment 13 Jon Masters 2010-08-10 20:19:41 EDT
I have requested the corresponding change to Anaconda be made:

./loader/driverdisk.c:    return strcmp(dep, "kernel-modules") || strcmp(version, kernelver);

Will need to match on "kabi-modules" in order to ensure we are consistent. I think this is something we should do for 6.0 in order to avoid behavior changing later on that is confusing. It's a one-line patch without any real risk.

Jon.
Comment 14 Jon Masters 2010-08-10 20:54:04 EDT
Created attachment 438036 [details]
redhat-rpm-config-9.0.3-RHEL6-kmodtool-change-kernel-modules-provide-to-kabi-modules-provide.patch
Comment 16 Jon Masters 2010-08-11 13:39:12 EDT
Folks,

We have decided to defer this fix. We will immediately discuss the implementation of the fix for RHEL6.1 however at this time there are other risks to changing the Anaconda loader behavior, and the potential for unintended fallout from this. So even though I have test packages, etc. and it's relatively small, we don't want to cause other problems with installation. Instead, we will discuss workaround options and documentation solutions for RHEL6.0. Thanks for your understanding.

Jon.
Comment 19 Martin Wilck 2010-08-12 05:01:08 EDT
Jon, 

two questions:

1) Why can't you simply change the default for "installonlypkgs" in yum? What's the reason that "kernel-modules" is a member of this list? No other packages except kmods provide it under RHEL6, AFAICS. So changing the default can't do any harm.
2) The kmod change is deferred according to comment #16. Will "kabi-modules" be introduced in RHEL6.1, yes or no? If yes I'd rather put "kabi-modules" in my kmods now already in order to be able reuse them later.

Martin

PS: IMO it would be interesting to introduce 

Provides: kabi-modules = <checksum>

where <checksum> would kind of a global KABI checksum, rather than

Provides: kabi-modules = <version>

No?
Comment 20 seth vidal 2010-08-12 08:52:21 EDT
Changing the default of installonlypkgs impacts other providers of rpms who are counting on yum to have certain behavior when it sees 'kernel-modules' as a provides. Changing that at this stage of the game will negatively impact them.
Comment 21 Martin Wilck 2010-08-12 09:02:01 EDT
(In reply to comment #20)
> Changing the default of installonlypkgs impacts other providers of rpms who are
> counting on yum to have certain behavior when it sees 'kernel-modules' as a
> provides. Changing that at this stage of the game will negatively impact
> them.    

What providers would that be? Are these guys providing kmods or anything else? If it's kmods, they should also benefit from this change. What else except kmods is providing "kernel-modules"?
Comment 22 seth vidal 2010-08-12 09:15:41 EDT
Not if their kernel modules are assuming that their pkgs will be installed and not updated so they are NOT removing older versions of themselves.
Comment 23 Martin Wilck 2010-08-12 09:23:41 EDT
(In reply to comment #22)
> Not if their kernel modules are assuming that their pkgs will be installed and
> not updated so they are NOT removing older versions of themselves.    

That would be a wrong assumption. Please see comment #10, where Jon asserts that "you don't have multiple versions of the same kmod at once".
Comment 24 seth vidal 2010-08-12 09:53:47 EDT
of HIS kmods. not all other kernel-modules. There are lots of other odd ball kernel-modules out there and they will be trying to obey the existing rules.
Comment 25 Martin Wilck 2010-08-12 09:58:39 EDT
(In reply to comment #24)
> of HIS kmods. not all other kernel-modules. There are lots of other odd ball
> kernel-modules out there and they will be trying to obey the existing rules.    

I thought Jon (representing Red Hat in this matter) was creating the rules for kmods under RHEL6 that everyone else should adhere to.
Comment 26 seth vidal 2010-08-12 10:11:27 EDT
1. Not everyone works for red hat but they still build pkgs that our users will end up using or they will end up using on our system.

2. breaking stride with what upstream AND fedora have done and continue to do seems like a bad move from a maintenance/testing standpoint.
Comment 27 Martin Wilck 2010-08-12 11:42:42 EDT
In other words, Red Hat would rather break updates for partners who follow the rules than break anything for people who don't. I see.

Well, let's go back to the technical discussion.

I think Jon's comment #10 is more general than you think. What possible sense could it make to have more than a single instance of a kmod installed at the same time? With weak-modules in place, it only makes sense if you need multiple kmods to match different kernels with incompatible KABI. But RHEL6 makes strong guarantees about the KABI, thus this scenario shouldn't ever occur under RHEL6.

On the other hand, updates of kmods will occur for every partner who builds kmods - kmods need updates once in a while just like every other software package. The current situation - which won't be fixed according to comment #16 - is that these updates will always fail unless users change their yum configuration. That's quite a restriction IMHO.
Comment 28 seth vidal 2010-08-12 11:57:16 EDT
(In reply to comment #27)
> In other words, Red Hat would rather break updates for partners who follow the
> rules than break anything for people who don't. I see.
> 

I don't speak for red hat or make any decisions about rhel6. I have made no statements for 'red hat'. I have only made an argument for why changing this setting in yum will be LESS good and will require MORE testing.


> Well, let's go back to the technical discussion.
> 
> I think Jon's comment #10 is more general than you think. What possible sense
> could it make to have more than a single instance of a kmod installed at the
> same time? With weak-modules in place, it only makes sense if you need multiple
> kmods to match different kernels with incompatible KABI. But RHEL6 makes strong
> guarantees about the KABI, thus this scenario shouldn't ever occur under RHEL6.
> 

openafs is the module that streaks to mind that never seemed to get along with our older kernel iterations in rhel4 or rhel5 and had to be rebuilt everytime.


> On the other hand, updates of kmods will occur for every partner who builds
> kmods - kmods need updates once in a while just like every other software
> package. The current situation - which won't be fixed according to comment #16
> - is that these updates will always fail unless users change their yum
> configuration. That's quite a restriction IMHO.    

This is why, in the past, kernel module plugins existed to manage just those cases where the module needed to be 'updated' not 'installed'. They normally did that by checking to see if the kernel evr that the module required had NOT changed while the kernel module version had changed.
Comment 29 Jon Masters 2010-08-16 18:45:34 EDT
The bottom line here is I would like to change to kabi-modules, but I can't do that in 6.0 because it is too late to make the switch. We will switch the provides that Anaconda looks for to e.g. kabi-modules later, but we can't do this for 6.0 at this time.

Martin: if you view this as critical for 6.0, please raise it with your RH contact with a justification and a link to this BZ.
Comment 31 Martin Wilck 2010-08-17 03:58:22 EDT
We need a solution for 6.0, definitely. It must be possible to update kmods. I will talk to Larry Troan about it.

My plan is to change the yum configuration for PRIMERGY systems. Either by writing documentation and asking our customers to set "installonlypkgs" by hand, or by forcing this configuration onto them somehow.

I am still convinced that it would be better for Red Hat and for its customers to change the default for "installonlypkgs" in yum, but I am tired of arguing. All relevant arguments for either side have been made on this bugzilla. 

Just one tiny little extra point: If you actually do the change from "kernel-modules" to "kabi-modules", all the non-conforming kmod authors that Seth is worried about will need to modify their code for 6.1. Wouldn't it be better to make them adapt now (with a major release, where people are expecting things to change) than later??
Comment 34 Jon Masters 2010-08-17 14:02:09 EDT
Thanks Martin. I have raised this internally.
Comment 35 Jon Masters 2010-08-17 23:01:38 EDT
Unfortunately, this must be deferred to RHEL6.1. We can talk about acceptable workarounds by email. I am sorry, but it is too late to make this change.
Comment 38 Martin Wilck 2011-01-28 09:59:52 EST
Jon,

in https://bugzilla.redhat.com/show_bug.cgi?id=622986#c20, you promised an async errata for yum changing the "installonlypkgs" option in a way similar to what I suggested in comment #19. Any progress on that?

Martin
Comment 39 Jon Masters 2011-02-01 15:43:43 EST
As I said, I am checking on this - I thought it was done.
Comment 40 Jon Masters 2011-02-01 22:36:16 EST
Apparently, this was issued some time back as I suspected:

https://bugzilla.redhat.com/show_bug.cgi?id=628151

Jon.
Comment 41 Martin Wilck 2011-02-02 05:08:42 EST
But it was declined as an errata and deferred to 6.1, if I am reading correctly.

What Fujitsu could do is to write the required installonlypkgs option in yum.conf using our DUP base package "primergy-dup", on which all our kmods depend. Please comment if you think that would be appropriate.
Comment 42 Jon Masters 2011-02-04 02:27:46 EST
Sorry, the link I provided was to the main RHEL6 package bug (that will feed into 6.1), but the actual "Zstream" errata bug was already fixed:

https://bugzilla.redhat.com/show_bug.cgi?id=634974

Jon.

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