The following behaviour is not described in the official "Gentoo Linux Kernel Upgrade Guide" found here: http://www.gentoo.org/doc/en/kernel-upgrade.xml It seems that when you emerge new gentoo-sources, update the symlink and run "make menuconfig", the configuration program _automatically_ tries to find an old .config file and reuse it to ease the configuration. It searches at least in /boot/. I had the .config from an older kernel saved as /boot/config-2.6.13-gentoo-r5. When I emerged gentoo-sources 2.6.14-r2 and ran "make menuconfig", it automatically found the old settings and applied them. This functionality should be described in the above documentation. The next things should be added to "Gentoo Linux Kernel Upgrade Guide": 1. Encourage the user to always copy /usr/src/linux/.config to /boot/config-... after building the kernel image using the correct naming scheme. This copying is now described only in the "Gentoo Linux Handbook" in section 7, not in "Gentoo Linux Kernel Upgrade Guide" for some reason. 2. Describe that "make menuconfig" tries to find and reuse an old .config file. 3. Rewrite the section "10: Advanced: Using your old kernel .config to configure a new one" to reflect the above functionality and possible tell which method is more secure or recommended: this one, or using "make oldconfig" as described in the docs. 4. Mention this functionality briefly in "Gentoo Linux Handbook" in section "7. Configuring the Kernel". This automation doesn't probably work if /boot/ is not mounted during "make menuconfig". Haven't tested that, though. I also don't know if old .config files are searched somewhere else, like /usr/src/ ? I also don't know how they should be named correctly. The above name DID work. And what about mixing different kernel families, like gentoo-sources and vanilla kernels? Could that cause problems? I tested this only on x86, but I assume this applies to all platforms. Reproducible: Always Steps to Reproduce: 0.Mount /boot, if needed. 1."cd /usr/src/linux/" 2."cp .config /boot/config-" (append correct "old" kernel version here) 3.Emerge new gentoo-sources if present. 4.Update the symlink /usr/src/linux as described in the docs. 5."cd /usr/src/linux" 6."make menuconfig" Actual Results: You should now see your old settings automatically applied. Expected Results: This bug report is about docs, but the software should probably ask the user if he wants to reuse the old settings.
Bad idea for upgrading between anything else then revisions of the same kernel version, and even then you should use make oldconfig, not just load the old kernel config in menuconfig.
(In reply to comment #1) > Bad idea for upgrading between anything else then revisions of the same kernel > version, and even then you should use make oldconfig, not just load the old > kernel config in menuconfig. The problem here is that it does it automatically! It doesn't ask if user wants to reuse old settings but just does that. If you have a backup of old .config in /boot/, "make menuconfig" will reuse that. So either we should: 1. Update the docs. 2. Alter the functionality.
(In reply to comment #2) > The problem here is that it does it automatically! It doesn't ask if user wants > to reuse old settings but just does that. If you have a backup of old .config in > /boot/, "make menuconfig" will reuse that. So either we should: > 1. Update the docs. > 2. Alter the functionality. Eh? What about 3/ Don't copy old config to /usr/src/linux or /boot or wherever ?
> Eh? What about > > 3/ Don't copy old config to /usr/src/linux or /boot or wherever Well, then the next doc should be corrected: http://www.gentoo.org/doc/en/handbook/index.xml It says: "It is also wise to copy over your kernel configuration file to /boot, just in case" If a user follows that advice, he might (at least according to you) run into troubles because this undocumented (?) functionality. And if reusing old .config really causes problems, this is a major issue! I really don't know how this should be handled. I repeat: user is not asked, whether he likes to reuse the old config file, if one is found in /boot.
(In reply to comment #4) > I repeat: user is not asked, whether he likes to reuse the old config file, if > one is found in /boot. I'm sorry, but the behaviour you are describing does not exist here... Running make menuconfig definitely does not reuse config saved in /boot
CCing kernel, don't know if this is some new 2.6.14 feature or what, not reproducible here with 2.6.13 at all...
> I'm sorry, but the behaviour you are describing does not exist here... Running > make menuconfig definitely does not reuse config saved in /boot I tested a bit more. I really don't know what is the logic it is using for selecting old config files. To test it you shouldn't have any .config in /usr/src/linux. So remove those first (backup). Then run "make menuconfig" and exit immediately without saving. You should now see if it is using an older config file. Mine reads: ------- $ sudo make menuconfig scripts/kconfig/mconf arch/i386/Kconfig # # using defaults found in /boot/config-2.6.14-gentoo-r2 # Your kernel configuration changes were NOT saved. -------- I'm not the only one seeing this behaviour. See the relevant discussion here: http://forums.gentoo.org/viewtopic-t-401641-highlight-.html
(In reply to comment #3) > (In reply to comment #2) > > The problem here is that it does it automatically! It doesn't ask if user wants > > to reuse old settings but just does that. If you have a backup of old .config in > > /boot/, "make menuconfig" will reuse that. So either we should: > > > 1. Update the docs. > > 2. Alter the functionality. > > Eh? What about > > 3/ Don't copy old config to /usr/src/linux or /boot or wherever Considering chapter 10., I'd go that way, and I'd add a warning to let users know about this behaviour. (In reply to comment #6) > CCing kernel, don't know if this is some new 2.6.14 feature or what, not > reproducible here with 2.6.13 at all... Look at scripts/kconfig/confdata.c, the following files are considered in sequence: ".config", "/lib/modules/$UNAME_RELEASE/.config", "/etc/kernel-config", "/boot/config-$UNAME_RELEASE", "arch/$ARCH/defconfig";
(In reply to comment #8) > Look at scripts/kconfig/confdata.c, the following files are considered in sequence: > ".config", > "/lib/modules/$UNAME_RELEASE/.config", > "/etc/kernel-config", > "/boot/config-$UNAME_RELEASE", > "arch/$ARCH/defconfig"; Ah well, now I am able to reproduce this (tried with /etc/kernel-config and /boot/config-$UNAME_RELEASE)... Hmm, we might either add a warning or advise people to copy the current config somewhere else then to the locations quoted above in the handbook (http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=7 - code listing 17) to avoid unexpected results. I've had a bad experience with 'make oldconfig' or loading the .config from previous kernel versions in menuconfig, it's been producing strange things a couple of times and don't consider this feature to be safe. :/ kernel herd, any ideas?
Honestly, we don't recommend the user to just accept whatever setting "make menuconfig" presents. I believe it is easier for the user if the configuration resembles his previous one, even though it isn't perfect. What difference does it make that "make menuconfig" takes that configuration, or the default kernel configuration?
Maybe the docs should mention this functionality and describe the proper naming scheme AND 'make menuconfig' should ask the user if he wants to use a default configuration or a found configuration(s)? Or at least tell the user in the config screen which one it chose: default or old config.
I feel a combination of make oldconfig && make menuconfig should be enough for most. I don't particularly see any problen here?
OK, as for .config backup, I'd suggest to replace Code Listing 17 in http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=7 with [*] Kernel .config support [*] Enable access to .config through /proc/config.gz 1/ Solves the issue of make menuconfig automatically reusing the old kernel configuration (possibly unwanted and not-so-safe) 2/ Makes a nice backup as well ;) In the kernel upgrade guide, replacing Code Listing 10.1 with: zcat /proc/config.gz > /usr/src/linux/.config && make oldconfig Comments?
Well, there's no point in using /boot/config-foo files (IMHO) as `scripts/extract-ikconfig` from kernel directory should do the same thing with existing bzImage.
(In reply to comment #13) > [*] Kernel .config support > [*] Enable access to .config through /proc/config.gz > > 1/ Solves the issue of make menuconfig automatically reusing the old kernel > configuration (possibly unwanted and not-so-safe) > 2/ Makes a nice backup as well ;) I do not like using kernel memory to save data that is only going to be used once and that is already available in a file
(In reply to comment #15) > I do not like using kernel memory to save data that is only going to be used > once and that is already available in a file So don't use it, perhaps? /proc/config.gz is exactly 8155 B here, what a waste of memory space. ;p Don't see what's wrong with using in-kernel features to backup kernel configuration. I don't like kernel recycling this information automatically in make menuconfig, which may cause strange results, that's what this bug is about.
(In reply to comment #10) > Honestly, we don't recommend the user to just accept whatever setting "make > menuconfig" presents. I believe it is easier for the user if the configuration > resembles his previous one, even though it isn't perfect. > > What difference does it make that "make menuconfig" takes that configuration, or > the default kernel configuration? The difference is that on the first kernel upgrade, current settings are automatically used, but not on the second upgrade, and there is nothing in the docs that can explain this discrepancy. Consider the following scenario: Joe wants to try Gentoo, downloads the CD, follows the handbook, ends up with a perfect distro using kernel-2.6.23. Joe is happy. kernel 2.6.24 is released. Joe follows the kernel-upgrade guide to know what to do. Joe runs `make menuconfig` Joe checks several config pages and he notices that all his settings have been automatically transfered. Joe thinks 'Cool, well done, easy' Joe completes his upgrade by following the doc, reboots, and everything works. Joe is a happy bunny. Two months later, kernel 2.6.25 comes out. Joe remembers the guide, follows it again because it's only his second upgrade and he does not know it by heart. Joe does remember that `make menuconfig` loads his settings automatically. Joe completes his upgrade, reboots, and nothing works. I shan't even mention how Joe would be pissed off had he been overconfident and replaced his previous entry in his bootloader config instead of adding a new one. Joe searches high & low and eventually finds out that the 2nd `make menuconfig` used the default config instead of his current settings. Joe is not a happy bunny anymore because the doc did not explain anything about that. PS: back to docs-team until we know how to eat at Joe's
(In reply to comment #16) > (In reply to comment #15) > > I do not like using kernel memory to save data that is only going to be used > > once and that is already available in a file > > So don't use it, perhaps? /proc/config.gz is exactly 8155 B here, what a waste Still a waste by your own words. > I don't like kernel recycling this information > automatically in make menuconfig, which may cause strange results, that's what > this bug is about. Then take it to lkml, we don't control that code
(In reply to comment #18) > > I don't like kernel recycling this information > > automatically in make menuconfig, which may cause strange results, that's what > > this bug is about. > > Then take it to lkml, we don't control that code No, but we are making unsafe recommendations in our docs wrt backing up the kernel config, so we might perhaps fix it, instead of focusing on debate about wasting a couple of kilobytes in memory? Saying that I don't like wasting another 32384 B of disk space to save data that is only going to be used once and that is already available in a file would be of about same importance and relevance here. Anyway, if you don't like it that much then just drop the suggestion, I could care less. Just don't advise people to backup the thing to /boot/config-$UNAME_RELEASE.
Sven raised a good point: Is it fundamentally more dangerous to use previous .config as a starting point for configuration rather than using some kernel default settings? I think both can lead to equally unusable system in the worst case scenario when the user doesn't go through the settings. And in the best case scenario the old .config most likely works flawlessly without editing. In this light I think this functionality should just be documented properly so the user knows what is happening. And thus there is probably no need to drop the recommendation of "cp .config /boot/" in the Handbook. And we even save 8155 bytes of precious kernel size :)
But the handbook doesn't say "cp .config /boot/" It says: "cp .config /boot/config-2.6.11-gentoo-r3" Due to the filename, this config will only be reused on a kernel which has a version of 2.6.11-gentoo-r3 and there is no danger of reusing old settings there.
(In reply to comment #21) > But the handbook doesn't say "cp .config /boot/" > > It says: "cp .config /boot/config-2.6.11-gentoo-r3" Yes, I meant that. I'm a lazy typer... > Due to the filename, this config will only be reused on a kernel which has a > version of 2.6.11-gentoo-r3 and there is no danger of reusing old settings there. I'm quite positive, that all my settings were also copied, when I upgraded from 2.6.13-r5 to 2.6.14-r2. Can't confirm that now, though.
(In reply to comment #21) > But the handbook doesn't say "cp .config /boot/" > > It says: "cp .config /boot/config-2.6.11-gentoo-r3" > > Due to the filename, this config will only be reused on a kernel which has a > version of 2.6.11-gentoo-r3 and there is no danger of reusing old settings there. That's where the discrepancy is: When first upgrading to e.g. 2.6.12-gentoo-r5, settings saved in /boot/config-2.6.11-gentoo-r3 will be reused (/boot/config-`uname -r`) but when upgrading later to e.g. linux-2.6.13-gentoo-r5, defconfig will be used. This behaviour is not described.
(In reply to comment #21) > But the handbook doesn't say "cp .config /boot/" > > It says: "cp .config /boot/config-2.6.11-gentoo-r3" > > Due to the filename, this config will only be reused on a kernel which has a > version of 2.6.11-gentoo-r3 and there is no danger of reusing old settings there. No. It will be reused if that version matches what 'uname -a' has to say about currently running kernel version. So, if you are running 2.6.8 and want to upgrade to 2.6.14, it will happily recycle that 2.6.8 config. Don't think this would be even remotely safe.
Yeah, sorry, just noticed that myself. I'm not convinced that its a major problem as the kernel upgrade guide asks you to mount /boot after compiling everything, so theres no chance for reuse. (This is also why I've never seen this behaviour before, and I imagine I'm in the same boat as most people) Either way the discrepency in the documentation should be solved. I suggest not copying it to /boot, or using a different naming scheme if you'd still like to encourage a backup procedure.
(In reply to comment #25) > Yeah, sorry, just noticed that myself. > > I'm not convinced that its a major problem as the kernel upgrade guide asks you > to mount /boot after compiling everything, so theres no chance for reuse. The guide also does not mention it works only if the following conditions are both met: 1) You must have followed the handbook to the t and used the very same partitioning scheme 2) You must be using an architecture that does recommend a separate /boot partition > Either way the discrepency in the documentation should be solved. I suggest not > copying it to /boot, or using a different naming scheme if you'd still like to > encourage a backup procedure. Agreed. Why not add `make defconfig` to make sure users do start with the default config and refer them to ch10 if they really want to reuse their .config?
Well, i'm with Jakub in this. Why don't use the in-kernel feature to save the config file?! If the user really wants to use the old kernel config, he'll have to copy it himself from /proc/config.gz, and afaik the Kconfig utils don't check there. Besides, if this method is used, the user will always start with a defconfig when building a new kernel. (unless he zcat /proc/config.gz > /usr/src/linux/.config)
Just FYI: `make install` in the kernel tree will also copy the .config to /boot/config-$UNAME_RELEASE (if the user has debianutils installed) - it has done this as far back as I can remember, and I consider it a nice feature. Why not just alert the user to the fact that `make *config` will look for the .config file in these places, and advice them to manually copy their previous .config file to the new kernel source and run `make oldconfig` when upgrading a kernel?
(In reply to comment #4) > > Eh? What about > > > > 3/ Don't copy old config to /usr/src/linux or /boot or wherever > > Well, then the next doc should be corrected: > > http://www.gentoo.org/doc/en/handbook/index.xml > > It says: "It is also wise to copy over your kernel configuration file to /boot, > just in case" > > If a user follows that advice, he might (at least according to you) run into > troubles because this undocumented (?) functionality. And if reusing old .config > really causes problems, this is a major issue! I really don't know how this > should be handled. > > I repeat: user is not asked, whether he likes to reuse the old config file, if > one is found in /boot. This is no longer the case. See bug #118031 -- the "copy oldconfig" instructions have been removed from all the handbooks. Is this bug still valid in light of the changes made?
It looks like this issue doesn't exists anymore. Thank you for updating the documents!
