How to locally maintain an end-of-life kernel branch?

How to locally maintain an end-of-life kernel branch?

[Michael Harless]

Hi,

Sorry if this is covered somewhere, I haven't been able to find much yet in
my searches.

I'm working on a project using the LTS 3.14 kernel, but I'll need to be
supporting it long after official support ends on kernel.org for the
branch.  Are there any pointers or suggestions on how to monitor for
security and bug fixes that I'll need to pull in and merge myself?  I'm
watching the lkml for patches and trying to follow the latest changes via
git, but I'm sure that I'll miss things in all of the traffic.  Thanks!


--Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160517/f5f97b18/attachment.html 

How to locally maintain an end-of-life kernel branch?

[Greg KH]

On Tue, May 17, 2016 at 11:21:52AM -0700, Michael Harless wrote:
> Hi,?
> 
> Sorry if this is covered somewhere, I haven't been able to find much yet in my
> searches.
> 
> I'm working on a project using the LTS 3.14 kernel, but I'll need to be
> supporting it long after official support ends on kernel.org for the branch.?

Eeek, why?  What is keeping you from moving to a newer kernel version?
Why is sticking with 3.14 a good idea for anyone?

> Are there any pointers or suggestions on how to monitor for security and bug
> fixes that I'll need to pull in and merge myself?

Look at the patches that are marked "cc: stable at vger.kernel.org" in the
changelog area when they hit Linus's tree.  Or look at the patches that
I apply to the latest stable tree.  Either way, be prepared to wade
through 100+ patches a week.

I'd recommend just updating to 4.1-stable, it will be easier and cheaper
for you in the long run.

good luck!

greg k-h

How to locally maintain an end-of-life kernel branch?

[Michael Harless]

Hi Greg,

On Tue, May 17, 2016 at 12:31 PM, Greg KH <greg@kroah.com> wrote:

> On Tue, May 17, 2016 at 11:21:52AM -0700, Michael Harless wrote:
> >
> > I'm working on a project using the LTS 3.14 kernel, but I'll need to be
> > supporting it long after official support ends on kernel.org for the
> branch.
>
> Eeek, why?  What is keeping you from moving to a newer kernel version?
> Why is sticking with 3.14 a good idea for anyone?
>

It's mainly due to certifications and testing and our upgrade process.  My
wish would be to update to a new kernel as well.


>
> > Are there any pointers or suggestions on how to monitor for security and
> bug
> > fixes that I'll need to pull in and merge myself?
>
> Look at the patches that are marked "cc: stable at vger.kernel.org" in the
> changelog area when they hit Linus's tree.  Or look at the patches that
> I apply to the latest stable tree.  Either way, be prepared to wade
> through 100+ patches a week.
>
>
That's what I was kind of afraid the answer was going to be.


> I'd recommend just updating to 4.1-stable, it will be easier and cheaper
> for you in the long run.
>
>
That's probably the next kernel I'll use, unless I can skip to an even
later one.  I'll still probably run into the same thing though, where I
need to support that kernel for awhile after it's reached end-of-life,
until I get some of the other upgrade problems solved.

Thanks for the suggestions on following stable and your patches, and giving
me a better idea of what kind of workload I'm looking forward to.


--Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160517/b5b0f6db/attachment.html 

How to locally maintain an end-of-life kernel branch?

[Valdis.Kletnieks at vt.edu]

On Tue, 17 May 2016 13:09:03 -0700, Michael Harless said:

> > Eeek, why?  What is keeping you from moving to a newer kernel version?
> > Why is sticking with 3.14 a good idea for anyone?
> >
>
> It's mainly due to certifications and testing and our upgrade process.  My
> wish would be to update to a new kernel as well.

That's a very broken certification system, if it allows you to attach
pretty much random patches onto a "blessed" 3.14 kernel, but won't let
you upgrade to a newer kernel

Thought Experiment:  What happens if you take a standard 3.14 kernel, and apply
*every single* patch from 3.15 from Linus's tree except the one that actually
tags it as 3.15?

