On Mon, 1 Sep 2008, Jean-Paul Chaput wrote:

> Hello John,
>
> What you have seen are kernels of differents versions.
>
>  kernel-2.6.18-92.1.10.el5.x86_64       : up to date.
>  kernel-2.6.18-53.1.21.el5.JSP1.x86_64  : obsolete.
>  kernel-2.6.18-53.1.19.el5.JSP1.x86_64  : obsolete.
>
> I could have built a newer one with a version incremenent
> that would have been greater than the latest (NFS lockd) released,
> but this would mix up with the SL/TUV kernel versioning.
> That is, my "newer" kernel could get in the way and block
> updates from the distrib.

We normally just stick something on the end of %release ie see the comment 
in the kernel specfile:

# Polite request for people who spin their own kernel rpms:
# please modify the "buildid" define in a way that identifies
# that the kernel isn't the stock distribution kernel, for example,
# by setting the define to ".local" or ".bz123456"
#
#% define buildid

setting something like:

%define buildid .lockdpatch1

means that the release will have that stuck on the end and so count as 
'newer' than any current version but will be older than the next real 
release from upstream (which hopefully contains those fixes).

> So I made a "variant", that is another kernel but with the
> same version, so it do get in the way of the updates.
> Besides, it allows to revert to the up-to-date stock kernel
> in case of unexpected problem.

Obviously during testing one may want to back off but having multiple 
versions installed allows for temporary backoff and simply removing the 
newer version will make the previous newest the default.

Havibng it count as 'newer' helps when you want to add it to a local repo 
and push it to hundereds of boxes.  We will only add a locally patched 
kernel to our (standard) repos once we have tested the new kernel enough 
so we are pretty confident that any extra patches havn't broken anything 
(or at least nothing we care about).

> Unfortunately, we uses our NFS shares with the "nolock" option
> (my fellow sysadmin managing the servers under BSD, tells me
> that the lockd algorithm is intrinsistically flawed and do
> not want to uses it). So I haven't tested it yet.

I'm sure it is fundamentally flawed.

> I've made this kernel avalaible because I took me little time
> (automated procedure...) and some people seemed to be stuck
> by this bug.

Indeed but ideally people may want a fixed kernel for all the existing 
varieties/versions - since they may be using any of them...

I see that RH bugzilla #459083 implies that it might get applied to the 
5.2 stream.

-- 
/--------------------------------------------------------------------\
| "Computers are different from telephones.  Computers do not ring." |
|       -- A. Tanenbaum, "Computer Networks", p. 32                  |
---------------------------------------------------------------------|
| Jon Peatfield, _Computer_ Officer, DAMTP,  University of Cambridge |
| Mail:  [log in to unmask]     Web:  http://www.damtp.cam.ac.uk/ |
\--------------------------------------------------------------------/