make oldconfig alternative for major kernel upgrades

[Section_8]

I have been upgrading kernels for many years, using make oldconfig to migrate .config to the new kernel. This is fine for most upgrades, but for upgrading to a new release, make oldconfig can be very tedious, answering all of the many questions. I have tentatively settled on the following procedure as an alternative to make oldconfig, for major kernel upgrades, to address this:

1 - Copy the old .config to /usr/src/linux
2 - make helpnewconfig > whatever.txt - saves off all "new" config options and help text.
3 - make olddefconfig - default all new config settings.
4 - make menuconfig, browse the output from step 2, change settings from defaults if needed.

I am still experimenting with this, trying to decide if this can introduce problems, or at least more problems than make oldconfig. One thing I am not absolutely sure about, is does helpnewconfig output the same settings that make oldconfig queries?

[pietinger]

This sounds very interesting (I like new ideas) ... but I dont understand where is the time advantage ... because you have to read your "whatever.txt" the same as you have to read all queries when doing "make oldconfig" (and as you already mentionend, it should be the same text).

Okay, you can print "whatever.txt" and do the reading offline ... one plus point

Please report your further investigations - I like to know all kernel things

[CaptainBlood]

It happened many times here to make an erroneous select at oldconfig.
Hence painfully restarting the whole process over again.

Step 2 may help to set things right more easily; nice tip

The rest for the procedure could fit for defconfig oriented kernel.
This is not the case here.

I'd expect same result when applying same selection set to both ways.

I'm still suspicious about oldconfig, I have a feeling it may introduces implicit setting activation(s).
So I scrutinize .config files from time to time, because of reduced kernel policy: anything that is not required as dependency, or from user pov should be removed. Because of some long time existing option(s) to remain undocumented until now, I remain not fully confident in my .config agyrt all these years. But that's another story.

Thks 4 ur attention, interest & support.

[Section_8]

This sounds very interesting (I like new ideas) ... but I dont understand where is the time advantage ... because you have to read your "whatever.txt" the same as you have to read all queries when doing "make oldconfig" (and as you already mentionend, it should be the same text).

I think make oldconfig for the kernel upgrade I did recently, from 5.15 to 6.1.12, required answering about 100 config questions. I think just reading the output of helpnewconfig, and then examining closer and changing the few settings I care about, would be easier than all those make oldconfig questions. One of the reasons I dread those really big oldconfig sessions is that I don't know how far I am from the end of it as I'm answering questions.

[pietinger]

[...] One of the reasons I dread those really big oldconfig sessions is that I don't know how far I am from the end of it as I'm answering questions.

Yes, I understand this completely. Of course you have to do this major upgrade only once in approximately two years ...

I have done my job at the end of december (5.15.82 -> 6.1.1) ... and the outcome was:
Only 11 steps have been worth for mentioning - see my (german) post: viewtopic-p-8766427.html#8766427

[pingtoo]

[...] One of the reasons I dread those really big oldconfig sessions is that I don't know how far I am from the end of it as I'm answering questions.

Yes, I understand this completely. Of course you have to do this major upgrade only once in approximately two years ...

I have done my job at the end of december (5.15.82 -> 6.1.1) ... and the outcome was:
Only 11 steps have been worth for mentioning - see my (german) post: viewtopic-p-8766427.html#8766427

pietinger,

I wonder would it have helped if you use "make savedefconfig"? if you have a "./defconfig" having all the key configs that you care about will the process reduce to much simpler?

I don't know much of kernel configuration. since I believe if not break don't fix it. I don't change system very offen, so I only keep track things I deem important during boot for kernel.

[pietinger]

I wonder would it have helped if you use "make savedefconfig"? if you have a "./defconfig" having all the key configs that you care about will the process reduce to much simpler?

I don't know much of kernel configuration. since I believe if not break don't fix it. I don't change system very offen, so I only keep track things I deem important during boot for kernel.

pingtoo,