(And yes, I've had systems running stuff certified for RHEL 6.1, but the
system was actually updated all the way to 6.7 except for the RPM that
has /etc/redhat-release ....)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160517/434666c4/attachment.bin 

How to locally maintain an end-of-life kernel branch?

[Greg KH]

On Tue, May 17, 2016 at 04:27:35PM -0400, Valdis.Kletnieks at vt.edu wrote:
> On Tue, 17 May 2016 13:09:03 -0700, Michael Harless said:
> 
> > > Eeek, why?  What is keeping you from moving to a newer kernel version?
> > > Why is sticking with 3.14 a good idea for anyone?
> > >
> >
> > It's mainly due to certifications and testing and our upgrade process.  My
> > wish would be to update to a new kernel as well.
> 
> That's a very broken certification system, if it allows you to attach
> pretty much random patches onto a "blessed" 3.14 kernel, but won't let
> you upgrade to a newer kernel

You beat me to it :)

> Thought Experiment:  What happens if you take a standard 3.14 kernel, and apply
> *every single* patch from 3.15 from Linus's tree except the one that actually
> tags it as 3.15?

Hey, wait, some other distro did that once, and guess what, no one
noticed!  So other distros finally got wise and just gave up the charade
and now do full kernel updates on incremental releases, with no reported
problems at all (i.e. SuSE and Oracle.)

So, just grab the 4.4 kernel tree and patch the makefile to say it is
3.14 and you should pass the certification system just fine!

best of luck,

greg k-h

How to locally maintain an end-of-life kernel branch?

[Greg KH]

On Tue, May 17, 2016 at 01:09:03PM -0700, Michael Harless wrote:
>     I'd recommend just updating to 4.1-stable, it will be easier and cheaper
>     for you in the long run.
> 
> That's probably the next kernel I'll use, unless I can skip to an even later
> one.? I'll still probably run into the same thing though, where I need to
> support that kernel for awhile after it's reached end-of-life, until I get some
> of the other upgrade problems solved.

Please use 4.4 then if you can move, it will "live longer" than 4.1.

> Thanks for the suggestions on following stable and your patches, and giving me
> a better idea of what kind of workload I'm looking forward to.

A lot of work, hopefully your customers are paying you a lot of money to
do it, as it's not going to be easy, or cheap...

good luck!

greg k-h

How to locally maintain an end-of-life kernel branch?

[Michael Harless]

On Tue, May 17, 2016 at 1:48 PM, Greg KH <greg@kroah.com> wrote:

> On Tue, May 17, 2016 at 04:27:35PM -0400, Valdis.Kletnieks at vt.edu wrote:
> > On Tue, 17 May 2016 13:09:03 -0700, Michael Harless said:
> >
> > > > Eeek, why?  What is keeping you from moving to a newer kernel
> version?
> > > > Why is sticking with 3.14 a good idea for anyone?
> > > >
> > >
> > > It's mainly due to certifications and testing and our upgrade
> process.  My
> > > wish would be to update to a new kernel as well.
> >
> > That's a very broken certification system, if it allows you to attach
> > pretty much random patches onto a "blessed" 3.14 kernel, but won't let
> > you upgrade to a newer kernel
>
> You beat me to it :)
>
> > Thought Experiment:  What happens if you take a standard 3.14 kernel,
> and apply
> > *every single* patch from 3.15 from Linus's tree except the one that
> actually
> > tags it as 3.15?
>
> Hey, wait, some other distro did that once, and guess what, no one
> noticed!  So other distros finally got wise and just gave up the charade
> and now do full kernel updates on incremental releases, with no reported
> problems at all (i.e. SuSE and Oracle.)
>
> So, just grab the 4.4 kernel tree and patch the makefile to say it is
> 3.14 and you should pass the certification system just fine!
>
>
I'll look into that.  I've also got some 3rd party proprietary drivers
(ugh), that I'd have to see would work or not.

--Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160517/54d5e63b/attachment-0001.html