# 2.6.31-r6 -> 2.6.31-r10 [Solved]

## aCOSwt

Hello,

As it is the first time I am going to proceed with a gentoo-sources upgrade, I try to follow the documentation.

 *Quote:*   

> §10.  Advanced: Using your old kernel .config to configure a new one
> 
> It is sometimes possible to save time by re-using the configuration file from your old kernel when configuring the new one. Note that this is generally unsafe -- too many changes between every kernel release for this to be a reliable upgrade path. 
> 
> The only situation where this is appropriate is when upgrading from one Gentoo kernel revision to another. For example, the changes made between gentoo-sources-2.6.9-r1 and gentoo-sources-2.6.9-r2 will be very small, so it is usually OK to use the following method.

 

Well well... I am in a situation where it should usually be OK...   :Confused:   :Confused: 

Apart from asking you...   :Very Happy: , what, BTW I do...   :Very Happy: ...

How can I know that it is actually OK for one specific kernel revision upgrade ?Last edited by aCOSwt on Sat Mar 13, 2010 5:25 pm; edited 1 time in total

----------

## krinn

because the kernel is still the same, the revision is just new patch gentoo devs add to the kernel to fix/optimize stuff (and can also add options, but generally never modify an existing option name)

but as the kernel remain the same, options names will remains the same too and are valid ones in .config

the doc is a bit shy about it. The only case when your .config should fail with a new kernel is when the new kernel renamed an option (it might happen, but not as much as that).

for example (fictive one!) : using a kernel option named : CONFIG_CPU=y and a newer kernel rename it to CONFIG_CPU_32 and CONFIG_CPU_64, this time as your option is CONFIG_CPU and it doesn't exist kernel should assume one per default, let's pickup CONFIG_CPU_32, and this could be bad if you run a 64bits cpu that need the CONFIG_CPU_64 option set.

And this case only will stop you from using the .config file as-is: copying it and doing the make bzimage will trigger unexpected results. But if you copy it and do make config, kernel will remove the CONFIG_CPU option for you and will stop to ask you what to answer to new options: so it will stop and ask about CONFIG_CPU_32 and CONFIG_CPU_64.

I suppose as the reader is reading it (a bit ugly but i'm not english!), the writer assume the reader doesn't how to do a kernel upgrade yet, and so  it's better to assume he should redo a whole kernel that might lower chances of troubles and train him to build kernel.

----------

## sera

 *aCOSwt wrote:*   

> How can I know that it is actually OK for one specific kernel revision upgrade ?

 

There is no guaranteed way to prove it's all fine. However I'm using make oldconfig for many years without troubles. Take a diff off the .config and if it doesn't look suspicious you should be fine.

Actually I think the chances for porting the .config to be the reason for breakage is rather small compared to the changes in the kernel itself.

----------

## Nerevar

A similar thread is here.

----------

## Simba7

It'll work fine. I've done this on 2 remote systems and my local systems without issue.

Now, if you switch to a newer kernel (other than .31), that's a different story.

----------

## aCOSwt

 *Simba7 wrote:*   

> It'll work fine.

 

Grrreat ! That is an answer ! At least the one I was waiting for !   :Cool:  Thank you Simba for your feadback.

I can start eyes closed.

 *sera wrote:*   

> There is no guaranteed way to prove it's all fine.

 

Hmmm... That is the answer I was fearing.   :Crying or Very sad: 

If there is no Simba7 next time, I will follow your advice diffing the two .config

Thanks to krinn detailed explanations, I should be able to sort what in the diff is suspicious out.

Thanks to all.

----------

