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)
Code:
# 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:
# 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:
# 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:
# 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?
_________________
Do you hear the sound of inevitability?
With age, comes great grumpiness and that, was 20 years ago...
CertFP: becbbd161d5a5c31de3c45171b77bf710911db29 / d985d21f89fe2977b593c4d381a1a86802e62990d9328d893db76d59f9935244
Last edited by HeXiLeD on Thu Sep 03, 2015 12:51 pm; edited 2 times in total
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.
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.
_________________
Anyway it's all the same at the end...
Need help to get it working: "x-fi surround 5.1"
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.
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.
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:
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 ?
_________________
Do you hear the sound of inevitability?
With age, comes great grumpiness and that, was 20 years ago...
CertFP: becbbd161d5a5c31de3c45171b77bf710911db29 / d985d21f89fe2977b593c4d381a1a86802e62990d9328d893db76d59f9935244
cach0rr0
Bodhisattva
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.
_________________
Lost configuring your system?
dump lspci -n here
|
see Pappy's guide
|
Link Stash
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:
Code:
<*> xHCI HCD (USB 3.0) support (EXPERIMENTAL)
[ ] Debugging for the xHCI host controller
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 ?
_________________
Do you hear the sound of inevitability?
With age, comes great grumpiness and that, was 20 years ago...
CertFP: becbbd161d5a5c31de3c45171b77bf710911db29 / d985d21f89fe2977b593c4d381a1a86802e62990d9328d893db76d59f9935244
cach0rr0
Bodhisattva
Joined: 13 Nov 2008
Posts: 4123
Location: Houston, Republic of Texas
Posted: Mon May 10, 2010 1:18 am
Post subject:
│ 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.
_________________
Lost configuring your system?
dump lspci -n here
|
see Pappy's guide
|
Link Stash
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.
_________________
Anyway it's all the same at the end...
Need help to get it working: "x-fi surround 5.1"
- 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:
# 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
_________________
Do you hear the sound of inevitability?
With age, comes great grumpiness and that, was 20 years ago...
CertFP: becbbd161d5a5c31de3c45171b77bf710911db29 / d985d21f89fe2977b593c4d381a1a86802e62990d9328d893db76d59f9935244
Last edited by HeXiLeD on Mon May 10, 2010 9:05 pm; edited 1 time in total
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:
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:
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.
_________________
Anyway it's all the same at the end...
Need help to get it working: "x-fi surround 5.1"
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
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.
_________________
Do you hear the sound of inevitability?
With age, comes great grumpiness and that, was 20 years ago...
CertFP: becbbd161d5a5c31de3c45171b77bf710911db29 / d985d21f89fe2977b593c4d381a1a86802e62990d9328d893db76d59f9935244
