Minor kernels updates applicability for people running custom kernel builds

Question

Imagine the situation.

You're running a custom kernel which you compiled from the vanilla sources using your own .config. A new minor update gets released, let's say 5.16.16 which was released just yesterday, while you're already running 5.16.15.

How can you determine for sure that 5.16.16 contains changes that actually affect your setup? Should you compile and reboot into it or it has zero changes for you and you may safely skip it?

I was thinking of this:

• Apply the patch
• Revert the kernel version back to the one you're already running
• Build the kernel and install it into a temporary directory
• Binary compare the resulting files

This will not work. Modules might match (I'm not even totally sure about that) but vmlinuz will be different because it contains the build date/time and the number which identifies how many times the kernel has been built, i.e. Linux localhost.localdomain 5.16.15 #1 SMP PREEMPT Thu Mar 17 11:20:15 2022 x86_64 x86_64 x86_64 GNU/Linux - you can see #1.

This has to be skipped somehow.

In other words I'm looking for a reproducible kernel build which ignores any local variables.

There's TuxMake but I cannot figure out how to use my custom .config and nothing else.

Answer 1

I’m not aware of an easy way to get a reproducible kernel build that would tell you what you need to know here.

However, the kernel build is now quite good at only rebuilding files which actually need to be rebuilt, so you can use that to give you a good indication of how relevant a bump is for you:

$ git checkout v5.16.14
$ make bzImage modules
$ md5sum $(find . -name \*.o | sort) > v5.16.14.sums
$ git checkout v5.16.15
$ make bzImage modules
$ md5sum $(find . -name \*.o | sort) > v5.16.15.sums

(The optimistic use of find and sort above works because of file naming constraints in the kernel.)

If this shows changes in object files other than vmlinux.o and the kallsyms files, you can investigate the changes in the corresponding source files.

Given the amount of churn in most stable point releases, it would be very unusual for nothing in the source code which goes into your build to change. With make allnoconfig, a minimal x86-64 kernel shows 25 changed object files between 5.16.14 and 5.16.15.