# Compare Two Compiled Kernels To See Differences

## dman777

I made some changes to my kernel and a few days later tested it and found out it didn't work. I can't remember what changes I made to it. I saved the previous version of it with kernel.bck. But, I don't have /proc/config enabled to see inside of it. How can I compare two compiled kernels and see what the differences are?

----------

## ShadowCat8

Greetings,

Well, the best way would be if you have both configs copied to /boot/, you can just do a 'diff' on the two of them.  That way, you will have the exact kernel versions with the local kernel version string attached so you know exactly which ones you are comparing.

If you didn't have the configs copied to /boot/, you can still run the diff across /usr/src/linux/.config and /usr/src/linux/.config.old (provided that you didn't save any kernel configs in between the last working and the current one) to get the changes.

Of course, if it was a genkernel, you can find the configs under /etc/kernels/kernel-config-<arch>-<kernel version>-<local kernel version string>

HTH.  Let us know.

----------

## dman777

Naw, their both custom kernels. I have compiled my kernel so many times, I don't think the current .config.old would match the kernel.bck I have. I guess I need to decompress the kernel? Is there a way and does it contain a .config in it?

----------

## John R. Graham

Alas, no. That's what /proc/config.gz is for. If including a copy of the .config in your kernel raises your hackles too much, consider using

```
make install
```

to copy the kernel to /boot. It also copies the .config file (appropriately labelled) there but doesn't bloat the kernel.

- John

----------

## Gusar

There's a script in the kernel source, scripts/extract-ikconfig

```
# extract-ikconfig - Extract the .config file from a kernel image

#

# This will only work when the kernel was compiled with CONFIG_IKCONFIG.
```

Pray that your old kernel was compiled with that option  :Smile: 

----------

## John R. Graham

Correct me if I'm wrong, but wont the .config file show up in /proc/config.gz of the running kernel if that is set?

- John

----------

## krinn

The kernel must be running to get /proc/config.gz, while this one could grab it from a kernel image even not running but with the option enable. So for OP it's useless.

i would add "make install" not only add the config in /boot but also backup old config and old kernel there.

that "make install" should have more publicity.

----------

## Gusar

 *John R. Graham wrote:*   

> Correct me if I'm wrong, but wont the .config file show up in /proc/config.gz of the running kernel if that is set?

 

/proc/config.gz has a separate option, CONFIG_IKCONFIG_PROC

----------

## John R. Graham

 *krinn wrote:*   

> i would add "make install" not only add the config in /boot but also backup old config and old kernel there.
> 
> that "make install" should have more publicity.

 Hear, hear! Long ago, I petitioned the devs to change the Handbook to use this method. At the time, I was told that the rationale for not using it was that it doesn't work on all architectures. But it works just fine on x86 and amd64. I'd really prefer "best method for each Handbook" over "common method for all Handbooks".

- John

----------

## krinn

Can't believe it's not done, every starting users would be happy to have a grub.conf like this

```
title  Lastest built kernel

root (hd0,1)

kernel /vmlinuz root=/dev/sdb2

title Previous built kernel

root (hd0,1)

kernel /vmlinuz.old root=/dev/sdb2

```

But i suppose starters would fallback to "Previous built kernel", make change to their kernel and "make install", forgetting to "cp /boot/vmlinuz.old /boot/vmlinuz" bofore that "make install", ending with a non working vmlinuz.old and a DOOHHHH!!!!!! if the new one also fail  :Very Happy: 

----------

## ShadowCat8

Well,

Then how about this:

If both kernels were built on the same box under the same /usr/src/linux, then as root, do a: 

```
 ~ # ls /usr/src/linux/.config<tab><tab>

.config                            .config--2012-11-12--12-18-29.bak  .config--2012-11-12--12-20-40.bak  .config.old
```

If they were from the same kernel source, the system may have already made a backup for you.

HTH.  Let us know.

----------

## CkoTuHa

what idiot would name the kernel as vmlinuz firsthand ? Even if that person is not an idiot, it is an idiotic naming convention firsthand. To answer the question asked by OP, there is still research ongoing on how to get the original source or some form of it from the compiled binary. It is somewhere comp.xxx on arXiv.org. If you find a reasonable way to do that, I believe they will give you ACM Turing award for sure or some megabuck company will pay you 10^30$ for sure.

----------

## Hu

 *CkoTuHa wrote:*   

> To answer the question asked by OP, there is still research ongoing on how to get the original source or some form of it from the compiled binary.

 The OP only wants to know what configuration was fed to each kernel build, not the exact Linux source used for the build.  We know what version he used, and while we could derive the configuration if we knew what source was used, determining the configuration is usually an easy problem because usually it is embedded in the kernel.  The OP did not do this, so we are now trying to find other places that the configuration might have been saved.