I am sorry, I dont understand what you mean. I have done what is always necessary if you upgrade to a new kernel version - and what PO did also; PO only "found a new way" to do so. Maybe you know this already; but I have done a "make oldconfig" according to (my own) CheatSheat:
https://wiki.gentoo.org/wiki/User:Pieti ... eat_Sheets
Here is also explained what a "make oldconfig" does (this chapter I have copied from a post from @Neddy )

[pjp]

1 - Copy the old .config to /usr/src/linux
2 - make helpnewconfig > whatever.txt - saves off all "new" config options and help text.
3 - make olddefconfig - default all new config settings.
4 - make menuconfig, browse the output from step 2, change settings from defaults if needed.

Interesting, I'll have to try this for my next upgrade.

Does anyone know if there is a way to answer no to all questions about new hardware? That would go a long way toward reducing the how-long-is-this-going-to-take factor.

[pingtoo]

I wonder would it have helped if you use "make savedefconfig"? if you have a "./defconfig" having all the key configs that you care about will the process reduce to much simpler?

I don't know much of kernel configuration. since I believe if not break don't fix it. I don't change system very offen, so I only keep track things I deem important during boot for kernel.

pingtoo,

I am sorry, I dont understand what you mean. I have done what is always necessary if you upgrade to a new kernel version - and what PO did also; PO only "found a new way" to do so. Maybe you know this already; but I have done a "make oldconfig" according to (my own) CheatSheat:
https://wiki.gentoo.org/wiki/User:Pieti ... eat_Sheets
Here is also explained what a "make oldconfig" does (this chapter I have copied from a post from @Neddy )

"savedefconfig" is a concept used a lot in embedded system build process. I think sys-kernel/gentoo-kernel USE flag "savedconfig" use same technique somehow.

For Linux kernel, in the source code tree, run "make savedefconfig" after you finish curate (i.e. after make menuconfig) your kernel configuration. it will create a ./defconfig file which is a minimal of the .config. You may review the ./defconfig and further reduce configure options to only have key configuration options for your hardware and software need.

Once you have the "defconfig" you can use it to apply for the next kernel version. This way you can be sure your very important configurations was kept for all new kernel generation.

The usual steps for apply "defconfig" to new kernel tree as follow,

1. cd /usr/src/linux-my-next-version
2. make mrproper or cp ../linux-my-current-version/.config .config
3. cp "defconfig" ./defconfig # "defconfig" mean you have it saved in some place for long term keep.
4. scripts/kconfig/merge_config.sh defconfig
5. make olddefconfig # give all the new symbols to there default value
6. make # Do whatever you generally do for building linux kernel

The "scripts/kconfig/merge_config.sh" can take more than one "defconfig". So it is possible to separate your previously saved "defconfig" file in to multiple files and each file may be target to kernel key configurations that is required for certain software or hardware, for example sound subsystem

[pietinger]

pingtoo,

thank you very much for your explanation ! (sorry, I knew this already; but it is helpful for all others)

The crucial with new versions is NOT to carry over your old settings; it is the question: What is new ? ... and shall I take the (new) defaults or shall I change some of them ?

For this you have only "make oldconfig" or "make listnewconfig" or "make helpnewconfig". (Or you read all patches which make the new kernel version )

[pietinger]

Does anyone know if there is a way to answer no to all questions about new hardware?

AFAIK there is no way. You can only say no to ALL NEW options with "make allnoconfig" (I really DONT recommend because you have some new options which defaults to yes for a good reason).

If you want some fun you can use also "make randconfig"

(see more in "make help").

[Goverp]

...
I think make oldconfig for the kernel upgrade I did recently, from 5.15 to 6.1.12, required answering about 100 config questions. I think just reading the output of helpnewconfig, and then examining closer and changing the few settings I care about, would be easier than all those make oldconfig questions. One of the reasons I dread those really big oldconfig sessions is that I don't know how far I am from the end of it as I'm answering questions.

