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:

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)

Code: Select all

 # 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)

Code: Select all

# 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)

Code: Select all

 # 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)

Code: Select all

# 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]

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]

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.

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

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.

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]

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]

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:

Code: Select all

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

Code: Select all

 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]

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

in this case

Code: Select all

 Symbol: USB_XHCI_HCD [=n]
  │   Depends on: USB_SUPPORT [=y] && USB [=y] && PCI [=y] && EXPERIMENTAL [=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.

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]

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

Code: Select all

# 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]

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

Yes, sure.

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

Code: Select all

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:

Code: Select all

/dev/input/mouse0
/dev/psaux

Code: Select all

 # 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

Code: Select all

CONFIG_MOUSE_PS2_ELANTECH=y //for the netbook

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

Code: Select all

/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

Code: Select all

 cd /usr/src/linux

2) Then I make menu menuconfig using sudo:

Code: Select all

 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:

Code: Select all

 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