----------

## toralf

 *Gusar wrote:*   

> There's a script in the kernel source, scripts/extract-ikconfig

 cool hint - thx.

----------

## krinn

 *CkoTuHa wrote:*   

> what idiot would name the kernel as vmlinuz firsthand ?

 

Must be a random guy named Torvalds...

And your idiotic naming convention is explain here : http://en.wikipedia.org/wiki/Vmlinux#Etymology

Someone stole your lollipop CkoTuHa ?

----------

## CkoTuHa

While I appreciate pointing to the beautiful naming convention, which underlines the abstraction that was first implemented circa 1959(apparently, vm in vmlinuz stands for virtual memory), it makes me wonder, what version of linux was available back then. Perhaps 0.0.0000.00000000.0000000000000000.xx.yy ? Also, when linux got to 2.4.xx it got compression of the image figured out and boom, you got the z (z, for compression). bzImage anyone ?

So, still, I challenge those who name his/her kernel vmlinuz and not something like 3.8.7. I just can't fathom people indulging enough to install linux, compile their custom kernel (mess with the config file and then somehow proceeding to delete it) and yet, follow to the letter of some 20 years old adage and name it, of all things, vmlinuz. Is this what people claim as being not creative enough and lack of imagination ?

PS: btw, isn't Linus the guy that kept with 2.6.XX.y naming convention ? There must be some nice math behind that or some scientific beauty why 3 is such a bad natural number that should be avoided like a plague. I can understand now, how Linus was disappoint(pun intended) at Mauro, when the later changed function spec to return some other return value instead of EINVAL  thus breaking alsa or pulseaudio. I appreciate Linus' engineering talent but ffs, vmlinuz, 2.6.xx.yy says he is not good at naming things. But I guess he is now trying to compensate that since in the last year linux went from 2.6.xx.yy.forever to 3.9-rcX already.

PPS: and yes, I foresee bunch a crap people google up regarding how you should avoid releases numbered v3.

PPPS: excuse my digression here

----------

## krinn

 *CkoTuHa wrote:*   

> So, still, I challenge those who name his/her kernel vmlinuz and not something like 3.8.7.

 

Ah this explain it so. The function we are speaking off (the "make install"), also produce kernel with version in its name.

You should look at it, your taste is handle already.

```
ls /boot

System.map                   config-2.6.36-rc6

System.map-2.6.31-gentoo     config-2.6.36-rc6.old

System.map-2.6.31.9          config-2.6.38.7

System.map-2.6.33-gentoo     config-3.4.7

System.map-2.6.35-gentoo-r6  config.old

System.map-2.6.35.4          failsafe

System.map-2.6.35.4.old      fbsplash-livecd-2006.1-1024x768

System.map-2.6.36-rc6        fbsplash-livecd-2007.0-1024x768

System.map-2.6.36-rc6.old    grub

System.map-2.6.38.7          lost+found

System.map-3.4.7             vmlinuz

System.map.old               vmlinuz-2.6.31-gentoo

boot                         vmlinuz-2.6.31.9

config                       vmlinuz-2.6.33-gentoo

config-2.6.31-gentoo         vmlinuz-2.6.35-gentoo-r6

config-2.6.31.9              vmlinuz-2.6.36-rc6

config-2.6.33-gentoo         vmlinuz-2.6.36-rc6.old

config-2.6.35-gentoo-r6      vmlinuz-2.6.38.7

config-2.6.35.4              vmlinuz-3.4.7

config-2.6.35.4.old          vmlinuz.old

```

----------

## ShadowCat8

Well,

From that perspective, then *every* time you build a new kernel, ESPECIALLY when you are experimenting with new features/configs, then you SHOULD make use of CONFIG_LOCALVERSION, with something like:

```
CONFIG_LOCALVERSION="-<whatever you are calling the build>-<date>-<time or sequence number of build for the day>"
```

As an example, when I wanted to experiment with some of Pappy McFae's kernel configs to start with in a build at home, I ended up with a kernel that was called vmlinuz-2.6.36-gentoo-r5-PKS-20110117-01 (where "PKS" stands for "Pappy's Kernel Seeds").  Of course, the line in the config read as:

```
CONFIG_LOCALVERSION="-PKS-20110117-01"
```

@dman777: So, you have a number of places to check for where the files with the differences might be:

/boot/config-*

/usr/src/linux/.config-*

If using a genkernel: /etc/kernels/kernel-config-*

HTH.  Let us know.

----------