That's the price of stability.
I've taken to running with vanilla sources (actually, it's stable from git managed in user-space, not portage, but the results are the same). Approx weekly updates, but only a few questions (mostly new hardware drivers which, of course, my box has no need for) at change of V.R, and rarely any at V.R.M. For example, from 6.0 to 6.1, something like 20 questions, of which only about 5 require any thought, and about 2 questions in total from 6.1.1 to 6.1.12.

[Syl20]

Of course you have to do this major upgrade only once in approximately two years ...

... by computer. For some of us, that may represent lots of time. Especially with recycled machines, while each one have its own characteristics.

I often miss the "default-to-yes" questions about the new network cards. And I often have to make somes researches on some new features, for example around security and hardening. So I prefer starting the migration process on a "not-so-important" computer (yes, I know, I'm a genius), to have an idea of how that will be for the others, when I'm sure to have all the time I need (no dates, no meetings, no constraints...), by making one complete "make oldconfig" pass, and filling a separate text file with my remarks, mistakes, and so on, to know what to review during a "make menuconfig" second pass. Then, if the new kernel boots (sometimes it doesn't, so return to step 2, and add a GRUB entry to be able to boot the last working kernel), and after one or two days of monitoring, I try to migrate the other machines as quick as I can, as the important knowledge is still fresh in my brain.

I like the "make helpnewconfig > whatever.txt" tip. I'l try it next time. Avoiding additional "?" steps during the "make oldconfig" part should lower the number of mistakes. Thank you Section_8.

A little off-topic, but I still don't know why everyone seems to be convinced that it's mandatory to put a copy of a working .config file inside the sources directory... Did I miss something ?

Code: Select all

~ # cd /usr/src/linux
/usr/src/linux # rm -vf .config
'.config' supprimé
/usr/src/linux # make oldconfig
#
# using defaults found in /boot/config-6.1.12-gentoo
#
#
# configuration written to .config
#
/usr/src/linux #

[pietinger]

A little off-topic, but I still don't know why everyone seems to be convinced that it's mandatory to put a copy of a working .config file inside the sources directory... Did I miss something ?

Code: Select all

~ # cd /usr/src/linux
/usr/src/linux # rm -vf .config
'.config' supprimé
/usr/src/linux # make oldconfig
#
# using defaults found in /boot/config-6.1.12-gentoo
#
#
# configuration written to .config
#
/usr/src/linux #

Yes, you miss two things:

1. Not all users are using a bootmanager; they do an UEFI boot directly a (stub-)kernel (like me). Here you dont use "make install"; instead you copy bzImage to /boot/efi/MYDIR/bzImage.efi (and therefore .config will be NOT copied into /boot)

2. It only works because we have a hook for "make install" ... it could be some other distributions dont have this hook (or you try this with a vanilla kernel). See more in this (german) thread:
viewtopic-p-8594916.html#8594916

[Syl20]

OK, that's clear now. Thank you for the explaination.

[Section_8]

FYI, I have a bash script I use for installing a new kernel. I'm changing the section that runs make oldconfig to this, so I can decide what to do, based on the number of settings in the new .config:

Code: Select all

newconf="config_new_settings.txt"
make helpnewconfig > $newconf
numupd=$(make listnewconfig | wc -l)
echo -e "\nThis kernel has $numupd new config settings"
echo -e   "Do you want to run make oldconfig? (y/n/x)"
read input
input=${input,,}
[ $input = "x" ] && exit
[ $input = "y" ] && make oldconfig
[ $input = "n" ] && make olddefconfig && konsole --workdir $PWD -e less $newconf &> /dev/null &

echo -e "\nmake menuconfig"
make menuconfig

[pietinger]

FYI, I have a bash script I use for installing a new kernel. [...]

Code: Select all

[...]
numupd=$(make listnewconfig | wc -l)
echo -e "\nThis kernel has $numupd new config settings"
[...]

Section_8,

thank you very much for sharing your ideas - great stuff ! Yes, knowing the amount before you start is great for decision making. I have just copied your script into my personal CheatSheet file Thanks again !