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?
_________________
man cannot be brave without being afraid

[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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[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.
_________________
TIA

[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?
_________________
man cannot be brave without being afraid

[wcg]

[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]

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[dmpogo]

[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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[wcg]

I always run

[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.)
_________________
TIA

[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).
_________________
TIA