# Which kernel to keep as backup? 4.9 or 4.11[SOLVED]

## Tony0945

My primary kernel is 4.12 but I keep a backup kernel in case the latest fails. Which kernel series would you keep as backup? 

I also keep 4.4.73 (frozen) as an emergency boot. 

Using grub legacy.Last edited by Tony0945 on Tue Aug 08, 2017 1:16 pm; edited 2 times in total

----------

## Jaglover

What's the difference, keep the latest kernel that worked for you before upgrade.

----------

## Tony0945

 *Jaglover wrote:*   

> What's the difference, keep the latest kernel that worked for you before upgrade.

 There might be a bug common to both, which is why I keep different series. Keeping all three up to date was working OK until Linus started the "kernel of the week club". I can't beleive these "stable" (according to kernel.org) releases are thoroughly tested.

----------

## asturm

Linus doesn't do kernel point releases.

 *Tony0945 wrote:*   

> I can't beleive these "stable" (according to kernel.org) releases are thoroughly tested.

 

Wait for a week and they inevitably are...

----------

## Tony0945

 *asturm wrote:*   

> Linus doesn't do kernel point releases.

  OK, somebody at kernel.org

----------

## saboya

Just wait a few weeks before upgrading?

----------

## marax_faraii

What I do is that I have the latest stable from the portage tree but my main is ~amd64 so when there's an update, I compile it, test it but I keep the previous version until all is conformed to work and if there's something I rely on doesn't work anymore I search for bugs and if there isn't any I open one.

----------

## Tony0945

 *marax_faraii wrote:*   

> What I do is that I have the latest stable from the portage tree but my main is ~amd64 so when there's an update, I compile it, test it but I keep the previous version until all is conformed to work and if there's something I rely on doesn't work anymore I search for bugs and if there isn't any I open one.

 

Thank you. Since none of the 4.11 branch are stable in the portage sense, then I would keep the 4.9 branch.

It would be good to do this automatically, but I don't know if it's possible to do "latest stable" in an ebuild. It is possible to specify the branch slot.

I used to specify specific versions in the world file when releases only came out every few months but I hate to edit the world file weekly; it's just an invitation to disaster.

----------

## toralf

Keep the last 2 working kernel versions, eg. both 4.9.36 and 4.11.9 - so you're on the save site.

----------

## Tony0945

 *toralf wrote:*   

> Keep the last 2 working kernel versions, eg. both 4.9.36 and 4.11.9 - so you're on the save site.

 

More work, but a solution.

Or do you mean keep just one (or two) specific versions, updatng monthly or quarterly instead of compiling each new release in the series?

That's a good answer too.

Do you know what's different architecturally between 4.9 and 4.11? That was the real basis of this thread. 

Why did 4.8 disappear from gentoo but 4.4 stayed?

----------

## fcl

 *Tony0945 wrote:*   

> ....
> 
> Why did 4.8 disappear from gentoo but 4.4 stayed?

 

If you check kernel.org you can see that 4.8 series isn't listed, ie. it's not supported anymore by upstream. Gentoo kernel team could manually patch it but it's not worth it as there are other older/newer kernels supported by upstream.

----------

## Tony0945

Versions changing too fast for me. And no longer any commentary on what changed.

----------

## Jaglover

I think I'm missing the whole reason for this discussion. Once I have the sources on my hard drive, why should I worry if the ebuild is still in the tree?

----------

## asturm

 *Tony0945 wrote:*   

> Versions changing too fast for me. And no longer any commentary on what changed.

 

The public git log really is enough for the small changes between point releases, I don't even remember the last time summary said anything else than 'all users must upgrade'.

 *Tony0945 wrote:*   

> More work, but a solution.

 

What exactly is 'work' about simply not deleting already compiled kernel images?

Are you desperately trying to find reasons to complain?

----------

## Tony0945

 *asturm wrote:*   

> What exactly is 'work' about simply not deleting already compiled kernel images?
> 
> Are you desperately trying to find reasons to complain?

 

The work is in compiling the new kernels, mostly in configuration.

 *Quote:*   

> Are you desperately trying to find reasons to complain?

 

I wasn't complaining. I thought[/quote] maybe someone new why there is a 4.9 series and a 4.11 series, i.e. What's the difference?

Why are you so truculent?

----------

## Tony0945

 *Jaglover wrote:*   

> I think I'm missing the whole reason for this discussion. Once I have the sources on my hard drive, why should I worry if the ebuild is still in the tree?

 

Yes, you are. It's not about keeping old versions. It's why should I keep building new subversions of both 4.9 and 4.11 instead of dumping one.

I'm marking it closed.

----------

## asturm

Why don't you ask that question right away? It's not hard to figure out that info (right from lkml), and there's much more than just 4.11 and 4.9 available:

```
mainline   4.12

stable   4.11.9

longterm   4.9.36

longterm   4.4.76

longterm   4.1.42

longterm   3.18.60 (EOL)

longterm   3.16.45

longterm   3.10.107

longterm   3.4.113

longterm   3.2.90
```

The further you go down, the more conservative the audience for these LTS releases are... It's really your choice, you know best which kernels work fine for your hardware. And if you don't want to make such decisions at all, just follow Gentoo stable kernels...

 *Tony0945 wrote:*   

> The work is in compiling the new kernels, mostly in configuration.

 

Why would you? make oldconfig for the new kernel, keep old kernel as fallback...

----------

## Hu

You shouldn't be updating both 4.9 series and 4.11 series on a single system.  Pick whether you want to track an LTS kernel or track a short-term stable kernel.  Build and switch to each point release of that series, ignoring any that you do not need (e.g. if a fix applies only to subsystems you know you do not build).  Identifying which kernels are irrelevant to you can be a bit challenging since every announcement says "everyone must upgrade" and does not usually go into whether there are any critical changes.  At that point, you need to choose either to err on the side of caution and take upgrades you may not need or err on the side of convenience and risk missing an update you should have taken.

----------

## Tony0945

The answer is 4.9, see here: https://fossbytes.com/linux-4-14-next-lts-kernel/

Good advice, Hu, but I prefer to keep at least two kernels in grub in case the latest has serious problems with my hardware.

----------

## s4e8

4.12 as backup, git-source as default.

----------

## NTU

 *s4e8 wrote:*   

> 4.12 as backup, git-source as default.

 

 :Laughing:   :Laughing:   :Laughing:   :Laughing:   :Laughing:   :Laughing:   :Laughing: 

Finally some decent advice! lmao

----------

## asturm

 *Tony0945 wrote:*   

> The answer is 4.9, see here: https://fossbytes.com/linux-4-14-next-lts-kernel/

 

 *asturm wrote:*   

> 
> 
> ```
> longterm   4.9.36
> ```
> ...

 

----------

