# The *right* way to update a kernel with minimal work?

## mhelvens

Hello all!

I've been looking for a way to simplify my kernel updates. Right now I use `make menuconfig` every time and manually set my preferred options, which is obviously not optimal. The whole process usually takes me 20 minutes.

I am aware of the `make oldconfig` option, but it doesn't do the right thing. The .config file lists all kernel settings, not just the ones I changed. So if I use an old .config file, it will overwrite every existing value and I might miss the benefits of new default settings. `oldconfig` will also ask me to manually choose values for new settings. I'm not interested in those. I just want to carry over my manual changes to the new kernel version.

This is how I think it should work: `make menuconfig` should create a 'configuration delta' file that only stores the values the user explicitly set. The required .config file can be automatically generated from that by applying it to the default kernel. This 'delta' is what we can safely copy over to new kernel versions. I only want to be prompted when a symbol in the delta is no longer available in the new kernel, so I can manually intervene. Otherwise I don't want to be bothered and everything should be done automatically.

My question: Has anyone implemented this already?

If not, it shouldn't be too difficult. At least in a limited way. A script that takes a default .config and your own .config to create the delta. And a script that takes your delta and a new default .config to create the needed .config. The problem is only that this naive solution can't distinguish between a default value and a setting that you purposely set to the default value (and want to stay that way). It would require a change to the `make menuconfig` interface in order to make the distinction.

If this doesn't exist yet, maybe I can give it a shot. But I don't want to reinvent the wheel.

Cheers!

----------

## asturm

Probably a lot of work when you can just make oldconfig and then scim through the options with make menuconfig when there's been some interesting news about sth. (that's what I do).

----------

## mhelvens

 *genstorm wrote:*   

> Probably a lot of work when you can just make oldconfig and then scim through the options with make menuconfig when there's been some interesting news about sth. (that's what I do).

 

The two problems I mentioned about `make oldconfig` still apply. It will silently overwrite values I never changed and will bother me with newly available symbols that I'm not interested in. Skimming the new settings doesn't help alleviate those.

----------

## Hu

You can use make oldnoconfig to keep existing settings as-is and automatically answer No to any new choices.

----------

## gorkypl

You may also take a look here:

https://forums.gentoo.org/viewtopic-t-910476-highlight-.html

And I'll quote my answer from that thread  :Smile: 

 *Quote:*   

> When upgrading a kernel on the same machine I just make a diff between .config.old and .config generated by make, so I can see what has changed between revisions and address only these changes.

 

----------

## Dont Panic

'make oldconfig' has always worked for me, as long as it's within a given kernel release.

Most sublevel kernel releases (such as 3.2.6 -> 3.2.7) result in no changes at all in my .config when I run 'make oldconfig' (except for the header).

However, I find I need to pay attention to my .config file whenever I run 'make clean' or 'make mrproper'.

You've got me curious why your experience with 'make oldconfig' is so different from mine.

It almost sounds like you're clobbering your .config with a 'make clean' or 'make mrproper' before you run 'make oldconfig'.

----------

## overkll

If one omits "kernel .config support" from their kernel, then `make oldconfig` won't find the config and will prompt the user for EVERY config option.

General setup section:

```

...

  │ │    [ ] Auditing support                                             │ │  

  │ │        IRQ subsystem  --->                                          │ │  

  │ │        RCU Subsystem  --->                                          │ │  

  │ │    <*> Kernel .config support                                       │ │  

  │ │    [*]   Enable access to .config through /proc/config.gz           │ │  

  │ │    (18) Kernel log buffer size (16 => 64KB, 17 => 128KB)            │ │  

...

```

```
  ┌──────────────────────── Kernel .config support ─────────────────────────┐

  │ CONFIG_IKCONFIG:                                                        │  

  │                                                                         │  

  │ This option enables the complete Linux kernel ".config" file            │  

  │ contents to be saved in the kernel. It provides documentation           │  

  │ of which kernel options are used in a running kernel or in an           │  

  │ on-disk kernel.  This information can be extracted from the kernel      │  

  │ image file with the script scripts/extract-ikconfig and used as         │  

  │ input to rebuild the current kernel or to build another kernel.         │  

  │ It can also be extracted from a running kernel by reading               │  

  │ /proc/config.gz if enabled (below).                                     │  

 
```

----------

## Hu

 *overkll wrote:*   

> If one omits "kernel .config support" from their kernel, then `make oldconfig` won't find the config and will prompt the user for EVERY config option.

 This feature is for embedding the configuration into the kernel image.  Could you explain why the .config file in $KBUILD_OUTPUT would be ignored due to not having a .config embedded in the kernel image?

----------

## ppurka

 *Hu wrote:*   

>  *overkll wrote:*   If one omits "kernel .config support" from their kernel, then `make oldconfig` won't find the config and will prompt the user for EVERY config option. This feature is for embedding the configuration into the kernel image.  Could you explain why the .config file in $KBUILD_OUTPUT would be ignored due to not having a .config embedded in the kernel image?

 Indeed that seems so strange to me.

Myself, I copy the .config from the old kernel directory to the new kernel directory and run make oldconfig. I am only prompted for any new kernel options. The settings from my old config remain intact. I follow up the kernel compilation and installation with an emerge @module-rebuild, modify grub, and that's a painless enough and complete kernel upgrade.

----------

## d2_racing

Hi, this is what I use when I upgade my kernel :

```

# cd /usr/src/linux

# make oldconfig

# time make -j5 && make modules_install && make install && boot-update -V && emerge -1v @module-rebuild && emerge -1v @x11-module-rebuild 

```

----------

## mhelvens

 *Dont Panic wrote:*   

> 'make oldconfig' has always worked for me, as long as it's within a given kernel release.
> 
> Most sublevel kernel releases (such as 3.2.6 -> 3.2.7) result in no changes at all in my .config when I run 'make oldconfig' (except for the header).
> 
> However, I find I need to pay attention to my .config file whenever I run 'make clean' or 'make mrproper'.
> ...

 

Honestly, I never used `make oldconfig`, because I looked up what it does, and it's not what I need. Anyway, with my idea, it would be pretty safe and effortless to transfer your settings across kernel releases.

----------

## asturm

I'm using it to upgrade since about 2.6.17 and the 9 or 10 new options/drivers per release are easily dismissed (or looked into, via '?').

Your attempt at solving this will also need to address renamed, previously selected options/whole subsystems.

----------

## mhelvens

 *genstorm wrote:*   

> Your attempt at solving this will also need to address renamed, previously selected options/whole subsystems.

 

True. Although that is a problem with `make oldconfig` as well. And if the kernel developers will not offer support for this (and formally document the renamed options), the best we can do is give the user a message: "your selected option OPTION_NAME is no longer available, please use `make menuconfig` to manually fix the problem".

And I'd be fine with that.

----------

## asturm

That, while true, is a minor problem. Most of the time then I will be alerted by a strangely familiar sounding new option via make oldconfig and look into it.

----------

## b0nafide

 *Hu wrote:*   

> You can use make oldnoconfig to keep existing settings as-is and automatically answer No to any new choices.

 

Thanks Hu! I learn something new every day. This was useful.

----------

## Dont Panic

 *overkll wrote:*   

> If one omits "kernel .config support" from their kernel, then `make oldconfig` won't find the config and will prompt the user for EVERY config option.

 

I tried this on my system (built kernel without "kernel .config support"), and the 'make oldconfig' command worked worked just like always.

It showed no differences (since I had just built the kernel).  Did I miss something?

----------

