How to locally maintain an end-of-life kernel branch?
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
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@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
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@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
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 ....)
On Tue, May 17, 2016 at 04:27:35PM -0400, Valdis.Kletnieks@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
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@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
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
participants (3)
-
Greg KH -
Michael Harless -
Valdis.Kletnieks＠vt.edu