# Kernel method: make menuconfig vs make oldconfig [SOLVED]

## HeXiLeD

Question for the experts (preferably)

What method is should actually be used and why.

(the kernel used was vanilla-sources)

Recently while upgrading from 2.6.30.3 to 2.6.32.9 and 2.6.34-rc6 (all vanilla sources) i found myself in a dilemma caused by a few problems.

I am a manual kernel user; always been and will. I like to trim and optimize the kernel to the maximum possible in order to load exactly only what i need  and every time i upgrade to a new kernel i will take as much time as necessary to compile the new one from scratch.

I have always preferred not to use make oldconfig until this last time. In the past years i always opened the old kernel with make menuconfig in one terminal and at the same time starting the new kernel on another terminal with make menuconfig and copying all the selected options thoroughly.

I have read a few topics and pages about this; including Gentoo Linux Kernel Upgrade Guide and i agree with what is said there:

 *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. However, it is not appropriate to use it in the example used throughout this document: upgrading from 2.6.8 to 2.6.9. Too many changes between the official releases, and the method described below does not display enough context to the user, often resulting in the user running into problems because they disabled options that they really didn't want to.

 .

However i have currently encountered a problem that was only solved by make oldconfig.

This problem was weird and mostly to do with the mouse support and sata /dev/*names*

While the /dev/*names* were not a big issue for me; the mouse was.

When i moved to 2.6.32.9 and above making sure that i had the same kernel support as before; when i rebooted the mouse did not work.

/dev/mice and /dev/psaux existed; and i was able to use the USB mouse but NOT the regular working PS/2 mouse.

There were no errors anywhere as well as any output.

Sata dev names changed from /dev/sdb* /dev/sdd* /dev/sde* /dev/sdf* to /dev/sdg* /dev/sdh* /dev/sdi* /dev/sdj* 

(basically they jumped 4 letters ahead)

Here is an example of 4 kernels and their ps/2 mice support as well as the compile method.

2.6.30.3 (old kernel - rock solid - no mice or sata issues all hardware works)

```
 # cat config-2.6.30.3 | grep PS2

CONFIG_MOUSE_PS2=y

CONFIG_MOUSE_PS2_ALPS=y

CONFIG_MOUSE_PS2_LOGIPS2PP=y

CONFIG_MOUSE_PS2_SYNAPTICS=y

CONFIG_MOUSE_PS2_LIFEBOOK=y

CONFIG_MOUSE_PS2_TRACKPOINT=y

# CONFIG_MOUSE_PS2_ELANTECH is not set

# CONFIG_MOUSE_PS2_TOUCHKIT is not set

# CONFIG_SERIO_PCIPS2 is not set

CONFIG_SERIO_LIBPS2=y
```

2.6.32.9 made by: make menuconfig after emerged. (oldconfig not used and the ps/2 mouse did not work and sata went /dev/* changed)

```
# cat config-2.6.32.9 | grep PS2

CONFIG_MOUSE_PS2=y

CONFIG_MOUSE_PS2_ALPS=y

CONFIG_MOUSE_PS2_LOGIPS2PP=y

CONFIG_MOUSE_PS2_SYNAPTICS=y

CONFIG_MOUSE_PS2_LIFEBOOK=y

CONFIG_MOUSE_PS2_TRACKPOINT=y

# CONFIG_MOUSE_PS2_ELANTECH is not set

# CONFIG_MOUSE_PS2_SENTELIC is not set

# CONFIG_MOUSE_PS2_TOUCHKIT is not set

# CONFIG_SERIO_PCIPS2 is not set

CONFIG_SERIO_LIBPS2=y
```

2.6.34-rc6 made by: make menuconfig after emerged. (oldconfig not used and the ps/2 mouse did not work and sata went /dev/* changed)

```
 # cat config-2.6.34-rc6 | grep PS2

CONFIG_MOUSE_PS2=y

CONFIG_MOUSE_PS2_ALPS=y

CONFIG_MOUSE_PS2_LOGIPS2PP=y

CONFIG_MOUSE_PS2_SYNAPTICS=y

CONFIG_MOUSE_PS2_LIFEBOOK=y

CONFIG_MOUSE_PS2_TRACKPOINT=y

# CONFIG_MOUSE_PS2_ELANTECH is not set

# CONFIG_MOUSE_PS2_SENTELIC is not set

# CONFIG_MOUSE_PS2_TOUCHKIT is not set

# CONFIG_SERIO_PCIPS2 is not set

CONFIG_SERIO_LIBPS2=y

# CONFIG_SERIO_ALTERA_PS2 is not set
```

2.6.32.9 made by: make oldconfig after emerged. (2.6.30.3 oldconfig was used and the ps/2 and sata worked perfectly)

```
# cat /usr/src/linux/.config | grep PS2

CONFIG_MOUSE_PS2=y

CONFIG_MOUSE_PS2_ALPS=y

CONFIG_MOUSE_PS2_LOGIPS2PP=y

CONFIG_MOUSE_PS2_SYNAPTICS=y

CONFIG_MOUSE_PS2_LIFEBOOK=y

CONFIG_MOUSE_PS2_TRACKPOINT=y

# CONFIG_MOUSE_PS2_ELANTECH is not set

# CONFIG_MOUSE_PS2_SENTELIC is not set

# CONFIG_MOUSE_PS2_TOUCHKIT is not set

# CONFIG_SERIO_PCIPS2 is not set

CONFIG_SERIO_LIBPS2=y
```

In these examples the PS/2 support is the same as it was for for the sata drives and this puzzles me about why this problem happened. I rebooted a few times and played with the kernels and got to no conclusion.

Since the .config file is basically a text file with options i am now questioning what method should be used next time. 

While choosing make oldconfig is not recommended and it is uncomfortable for me due to documented facts and documentation i now i have to question this.

What should i do in the next upgrade to ensure that i have a flawless kernel compile without any flaky choices or configurations.

Whats your input, advice and experience compiling kernels and their outcome performance and stability?

----------

## gentoo_dude

This is what I usually do, even though I use the gentoo-sources, and genkernel, but I still like to customize my kernel:

1. copy the current kernel .config in the new kernel sources folder, this way the current settings are passed to the new kernel

2. point the linux symbolic link to the new kernel sources folder.

3. run genekernel with options --no-clean --menuconfig; genkernel opens the .config file in the /usr/src/linux folder, and opens menuconfig for kernel configuration

4. customize the kernel the way I want with the options that I had working in the previous one already selected.  I usually double check those that are correct, and see what is new.

5. save the kernel config file and let genkernel finishing compiling my kernel.

6. restart and boot from the new kernel.

----------

## keenblade

Actually firstly run "make oldconfig", so your old settings are migrated and only new or changed options are presented to you to select. Then to make sure everything is ok, run "make menuconfig" or "make xconfig". make oldconfig is very clever. Even it can do it's job between different versions of kernel. I have never run into a problem with this way.

----------

## Mousee

 *HeXiLeD wrote:*   

> 
> 
> While choosing make oldconfig is not recommended and it is uncomfortable for me due to documented facts and documentation i now i have to question this.

 

I think you're misunderstanding what the Gentoo Documentation is warning you about - and it makes sense as it's not specifically stated in the guide as to which method of making "your old kernel .config to configure a new one" they're referring to. What is stated in the guide is, however, correct.

If you're upgrading from, and I'm making these versions up just as an example, say gentoo-sources-2.6.33-r1 to gentoo-sources-2.6.33-r6 then using "make menuconfig" should, in almost all cases, be perfectly safe and acceptable. In some cases even going a revision up (ie. 2.6.33 to 2.6.34) works, as has been my experience in my "noob" days when I didn't understand the need for using "make oldconfig".  Anyways - as stated in the Gentoo Documentation that you quoted, using "make oldconfig" any time you upgrade to a new version, whether it be major or minor, is essential to a safe and functional kernel configuration. The part of the documentation that's confusing, which is warning you about being "unsafe", is using "make menuconfig" to update rather than "make oldconfig". 

So to conclude - using "make menuconfig" is safe to use when performing revision specific upgrades (as per my example) only and "make oldconfig" should be used in all other cases.

----------

## HeXiLeD

 *Mousee wrote:*   

>  *HeXiLeD wrote:*   
> 
> While choosing make oldconfig is not recommended and it is uncomfortable for me due to documented facts and documentation i now i have to question this. 
> 
> I think you're misunderstanding what the Gentoo Documentation is warning you about - and it makes sense as it's not specifically stated in the guide as to which method of making "your old kernel .config to configure a new one" they're referring to. What is stated in the guide is, however, correct.
> ...

 

I didn't misunderstand. It is pretty straight forward what it is said in gentoo documentation:

 *Mousee wrote:*   

> If you're upgrading from, and I'm making these versions up just as an example, say gentoo-sources-2.6.33-r1 to gentoo-sources-2.6.33-r6 then using "make menuconfig" should, in almost all cases, be perfectly safe and acceptable

 

That is what we all know. makeconfig It is what is recommended. That is not the issue about what i posted. It is the opposite.

From gentoo documentation.

 *Quote:*   

> 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.

 

This means using the oldconfig by doing "make oldconfig" and not "make menuconfig"

In my case; this "unsafe way"proved to be more useful than make menuconfig and i changed from 2.6.30.3 to 2.6.34-r6 which is a big jump for the acceptable oldconfig method.

Now another question rises:

How safe & clean is to make oldconfig first and then make menuconfig right after it ?

Is this safe even if we are jumping from something like 2.6.20 to 2.6.30 ?

----------

## cach0rr0

 *keenblade wrote:*   

> Actually firstly run "make oldconfig", so your old settings are migrated and only new or changed options are presented to you to select. Then to make sure everything is ok, run "make menuconfig" or "make xconfig". make oldconfig is very clever. Even it can do it's job between different versions of kernel. I have never run into a problem with this way.

 

++

This is the route I always go. Fire off `make oldconfig`, sort out any discrepancies, follow it up with `make menuconfig` to review.

----------

## HeXiLeD

 *cach0rr0 wrote:*   

>  *keenblade wrote:*   Actually firstly run "make oldconfig", so your old settings are migrated and only new or changed options are presented to you to select. Then to make sure everything is ok, run "make menuconfig" or "make xconfig". make oldconfig is very clever. Even it can do it's job between different versions of kernel. I have never run into a problem with this way. 
> 
> ++
> 
> This is the route I always go. Fire off `make oldconfig`, sort out any discrepancies, follow it up with `make menuconfig` to review.

 

Here is another update about that method (which was the one i had to use for me as explained in this topic)

I just compiled another 2.6.32.9 kernel in another 64bit box. The first thing i did was mrproper and then make menuconfig; so there was no old config done in any way.

Then i went to check the new kernel make menuconfig and when compared do my 2.6.32.9 kernel made with oldconfig + make menuconfig i found that i did not have some menu options using oldconfig method; that i have in the new kernel that i just compiled using mrproper + make menuconfig without using oldconfig

For example; under USB drivers support in this new kernel i have:

```
<*>     xHCI HCD (USB 3.0) support (EXPERIMENTAL)                                                       

     [ ]       Debugging for the xHCI host controller
```

Which for the same kernel version on another box; but using oldconfig i don't see it or have it.

In the past this was what made me not wanting to use make oldconfig and which is pretty much in accordance with what gentoo kernel upgrade documentation says about using oldconfig not being a safe method. For some reason; making oldconfig seems to "skip"or "not see some configuration details.

From what i see this proves that making oldconfig is in fact not very safe or good. 

Have you guys experienced this kind of problem too ?

Is there a way of making oldconfig and still have all the new kernel options displayed ? 

Maybe something like make oldconfig + mrproper + make menuconfig ?

----------

## cach0rr0

most likely going to be dependencies/blockers, if i were to hazard a guess. 

in this case

```

 Symbol: USB_XHCI_HCD [=n]

  │ Prompt: xHCI HCD (USB 3.0) support (EXPERIMENTAL)

  │   Defined at drivers/usb/host/Kconfig:20

  │   Depends on: USB_SUPPORT [=y] && USB [=y] && PCI [=y] && EXPERIMENTAL [=y]

  │   Location:

  │     -> Device Drivers

  │       -> USB support (USB_SUPPORT [=y])

  │         -> Support for Host-side USB (USB [=y])

```

namely the dependency there. If your old kernel didn't have say, the EXPERIMENTAL symbol ticked, that would be carried forward; set all of those 4 options that are dependencies, and see if USB_XHCI_HCD doesn't show up.

----------

## keenblade

 *cach0rr0 wrote:*   

> most likely going to be dependencies/blockers, if i were to hazard a guess. 
> 
> in this case
> 
> ```
> ...

 

HeXiLeD, as cach0rr0 pointed, you have to choose usb support y, usb y or m, pci y, and experimental y.

Probably you have missed what the "make oldconfig" suggested or asked for some of these new options which does not exist in your old .config file. So it become disabled since you did not chose y or m to oldconfig script. That means make oldconfig did its job perfectly. And did not add any unnecessary options and so did not make your kernel full off unnecessary crap. So the solution is; after using "make oldconfig" use "make xconfig" since it gives an option (Show all Options). Then you can see what options are disabled or not shown normally.

Also you maybe interested in the "make localmodconfig" which gathers information from your running system and creates a .config dynamically from your hardware. And don't forget to plug external devices before running it, so it can analyze them and add support to your kernel. But you will always need to make your own optimizations after it. Since you know what you want better then it.

----------

## HeXiLeD

 *keenblade wrote:*   

> ...So the solution is; after using "make oldconfig" use "make xconfig" since it gives an option (Show all Options).

 

Good point. I forgot about that. Or make gconfig (gtk)( and so i did). And you are 100% correct. It does display what was not selected from the previous config.

So it is fair enough to say that doing # make oldconfig && make gconfig will be safe to do (safer than make oldconfig + make menuconfig)  since it will not only reuse the old settings as it will also display what was not previously selected and it it now available.

2 questions:

- Is there a way to have this display (show all) method with the ncurses make menuconfig showing all the new options ? 

- while make gconfig shows me the "hidden"new drivers; it does not allow me to select them to include them in the new compile. ( it is greyed out) What is the solution ?

```
# make help

Cleaning targets:

  clean           - Remove most generated files but keep the config and

                    enough build support to build external modules

  mrproper        - Remove all generated files + config + various backup files

  distclean       - mrproper + remove editor backup and patch files

Configuration targets:

  config          - Update current config utilising a line-oriented program

  menuconfig      - Update current config utilising a menu based program

  xconfig         - Update current config utilising a QT based front-end

  gconfig         - Update current config utilising a GTK based front-end

  oldconfig       - Update current config utilising a provided .config as base

  localmodconfig  - Update current config disabling modules not loaded

  localyesconfig  - Update current config converting local mods to core

  silentoldconfig - Same as oldconfig, but quietly, additionally update deps

  randconfig      - New config with random answer to all options

  defconfig       - New config with default answer to all options

  allmodconfig    - New config selecting modules when possible

  allyesconfig    - New config where all options are accepted with yes

  allnoconfig     - New config where all options are answered with no

```

----------

## keenblade

 *HeXiLeD wrote:*   

> ...And you are 100% correct. It does display what was not selected from the previous config.
> 
> 

 

Yes, sure.

 *Quote:*   

> 
> 
> - Is there a way to have this display (show all) method with the ncurses make menuconfig showing all the new options ? 
> 
> - while make gconfig shows me the "hidden"new drivers; it does not allow me to select them to include them in the new compile. What is the solution ?

 

1- Don't know.

2- You have to satisfy the dependencies of the option. Just look at the info window like this:

```

Depends on: USB_SUPPORT [=y] && USB [=y] && PCI [=y] && EXPERIMENTAL [=y] 

```

When you enable the options in the "Depends on" line in kernel, you can select the desired option.

----------

## HeXiLeD

Once again  the same problem described here happens. This time upgrading from vanilla-sources-2.6.32.9 to -2.6.37 and -2.6.37.2.

This time using make oldconfig and the issue happened in a desktop and netbook.

On the netbook i lost the double tap touchpad funtion which does the same as a mouse left click.

On the desktop i lost the PS/2 mouse but usb mouse works. Also on the desktop my hard drives letters were changed except where the OS is installed and sometimes /dev/sdb1 jumps from /dev/sdb1  to /dev/sdf1.

Both computers have:

```
/dev/input/mouse0

/dev/psaux

```

```
 # cat /boot/config-2.6.37.2 | grep PS2

CONFIG_MOUSE_PS2=y

CONFIG_MOUSE_PS2_ALPS=y

CONFIG_MOUSE_PS2_LOGIPS2PP=y

CONFIG_MOUSE_PS2_SYNAPTICS=y

CONFIG_MOUSE_PS2_LIFEBOOK=y
```

```
CONFIG_MOUSE_PS2_ELANTECH=y //for the netbook
```

My fstab entries have double entries just in case like this example:

```
/dev/sdb1               /home           ext3            noatime                  0 1

/dev/sdf1               /home           ext3            noatime                  0 1
```

At boot at least the system will mount the one it detects. 

Udev version is 151-r4 .

This issue still remains. The only thing that changed now was the kernel version and the fact that is also happening on my netbook.

No idea why this happens or even how to solve it. I have rm -rf /dev/* but at boot the problem persists.

----------

## Odysseus

Let me preface my comments to this thread by saying that I'm not an IT pro, but just a long-time hobbyist who's been using Linux since the mid '90s.

That said, I have a routine for rebuilding kernels that has never failed me that may resolve your issues. Whenever I build a kernel from new sources or rebuild one from existing sources I follow these steps:

1) As my normal user I cd into the source directory

```
 cd /usr/src/linux
```

2) Then I make menu menuconfig using sudo: 

```
 sudo make menuconfig
```

3) Then I compile the kernel, modules, install them, then copy the kernel, config and create a system map in /boot with this:

```
 sudo make && sudo make modules_install && sudo make install
```

When finished, your new kernel, config and system map will reside in /boot. Now whenever you "make menuconfig" in a new kernel source, the choices that are still valid that were made from the previous kernel are migrated over automatically, and choices that are no longer valid are ignored, as the script reads the old config file from /boot.

A big advantage from doing it this way is that if you experiment with new settings with the same kernel source and find you have an issue it's easy to recover from, as the "make install" script automatically copies and renames the existing kernel, config, and system map from the same source to vmlinuz-2.6.xx.old, config-2.6.xx.old, and System.map-2.6.xx.old (xx in these represent the kernel version). In the event of a disaster, all one has to do is rename the ".old" files by removing the ".old" and you're back up and running again.

Another advantage is that if something has changed in between kernels that makes the previous configuration no longer valid when exiting "make menuconfig" warnings will appear pointing to the issues in your configuration. Then all you have to do is troubleshoot the warnings prior to building or rebuilding the kernel. These warnings have saved my bacon on more than one occasion, before going off and wasting time building an unusable kernel.

Using this method has served me well for many years and literally hundreds of kernel reconfigurations and updates without ever giving me a problem like mentioned in these posts.

I hope this helps.

Ciao

----------

