Hi Phil,
On Jan 12, 2011, at 20:58 , Phil Perry wrote:
> On 12/01/11 18:10, Stephan Wiesand wrote:
>>
>> Where "they work" at least means: there's a way to have working modules for *any* kernel installed on the system, not just the latest one, using nothing but yum or rpm. To the best of my understanding, this rules out the current ELRepo packages if/when the ABI used by the openafs modules changes, which can happen. Feedback on this issue, and the way I tackled it by making minute changes to the packaging, is still very welcome.
>>
>
> Hi Stephan,
>
> Sorry, I've not kept up with this thread - how did you solve the above issue?
it's not really solved. It's just possible to have working modules for all installed kernels, from kmod packages, at all.
> The default action for yum in RHEL6 is now to update kmod packages (as built with kmodtool); so do you retain an older compatible kernel module for older kernels once the kABI changes?
I saw you discussing this on the elrepo list, and I thought about it. It's a perfect solution in the sense that updates would still work as usual. But it's ugly because the spec needs to be touched when it happens, and because one would presumably package the binary. I tried to find a way to keep the previous module, unpackaged, in the case of such updates, maybe by stowing it away in %preun and restoring it in %posttrans and re-registering it with weak-modules. But it seemed too messy.
> Presumably you're talking about a case where, for example, you have a module built against 2.6.32-x that supports 2.6.32-x and 2.6.32-y, but when 2.6.32-z is released the module doesn't weak-link. Then, on rebuilding the module against 2.6.32-z you find it also no longer weak-links back to previous 2.6.32-x and 2.6.32-y kernel series.
Yes. I assume that the latter is the case if and only if the former is, since the ABI provides/requires are supposed to be complete on EL6.
And I expect it to happen sooner or later, because the openafs module uses lots of interfaces not on the whitelist.
> This is not an easy problem to solve in an automated fashion. Suppose we just build non-updating packages (as per the EL5 default), and build a new package for 2.6.32-z. That would work in the case above, but would fail in the case where the module built against 2.6.32-z does weak-link back against older kernels. You could fix this with an Obsoletes though I guess.
What I implemented is a compromise: updating packages, but with a one-to-one correspondence between the kernel release the module was built for, and the kmod release. For example, the current packages are
openafs-client-1.6.0-89.pre1.sl6.x86_64
kmod-openafs-1.6.0-89.pre1.sl6.71.x86_64
The extra ".71" means the module was built agains 2.6.32-71.el6. It's similar to the original fedora kmod convention, just a bit more wieldy.
If we update the openafs package to release 90, it will just work. Kernel updates will work as usual.
But now, we may also decide to rebuild against a later kernel, for whatever reason, and that will work as well (and the module will weak-link back to the other kernels).
And in the case that the next kernel update (say, 2.6.32-123.3.1) breaks the ABI, we can rebuild the unmodified SRPM against that kernel. The kmod package release will change to 89.pre1.sl6.123.3.1, yum updates will work as usual, but the system is left without a working module for the older kernels. However, it's possible to reinstall the previous kmod-openafs with "rpm -i --oldpackage" as a workaround for those in need of it.
And it's now also an option to keep yum from touching kernels and kmods, and updating kernels and modules by other means that guarantee that the AFS client will work when any kernel is booted. That's what we do here currently - we may hand kernel updates over to yum with SL6, but I'm not sure yet.
> If I may ask, why the need to continue to support older kernel series going forward?
For the same reasons we coinstall a new kernel instead of updating. It allows to decouple the rpm updates/installs and the reboot for activating the kernel, while being fully functional in the meantime, including the ability to restart the AFS client (reloading the module).
And: The new kernel may not work on some system, so it's good to be able to boot the old one and fix things up. In our environment, the ability to fix things up automatically depends on a working AFS client.
Both are rare cases. Which is why I think the compromise isn't so bad. Extending the kmod package release in this way allows coinstalling kmods when it's really required, and it allows updating to a build against a later kernel, while everything kmods do without this change simply keeps working the same way as before.
It's not a perfect solution, but there are advantages to doing it this way. And I don't see any disadvantage, but I may well be missing something. Thanks for any feedback!
Regards,
Stephan
--
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany
|
