This is important. And it is synced with 620844.
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:
Created attachment 438038 [details]
Created attachment 438039 [details]
Created attachment 438040 [details]
Created attachment 438041 [details]
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.
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.
Clearing NEEDINFO from David Cantrell.
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.
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.
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.
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.
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.
(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.
No problem :)
Any news on the async update?
I am checking - I thought this was done.
Apparently, this was issued some time back as I suspected:
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.
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.
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.