# Average time for gentoo-sources to become unmasked?

## Thomas2010

I noticed gentoo-sources-2.6.36.ebuild is available but when I updated my gentoo-sources I went from 2.6.34-r6 to 2.6.34-r12. When I looked in the ebuild I noticed the USE flag is "~x86" but I use "x86" in my make.conf file. 

1 - How much longer until the sources are unmasked? 

2 - How "dangerous" is it to unmasked the sources and build a kernel from them myself?

3 - On a related note, what is the common procedure for keeping old/rescue kernels around? It is just to leave the kernels in /boot or should a /boot/kernels directory be made and copy them into the directory? I name my kernels "kernel-<source version>".

----------

## NeddySeagoon

Thomas2010,

Its not very dangerous. You should always keep at least one working kernel beside the one you have just made so its easy to boot your system if you mess up the new kernel, or the new kernel fails for some reason.

The biggest problem seems to be for binary blob drivers. 2.6.36 needs the hard masked nvidia-drivers, which is also in the tree.

If you don't have an nvidia card, you won't care about that.

Every time you add a kernel to /boot, add a new booting stanza to grub.conf that points to it.  Don't move the kernels around.

When /boot is getting full, delete some old kernels and the grub entries that booted them.

----------

## dmpogo

 *NeddySeagoon wrote:*   

> 
> 
> Every time you add a kernel to /boot, add a new booting stanza to grub.conf that points to it.  Don't move the kernels around.
> 
> When /boot is getting full, delete some old kernels and the grub entries that booted them.

 

Also, when you are happy with the new kernel (or just straight away), make sure that it is the default entry in /boot/grub/grub.conf

(if you did not change much in grub.conf, it will be the first entry among the kernels)

----------

## NeddySeagoon

dmpogo,

I put the new boot stanza at the top of grub.conf, so its the default.

----------

## Thomas2010

My thanks for all the help. I am using the 2.6.36 kernel without any problems. I have integrated ATI graphics so there are no NVIDIA issues.

I have another question relating to kernel. If I want to make changes to the kernel do I have to boot into a different one before making any changes or can I make my changes, compile it, overwrite the current one, then reboot into the updated kernel? While looking through dmesg to see if I could figure out why sound is not working I noticed IPV6 was compiled into the kernel and I do not want it.

----------

## dmpogo

 *Thomas2010 wrote:*   

> My thanks for all the help. I am using the 2.6.36 kernel without any problems. I have integrated ATI graphics so there are no NVIDIA issues.
> 
> I have another question relating to kernel. If I want to make changes to the kernel do I have to boot into a different one before making any changes or can I make my changes, compile it, overwrite the current one, then reboot into the updated kernel? While looking through dmesg to see if I could figure out why sound is not working I noticed IPV6 was compiled into the kernel and I do not want it.

 

You can do it on working kernel, except one issue with modules.   The kernel itself does not matter, since it is loaded in the memory and will be reloaded only on reboot. However, if you changed the modules, and load modules after you reinstalled the new kernel, they may, theoretically,  fail, since they will be loaded into the old running kernel

----------

## Thomas2010

Once again, I thank you for your help. I updated my kernel and got sound working.

----------

## idella4

always a good practice to mark your initial thread [solved] when finished.

----------

## mpagano

1 - How much longer until the sources are unmasked? 

I usually wait 30 days before I request gentoo-sources to be stabilized.  We have some baselayout-1 issues with >= 2.6.35 , so we had to backport a fix and then wait 30 days for that, which is why there is no 2.6.35 stabled.

Personally, I would always run the latest version of a kernel that I could. People get hung up on running a "Stable" kernel and I don't know why.

2.6.34 has a stable version and 2.6.35 and 2.6.36 do not. So people run 2.6.34, even though it's no longer maintained by upstream (or me (Gentoo) at this point) and will not get any further updates.

People need to think differently when considering their kernel version than just "is it stable?".  For the kernel, I would also ask: "Is it still being maintained upstream and by my distro."

Right now I am maintaining Gentoo-sources 2.6.32, 35 and 36. I would not be running 33 or 34.

----------

## dmpogo

 *mpagano wrote:*   

> 1 - How much longer until the sources are unmasked? 
> 
> I usually wait 30 days before I request gentoo-sources to be stabilized.  We have some baselayout-1 issues with >= 2.6.35 , so we had to backport a fix and then wait 30 days for that, which is why there is no 2.6.35 stabled.
> 
> Personally, I would always run the latest version of a kernel that I could. People get hung up on running a "Stable" kernel and I don't know why.
> ...

 

You may find it funny,  but I still run 2.6.27 on my server and 2.6.32 on my laptop.  Actually, once hardware has been frozen,  there is usually very liitle point to upgrade  the kernel on this device, and for production systems, you know, the rule is - if it ain't broken don't fix it.

----------

## idella4

dmpogo,

