# Do linux system headers need to be same version as kernel?

## Seron

Do linux system headers need to be same version as kernel? If not, will any version combination do? Will a lower version kernel work together with higher version headers, and the other way around? Do they have to be within a certain version range? What problems may appear if the wrong version combination is used?

At the moment I'm using gentoo-sources-2.6.35-r15 (2.6.36-r5 produces intermittent system locks) and have installed linux-headers-2.6.36.1. Will this work?

----------

## NeddySeagoon

Seron,

The simple answers are No and No.

kernel-headers provides a stable (as in don't change) set of headers to build things against that need to be built against the kernel. glibc comes to mind.

Thus kerned-headers needs to be close enough to the kernel but not exact.  'enough' is difficult to quantify.  What matters is the changes, not version numbers.

Problems you get are fairly severe - like the system not booting with glibc complaining the kernel is too old.

----------

## wcg

Seperating kernel-headers from gentoo-sources, it would be up to the

maintainers of the kernel-headers package to define the kernel

version ranges where the data types in the actual kernel headers

are consistent with the data types in a particular kernel-headers

package version. When you compile glibc, it incorporates data

types from the kernel-headers package into various glibc type

definitons. A few other packages do that as well.

If the corresponding data types in the actual kernel that your

system boots do not match what is in the kernel-headers package

that glibc and other applications were compiled against, you get

lots of strange errors. Where the kernel-headers maintainers are

aware that some data type has changed in a particular kernel

version, they can specify in the ebuild that a particular kernel-headers

version is only valid with kernels greater than x.xx.x and less than

y.yy.y. With kernels outside that range, you get a "blocked by" or

"masked" message from emerge.

The glibc package maintainers can similarly specify a range for

kernel-headers package versions that are valid for that glibc

package version. (If the kernel-headers version data types are

consistent with your kernel's data type definitions, then the

glibc data type definitions will be, too.)

The kernel can go through numerous changes without changing

any of the data types of interest to glibc and other applications that

depend on kernel-headers, so it is not necessary to update

the kernel-headers package for every new kernel version that

is released.

----------

## Seron

Thanks for answering.

@NeddySeagoon: I'm not sure which questions your No answers relate to, as I had more than two question. Could it be that you mean headers need not be the same version as the kernel and that the kernel/header combination I have (gentoo-sources-2.6.35-r15 / linux-headers-2.6.36.1) won't work.

@wcg: Can I rely on portage to not install non-compatible kernel/header combinations, i.e. things will get blocked or are masked? If not, what safe rules can I follow in order to not run into problems?

----------

## wcg

 *Quote:*   

> Can I rely on portage to not install non-compatible kernel/header combinations, i.e. things will get blocked or are masked? If not, what safe rules can I follow in order to not run into problems?

 

In theory. All that the kernel-headers ebuild can check against is what

gentoo-sources packages you have installed. There is no way for the

kernel-headers ebuild to know what kernel you might actually boot.

You might download a kernel source package from www.kernel.org, build that,

and boot it to check to see if some oops happens with a vanilla kernel with no

distribution patches applied, for example. You can boot and run that kernel,

but your installed glibc has no way to know if that kernel source package's

header-exported data types are all consistent with the kernel-headers package

that it was compiled against.

I was running 2.6.35-gentoo-r4 on a pIII/i815 box with linux-headers-2.6.30.something

for a few months with no problems. It was recently upgraded to linux-headers-2.6.36.1

on the same box, without an upgrade to gentoo-sources in the same emerge --sync.

(That might show up in the next few days or something.)

I do not think there are guarantees here, just best efforts to not gratuitously

break anything by letting the linux-headers and gentoo-sources versions in

the set of packages in the stable set for a particular architecture get out of sync

with regard to data types in the kernel headers used by packages that depend

on linux-headers.

If you decide that you need to use versions of any of these packages from testing,

from some overlay, or from the wild blue yonder, "theory and practice", etc.

----------

## Yuu

Hi,

as I'm using zen-sources-2.6.34_p1-r2 and I've just emerged sys-kernel/linux-headers-2.6.36.1, I'm also interested by this topic.

 *NeddySeagoon wrote:*   

> Problems you get are fairly severe - like the system not booting with glibc complaining the kernel is too old.

 

glibc complaining when updating it ? Like emerge refusing to update sys-libs/glibc with an old kernel ?

----------

## NeddySeagoon

Yuu,

Kernels are built and installed outside of the protection and control of portage.

There is no protection to stop you installing an old kernel on your system or booting into one you really should have cleaned out, only to find its so old glibc is not compatible, or udev won't start. OF course, its not a big problem as we all keep several kernels around, so we can go back to a working kernel.

----------

## dmpogo

 *NeddySeagoon wrote:*   

> Yuu,
> 
> There is no protection to stop you installing an old kernel on your system or booting into one you really should have cleaned out, only to find its so old glibc is not compatible, or udev won't start. 

 

That's not the only scenario that rases question.  More importnat is like what I have on my server. Kernel is not upgraded since 2.6.27.

Yes I broke the system once by accidently upgrading udev, which did not start then.  Could the same happen with linux-headers ?

I.e I'll run tomorrow emerge --sync on that machine, my linux-headers will go up to 2.6.36.1 and sometime later I'll recompile glibc.

Am I protected from getting a broken system ? (and I won't have a working kernel around).  Or should I mask linux-headers ?

----------

## NeddySeagoon

dmpogo,

The right answer is to upgrade the kernel but thats not what you want to hear.

I would mask the headers so there is no danger of building a glibc that won't run on your old kernel.

You may also find you need to mask glibc and others (gcc?)  since glibc will depend on a certain version of linux-headers.

Exactly what packages and what versions is arch dependent.

----------

## wcg

I always run 

```

(emerge -DuNp system) 2>&1 |tee system_`date '+%Y_%m_%d'`.list

(emerge -DuNp world) 2>&1 | tee world_`date '+%Y_%m_%d'`.list

```

after an "emerge --sync" to see what all is going to be upgraded,

see if there are blocking package versions that need to be handled

first, etc. If I have doubts or if I want the builds for any of the packages

to be logged separately, I work through the emerges in the lists one

at a time. If it all looks pretty standard, I run the same commands

without the "p" option and replace ".list" with ".log".

In either case, after emerging the packages in system.list, I

run "revdep-rebuild -p" to see if anything needs to be

recompiled because of changes in one of its dependencies,

and if so, I run revdep-rebuild without the "-p" (and log the

output). I do the same for the packages in world.list after

emerging those.

(The last thing to do is run a "findcfg()" shell function that

I use to search /etc/* for "._cfg*" files that need to be

compared with the old versions of whatever config

files in /etc they update for changes in the new version

and local customizations in the old version.)

The revdep-rebuild command catches most dependency

changes, and it may catch the need to rebuild glibc after

upgrading linux-headers (I have not actually checked that

to see if it does).

----------

## wcg

Fyi for the OP: testing packages seem to be pretty close to

stable, at least the ones that I have used on amd64. I have

been using ~amd64 versions of flex, bison, binutils,

glibc, linux-headers, and gentoo-sources for several months

with no problems. (I do not use the ~amd64 gcc for code

that the system depends on, so that "what gcc did with

the source code" is rarely a variable to consider when

trying to understand why some program is crashing or

simply not doing what one expects it to do.)

----------

## wcg

PS:

Run "equery depends -d linux-headers" to see what all packages

depend directly on linux-headers for a particular system (and

should probably be re-emerged after an upgrade to linux-headers).

----------

