# make oldconfig - how does it work?

## piedar

I'm experiencing some confusion as to how to use make oldconfig on new kernel sources.  Should I copy my old .config to the current tree first or does oldconfig make a brand new .config by reading kernel information from somewhere else?

Also, I've read that it is not recommended to use the same .config for different kernel versions, but it is OK to use the same .config for different revisions of the same version.  Does this apply to make oldconfig as well?

----------

## John R. Graham

The source of information is an old kernel .config file.  What "make oldconfig" does is to make sure that all configurable items in the new kernel source are represented in the new .config file.  It also trims out any lines that may no longer be present.

There is usually acceptable luck in running "make oldconfig" if the old and new kernels are not very far apart.

- John

----------

## Jaglover

http://www.gentoo.org/doc/en/kernel-upgrade.xml

make oldconfig has caused lots of headaches, but it's an easy lazy way to upgrade your kernel. It's safe to upgrade to next revision with make oldconfig. Not so safe to upgrade to next version.

----------

## piedar

Hmm.  I asked because when I did an oldconfig after having copied in my .config, oldconfig didn't ask me any questions, but when I didn't copy it in, oldconfig asked me questions about new options, which I assume it should do.

EDIT: NVM, I guess it was asking me about the default config.  Thanks for your help.

----------

## Hu

Contrary to the advice in the document Jaglover linked, you can use make oldconfig to jump major revisions.  However, if you do so, you should be aware that there is the potential for it to generate a configuration that is not usable without some hand editing.  For example, if the configuration option for the driver for your hard disk controller is moved, oldconfig may generate a configuration that omits the driver entirely.  I believe this actually happened to people a few kernels back.  In my opinion, it is less work to make oldconfig ; make menuconfig and proofread the results than to try to manually recreate the new configuration each time, even if such manual configuration keeps the old version visible as a reference.

----------

## cach0rr0

 *Hu wrote:*   

>  In my opinion, it is less work to make oldconfig ; make menuconfig and proofread the results than to try to manually recreate the new configuration each time, even if such manual configuration keeps the old version visible as a reference.

 

this is my usual route. especially if it's a config I've taken considerable time tweaking and fiddling with. 

I normally update symlink, zcat /proc/config.gz > .config, make oldconfig and answer any questions, make menuconfig and make sure at the very least my disk drivers are in place

I've gone from .32=>.33=>.34 without any issues doing this. I did not, however, chance it going from .28=>.31

----------

## krinn

and there's another option:

copy your old .config in the new kernel as .config and run make, kernel will stops where it cannot decide how to set an option else it will silently remove bad options and re-set valid ones.

This way old options are set when valid, removed when invalid and ask when new.

So if your driver has been moved/renamed kernel will ask for it because

- old driver isn't valid anymore -> removed

- a newer driver is seen -> ask about it

Once done make menuconfig to re-set ones you miss (can be boring to answer all new options and you might just gave up with accepting kernel default choices)

i can say i never used make oldconfig, but i suppose the "make" with an old .config might just trigger a make oldconfig + make session in one shot as the result looks similar ?

----------

## Jaglover

 *Hu wrote:*   

> Contrary to the advice in the document Jaglover linked, you can use make oldconfig to jump major revisions.  However, if you do so, you should be aware that there is the potential for it to generate a configuration that is not usable without some hand editing.  For example, if the configuration option for the driver for your hard disk controller is moved, oldconfig may generate a configuration that omits the driver entirely.  I believe this actually happened to people a few kernels back.  In my opinion, it is less work to make oldconfig ; make menuconfig and proofread the results than to try to manually recreate the new configuration each time, even if such manual configuration keeps the old version visible as a reference.

 

The trouble here is not missing an important driver, you will notice that for sure. I used to do oldconfig all the time, and finally it borks your kernel config. You will get weird forced [y] options you do not need, for instance. Some options may go missing and not appear any more.

Finally I decided it is not worth it. I just copy over old .config and run make menuconfig as suggested in Gentoo docs.

----------

## Jaglover

 *Quote:*   

> i can say i never used make oldconfig, but i suppose the "make" with an old .config might just trigger a make oldconfig + make session in one shot as the result looks similar ?

 

Actually, many years ago I read docs in kernel.org and I remember the warning not to use make oldconfig to jump versions. So I doubt make menuconfig will silently run oldconfig.

----------

## krinn

 *Jaglover wrote:*   

> So I doubt make menuconfig will silently run oldconfig.

 

never said that  :Wink: 

but "make" will do (well, it was last time i check, and it might not really do a make oldconfig but it look like it)

----------

## Hu

 *Jaglover wrote:*   

> The trouble here is not missing an important driver, you will notice that for sure.

 Yes, eventually.  It can be aggravating to leave out a driver that is mandatory for a usable system, but not mandatory for starting (e.g. IPsec if you use an IPsec VPN).

 *Jaglover wrote:*   

> I used to do oldconfig all the time, and finally it borks your kernel config. You will get weird forced [y] options you do not need, for instance. Some options may go missing and not appear any more.

 Could you elaborate on any of these problems?  When did you abandon use of oldconfig?

 *Jaglover wrote:*   

> Actually, many years ago I read docs in kernel.org and I remember the warning not to use make oldconfig to jump versions. So I doubt make menuconfig will silently run oldconfig.

 Like the kernel itself, the configuration system is prone to change over time.  A quick search of current kernel sources shows no such warning in Documentation/.  If you can find it again, I would be interested to see the full warning.

----------

## Jaglover

Hu,

I have no hard evidence to support what I said. I haven't jumped a version with oldconfig for long time. Troubles I remember are from 2.2 and 2.4 era. It is possible with 2.6 problems are less severe. Although I remember a few years ago when SATA stuff was moved make oldconfig totally failed to produce working kernels. 

Anyhow, kernel being the most important part of our GNU/Linux I'd say it deserves good handling. I personally do not regret the time spent with menuconfig.  

Can't find the full warning, all I remember is it stated oldconfig target was never intended for moving between versions. Perhaps searching kernel mailing lists would give something.

----------

## bus_drivr

you can always 'diff' the resulting file to see what changed. make oldconfig does make changes sometimes so saving a backup of it before make oldconfig and diff the two files to see what changed. Not a great reading format though

----------

## tabanus

I've used "make oldconfig" to upgrade every kernel from about 2.6.20. Only ever had problems skipping a version (e.g. .20 -> .22). This is my kernel upgrade routine (adapted from a post elsewhere in these forums a long time ago)

```

eselect kernel list

eselect kernel set [#]

zcat /proc/config.gz > /usr/src/linux/.config

cd /usr/src/linux

make oldconfig

make menuconfig

make -j3 && make modules_install

mount /boot

mv /boot/bzImage.old /boot/bzImage.old.1

mv /boot/bzImage /boot/bzImage.old

cp arch/x86/boot/bzImage /boot

cp .config /boot/config-2.6.xx-gentoo-rx

umount /boot

module-rebuild rebuild
```

That way if I was to end up with a borked system, I can easily re-boot back into the old kernel (I have grub offer me which of the 3 kernels I keep in /boot) to sort it. When I have had problems, it's been because of a specific kernel bug rather than anything to do with the upgrade technique. If make oldconfig throws up something I'm really not sure about, I just Google it, before answering the question.

In the old days I used to use a fresh menuconfig each time, and be left with an unusable system because I missed some obscure setting or other.

----------

