Bug 622986 - Driver Update Disks need to match on "kabi-modules", and not "kernel-modules"
Summary: Driver Update Disks need to match on "kabi-modules", and not "kernel-modules"
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda   
(Show other bugs)
Version: 6.1
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Martin Sivák
QA Contact: Release Test Team
Depends On: 620844
Blocks: 593390
TreeView+ depends on / blocked
Reported: 2010-08-11 00:24 UTC by Jon Masters
Modified: 2014-01-21 06:19 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 620844
Last Closed: 2010-10-05 16:57:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
TEST-CHANGED-PROVIDES-internal-RHEL6.0-DUD-sym53c8xx-2.6.32-59.1-1-x86_64.iso.gz (622.25 KB, application/x-gzip)
2010-08-11 01:11 UTC, Jon Masters
no flags Details
TEST-CHANGED-PROVIDES-internal-RHEL6.0-DUD-sym53c8xx-2.6.32-59.1-2-x86_64.iso.gz (622.31 KB, application/x-gzip)
2010-08-11 01:12 UTC, Jon Masters
no flags Details
TEST-CHANGED-PROVIDES-internal-RHEL6.0-DUD-virtio_blk-2.6.32-59.1-1-x86_64.iso.gz (157.41 KB, application/x-gzip)
2010-08-11 01:12 UTC, Jon Masters
no flags Details
TEST-CHANGED-PROVIDES-internal-RHEL6.0-DUD-virtio_blk-2.6.32-59.1-2-x86_64.iso.gz (157.51 KB, application/x-gzip)
2010-08-11 01:12 UTC, Jon Masters
no flags Details

Comment 1 Jon Masters 2010-08-11 00:25:34 UTC
This is important. And it is synced with 620844.

Comment 3 Jon Masters 2010-08-11 01:11:14 UTC
I am attaching 4 example disk images, built against 2.6.32-59.1.el6.x86_64, that use the newer "kabi-modules" provides in place of "kernel-modules". This should allow you to continue testing the moment you change this. Also, bear in mind that these may need respinning for newer kernels than 2.6.32-59.1 as the kABI is not frozen yet. In that case, you should download the ddiskit-v2.4+ and use that:



Comment 4 Jon Masters 2010-08-11 01:11:49 UTC
Created attachment 438038 [details]

Comment 5 Jon Masters 2010-08-11 01:12:08 UTC
Created attachment 438039 [details]

Comment 6 Jon Masters 2010-08-11 01:12:29 UTC
Created attachment 438040 [details]

Comment 7 Jon Masters 2010-08-11 01:12:46 UTC
Created attachment 438041 [details]

Comment 9 Jon Masters 2010-08-11 01:16:32 UTC
Those disks were built after applying the patch in 620844 to the redhat-rpm-config package, which was rebuilt as a test version. Internal folks can get access to the test build that I did of that and get the package even while waiting for the approval to incorporate that fix officially.

Comment 10 Jon Masters 2010-08-11 17:39:24 UTC

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.


Comment 12 Jon Masters 2010-08-11 17:43:19 UTC
Clearing NEEDINFO from David Cantrell.

Comment 13 Jon Masters 2010-08-16 22:49:10 UTC
Martin Wilck: This pertains to the other side of 620844. If you do decide this is critical to 6.0 for you and you raise 620844 then please also mention this is the other half of the issue.

Comment 16 Jon Masters 2010-08-17 18:04:07 UTC
Thanks Martin. I have raised this internally.

Comment 17 Jon Masters 2010-08-18 03:01:53 UTC
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 18 Martin Wilck 2010-08-23 09:52:00 UTC

please specify unambiguously what the syntax of the "kabi-modules" is going to be in 6.1. I need to put this into my kmods today, I don't want to rebuild everything for 6.1.


Comment 19 Jon Masters 2010-08-24 17:51:36 UTC
I am going to request that, in 6.1 we simply replace kernel-modules with kabi-modules. So you should be able to simply find/replace that single occurrence with the new one. However, obviously, if some unforeseen issue arises, we may have to do something else instead.


Comment 20 Jon Masters 2010-09-15 18:39:35 UTC
We are looking instead at an async update to 6.0 that will change the default installonly behavior such that it does not consider "kernel-modules" as an installation always and only target. I am sorry for the confusion Martin. Please do ping me in a week or two if you are unclear as to the state of that.


Comment 22 Martin Wilck 2010-09-16 15:28:01 UTC
(In reply to comment #20)
> We are looking instead at an async update to 6.0 that will change the default
> installonly behavior such that it does not consider "kernel-modules" as an
> installation always and only target. I am sorry for the confusion Martin.

I am happy to hear this. As I pointed out several times, I think this is the right solution. I'd be happy to see this update published early.

> Please do ping me in a week or two if you are unclear as to the state of that.

Just update this BZ if you know more details. Thanks a lot.

Comment 23 Jon Masters 2010-09-17 14:36:33 UTC
No problem :)

Comment 26 Martin Wilck 2011-01-28 14:52:47 UTC
Any news on the async update?

Comment 27 Jon Masters 2011-02-01 20:24:54 UTC
I am checking - I thought this was done.

Comment 28 Jon Masters 2011-02-02 03:36:44 UTC
Apparently, this was issued some time back as I suspected:



Comment 29 Jon Masters 2011-02-04 07:54:50 UTC
I provided the link to the correct Zstream bug elsewhere - the one referenced in c#28 applies only to 6.1, not to 6.0.z, our "async" releases for RHEL6.0.

Comment 30 Martin Wilck 2011-02-04 10:46:23 UTC
It's bug #634974, Gary pointed it out to me. Thanks.

However I am in an awkward situation now. I already asked Gary about it, I'd like to see your comment, too:

I could add a Requires: or PreReq: dependency on yum >= 3.2.27-14.el6_0.1 in our FTS kmods (mopre precisely, in our FTS "primergy-dup" base package, on which all our kmods depend). However, that would cause problems at system installation time because that package wouldn't available before the RHN update repositories are configured. 

The only chance I currently see is to get an exceptional permission from Red Hat to re-distribute the updated yum package on our DUDs, similar to what we did last year with the module-init-tools package from Bugzilla 638855 / RHBA 2010-0759. At that time, Red Hat granted us the permission. But in that context, Daniel Riek wrote "I'd like to clarify that nothing in this email may
be understood as a generic exception from these rules or as any kind of precedence for future similar issues". So, we need to request another, similarly specific exception for yum-3.2.27-14.el6_0.1.

Comment 31 Jon Masters 2011-02-08 10:11:10 UTC
There should not be a need to ship a replacement yum. If you have renamed the dependencies, it should be possible to use the standard kernel-modules dependency in your Driver Update Disk. Once the system is installed, the user will get the latest version of yum installed when they update.

If you are also shipping a repo and are concerned that the user will automatically update the driver before they receive the latest yum, that is a legitimate concern. I think I would prefer that (in that case), you instruct the user to run "yum update yum" as a first step post-install before running a general update in the case of using a driver disk. If we can have the correct version of yum installed, then there will be no problem going forward.

I realize you want to make this as automatic as possible - we can also discuss this on Wednesday during our call.


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