Created attachment 436307 [details]
script session demonstrating the problem

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. **

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.

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.

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.

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.

Created attachment 438036 [details]
redhat-rpm-config-9.0.3-RHEL6-kmodtool-change-kernel-modules-provide-to-kabi-modules-provide.patch

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.

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?

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.

(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"?

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.

(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".

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.

(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.

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.

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.

(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.

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.

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??

Thanks Martin. I have raised this internally.

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.

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

As I said, I am checking on this - I thought it was done.

Apparently, this was issued some time back as I suspected:

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

Jon.

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.

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.