I can only agree

----------

## chithanh

On my ThinkPad Edge 13 AMD, the 2.6.34 kernel boots but does not support hotkeys, rfkill or power management for the graphics chipset.

In 2.6.35, thinkpad_acpi support for Edge models and radeon power management was added.

In 2.6.36, rfkill works.

So up to now I had plenty reason to upgrade to newer kernels. But there were non-hardware improvements too, such as parallel crypto.

 *dmpogo wrote:*   

> You may find it funny, but I still run 2.6.27 on my server and 2.6.32 on my laptop. Actually, once hardware has been frozen, there is usually very liitle point to upgrade the kernel on this device, and for production systems, you know, the rule is - if it ain't broken don't fix it.

 I see your 2.6.32 laptop and raise you a btrfs formatted USB flash drive.  :Wink: 

----------

## dmpogo

 *chithanh wrote:*   

> On my ThinkPad Edge 13 AMD, the 2.6.34 kernel boots but does not support hotkeys, rfkill or power management for the graphics chipset.
> 
> In 2.6.35, thinkpad_acpi support for Edge models and radeon power management was added.
> 
> In 2.6.36, rfkill works.
> ...

 

That's what I meant, when hardware stabilizies.  On my server which is 6 years old,  went with Gentoo, because it had the latest kernel (2.6.3) and then updated regularly, before handling of that hardware stabilized in two years around 2.6.17.  That was 4 years ago, I then upgraded once to 2.6.27 because of udev issues.

 *Quote:*   

> 
> 
> So up to now I had plenty reason to upgrade to newer kernels. But there were non-hardware improvements too, such as parallel crypto.
> 
>  *dmpogo wrote:*   You may find it funny, but I still run 2.6.27 on my server and 2.6.32 on my laptop. Actually, once hardware has been frozen, there is usually very liitle point to upgrade the kernel on this device, and for production systems, you know, the rule is - if it ain't broken don't fix it. I see your 2.6.32 laptop and raise you a btrfs formatted USB flash drive. 

 

pass  :Smile:    BTW my laptop is thinkpad X300, which I got working completly around 2.6.29 - Fn keys, suspend/hibernate/bluetooth, everything.

rfkill, yes, is not working, done in software through acpi events[/quote]

----------

## mpagano

 *dmpogo wrote:*   

> 
> 
> You may find it funny,  but I still run 2.6.27 on my server and 2.6.32 on my laptop.  Actually, once hardware has been frozen,  there is usually very liitle point to upgrade  the kernel on this device, and for production systems, you know, the rule is - if it ain't broken don't fix it.

 

No, I don't. .27 and .32 are both maintained upstream so it meets the criteria I spoke of.

----------

## mv

 *mpagano wrote:*   

> People need to think differently when considering their kernel version than just "is it stable?".  For the kernel, I would also ask: "Is it still being maintained upstream and by my distro."

 

Why should people think that they should use for kernels a different policy than for other packages?  Nothing in gentoo documentation says so.  So (unless you had just written the contrary), I would expect that a kernel marked "stable" by the distribution is checked for security by that distribution. Otherwise the label "stable" has no meaning (and actually the kernel should be masked, if you do not know whether there are unfixed security issues).  So I strongly suggest to reconsider the policy of marking kernels stable: If security issues are involved, it should match with upstreams policy (i.e. only those kernels still maintained upstream [or by you] for security issues should be marked stable and otherwise masked).

----------

## dmpogo

 *mpagano wrote:*   

>  *dmpogo wrote:*   
> 
> You may find it funny,  but I still run 2.6.27 on my server and 2.6.32 on my laptop.  Actually, once hardware has been frozen,  there is usually very liitle point to upgrade  the kernel on this device, and for production systems, you know, the rule is - if it ain't broken don't fix it. 
> 
> No, I don't. .27 and .32 are both maintained upstream so it meets the criteria I spoke of.

 

But  .27 (gentoo-sources) is not in a portage tree anymore  as of something like month ago.

----------

## RedSquirrel

 *mv wrote:*   

> So I strongly suggest to reconsider the policy of marking kernels stable: If security issues are involved, it should match with upstreams policy (i.e. only those kernels still maintained upstream [or by you] for security issues should be marked stable and otherwise masked).

 

You might be interested in Bug 338739 - sys-kernel/vanilla-sources: stabilisation policy if you haven't seen it already. The discussion seems to have cooled off a bit.

Personally, I'm following a policy similar to the one described there, that is, using the 2.6.32 branch as a stable kernel. I also track the latest upstream stable release (2.6.36 as of this writing), but with mixed results.

----------

## mv

 *RedSquirrel wrote:*   

> You might be interested in Bug 338739 - sys-kernel/vanilla-sources: stabilisation policy if you haven't seen it already.

 

Thanks. I was not aware of that discussion. So all suggestions were already made...

----------

