[OpenAFS-devel] red hat 6 2.6.32-358.20.1.el6.x86_64 kernel

[Stephan Wiesand]

On Oct 7, 2013, at 16:47 , Jeffrey Altman wrote:

> On 10/7/2013 10:19 AM, Stephan Wiesand wrote:
>>=20
>> On Oct 7, 2013, at 15:48 , Jeffrey Altman =
<jaltman@your-file-system.com> wrote:
>>=20
>>> The required changes for the Linux 3.11 kernel will be included as =
part
>>> of the 1.6.5.1 release.   This release will also include Linux =
specific
>>> bug fixes and an AIX specific bug fix.
>>>=20
>>> The repository branch openafs-stable-1_6_5_x contains the proposed
>>> changes.  Unless something unexpected occurs the 1.6.5.1 release =
will be
>>> announced within the next two weeks.
>>=20
>> All true, but it's very unlikely that any of those changes are =
required to compile a working module for that RHEL-6.4 kernel. And none =
of the Linux specific bug fixes headed for 1.6.5.1 affects RHEL6.
>=20
> It all depends upon what Red Hat backported.

It's possible in theory. But really unlikely.

>> Either way, openafs modules for that kernel won't show up in any =
repository I know of before the source package is available on Red Hat's =
ftp server and rebuilt and released by the downstream projects. Which is =
unlikely to ever happen if this is indeed a hotfix only available to =
customers on special request.
>=20
> Agreed.  The most recent kernel in that series for which a src.rpm has
> been released by Red Hat is kernel-2.6.32-358.18.1.el6 which is dated =
15
> August 2013 but was published on 27 August 2013.   However, there are
> bug reports in the RedHat bugzilla referencing 2.6.32-358.20.1.el6
> dating to mid-August.

I found two of those, both against future RHEL6 minor releases and both =
mentioning 6.4.z - which is for customers who want to stay on 6.4 for a =
while but receive the critical fixes from those future releases =
backported to 6.4 after their release. Given that 6.4 still is the =
current minor release, "they released -358.20.1.el6" is a slight =
overstatement. None of all this is currently available publicly or to =
subscribers, even those with the EUS add-on, under normal circumstances.

I believe we have no way to provide binary modules for such cases in =
general. Chances are the kABI-tracking kmods from ELRepo or SL would =
just work, as would force-loading the module built against =
-358.18.1.el6. But given the outcome of previous discussions regarding =
kmods on this list, all these just aren't safe and can't be recommended.

Stephan=