Accidentally upgraded kernel-headers, should I downgrade?
 

When I first did my install of Slackware 13.37, I installed the 2.6.38.4 kernel from /testing.

I did a "upgradepkg testing/kernel*.t?z"

Well just now I realized that there was a kernel-headers package in /testing, and I've heard that you should only use the kernel headers that glibc was compiled with.

So did I make a mistake installing the kernel-headers from /testing?
And if I revert back to the stock kernel-headers package, will I have to recompile all the programs I've compiled with the 2.6.38.4 headers?

Thanks

Just to be safe, I would 'upgradepkg /linux-13.37_mirror/slackware/d/kernel-headers-2.37.6_smp-x86-2.txz'.

But may be you should wait for an answer with a sounder rationale ;)

My assumption was that when Pat built these packages he just renumbered them because of this requirement to keep headers at the appropriate level for the installed version of glibc, however a quick explodepkg and diff of the provided 37.6 v 38.4 kernel-headers packages do show a number of differences suggesting that my assumption was way off the mark.

There was a thread in this forum about a year back about kernel headers which eventually died out without really providing a definitive answer to this question.

General wisdom seems to say that you shouldn't update your kernel headers, but Pat's kernel-header packages clearly do.


The reason I'm interested in this subject is that I use my own kernels as the officially provided kernels tend to go out of upstream support very quickly. I don't install updated kernel headers when I update my kernel because of this idea that headers should match glibc. I guess the reason my system continues to work is that upstream keep new kernels backward compatible with stuff built against older headers.

When I go to 2.6.39 I might do a headers install and rebuild glibc this time and see if I hit any issues. I've not really wanted to do this before because if I change too much then I'll reach a point where I'm no longer running Slackware, but GazLware, though doing that for a while might be an interesting learning exercise.


Anyway, setting all that aside, I don't think Pat would provide a headers package in testing/ that wouldn't work, so you're probably safe using it even though this does appear to fly in the face of this 'general wisdom on headers'.

I am somewhat confused about this topic. I run a custom 2.6.38.6 on my main machine (/usr/src/linux points to the directory with the new sources), but have the original kernel headers installed. Can that lead to any problems? If so, how do I correct that without reverting to the original kernel?

Tobi,

The /usr/src/linux symlink isn't of any value these days and is not used for the headers. In fact, I delete mine completely as it serves no purpose.

Just to be clear:
I'm currently using my own .38.7 kernel with Pat's 38.4 headers package from testing/
The only reason I'm running those headers is that I updated to Pat's 38.4 kernel (just like piratesmack did) a while back prior to switching to my own custom kernel.

As a rule, I don't update my headers when I install a custom kernel, and if I hadn't tried Pat's 38.4 packages I'd still have 37.6 headers installed. In all honestly, I wasn't expecting there to be any difference between the packaged 37.6 and 38.4 headers - That came as a bit of a surprise.

GazL: Thanks for that clarification.

Thanks for the replies everybody.

I have not experienced any trouble with the 38.4 headers, but I think I'll go back to the 37.6 headers until I understand this better.

Technically, you shouldn't update them unless you have a reason to. But then, why are they there in /testing ? I don't know.

The symlink does not serve any purpose, but the original build location does. If you build in one directory, and then either remove or move that directory, things that build against the kernel's source headers will fail. This location is read from applications that need to link/read/use the kernel source headers- such as out of tree modules (Nvidia), or other applications (mjpegtools, MythTV ...). If you don't pass which kernel to build against, the application assumes the current running kernel, and gets the source location from /lib/modules/$KERNEL/source <-- which is a symlink to the actual source location at build time.

Slackware's kernel headers package has a strange name. As it is actually not the kernel's headers (at one time they were a kernel's headers though ;)). Better name might be glibc-headers? I think a simple renaming of this package would cut down on a bit confusion it currently causes. Kernel headers are also located in Slackware's kernel-source package, but these serve a different purpose than the (glibc)kernel-headers package. Perhaps some of the confusion comes for the fact that some Distro simply link /usr/src/linux/include/{linux,asm} to /usr/include, others do call the package libc headers, and Slackware simply call them kernel headers. Now I'm getting confused :scratch: :)

@ "source" headers

Apparently, from what I've seen of other such posts, is that distros are supposed to "sanitize" the source tree as well and have this as a seperate package from the kernel source so what you can do such things as compile the nVidia drivers without actually having the source. This is also the cause of the symlink to /usr/include since they can be used there as well.

This looks like the following is supposed to be run...
This implys that not even the kernel recommends using <exactly> the same headers for the source tree and the /usr/include headers.

Unfortunatly this still doesn't answer the glibc problem.

Yep, I'm aware of the old practice of linking /usr/src/linux/include/... into /usr/include, but that practice has been discouraged for quite a long time now, and I'd be very surprised to find any of the major distros still doing that. That's not what I'm confused about.

The confusion surrounds the question: Why are the headers contained within testing/kernel-headers-2.6.38.4*.txz different to those in kernel-headers-2.6.37.6*.txz when they both share the same glibc build, and when the general wisdom says that the kernel headers should remain at the version that was used to build glibc.

I get the feeling that this 'general wisdom' isn't the whole story but just the safest option because new kernels are compatible with older executables and libraries built against older headers. If you update the headers then you may need to rebuild some libraries. I don't see why glibc would be a special case as it's quite possible for other libraries to also use kernel features/headers directly which may be subject to change. Perhaps Pat's just been lucky so far when updating them.

The whole topic seems quite messy.

It does buck the general posts about the subject that's been beaten into our heads over the years.

My post wasn't directed towards you. Just a general post for others that browse by. I can imagine someone interpreting delete the link as deleting the actual source tree :)

Fair enough. :) My point was that the /usr/src/linux symlink wasn't necessary and that is what I was referring to, not suggesting anyone delete the /usr/src/linuix-$version contents, but yes, it's probably a good idea to make that point explicitly to save anyone from making a mistake. Thanks for mentioning that. :)

Going slightly off-topic, but still talking about what you've been referring to:
I've been considering changing the way I build my kernels to use the make O= option to keep the source pristine, but I'm not sure how best to handle these build and source symlinks under /lib/modules/$uname -r). I've seen some distros actually copy the contents across rather than rely on the symlinks, but I'm not sure how much would need copying (wouldn't want to have to copy the entire tree as that could get a little large).

Gazl, you shouldn't need to worry about the symlinks, or copying files, if you set the destination of your make command to a directory that does not get deleted.

I created a directory called /usr/local/builds just for use with kernel building. Each kernel build goes into its own separate sub-directory (e.g. /usr/local/builds/2.6.38.7-abc). You just have to remember to use the "O=/usr/local/builds/2.6.38.-abc" for all of your make commands. The symlinks will end up pointing to this new directory (no need to change symlinks or copy files).

As long as the this build directory remains intact (and the kernel source code exists too), you shouldn't have any problems.

The original kernel source code remains pristine (although you may need to run make mrproper once).