[SOLVED] Installing correct kernel source

[mimosa]

Thank you both. That is what I have always thought too, but like ChuangTzu, mostly out of "old habit", aka blind obedience. And then I found that if I did in fact replace the headers package, nothing bad happened ... but maybe it would, if I built certain things.

The corollary of the question is: at what point does it become inadvisable to upgrade your kernel, i.e., if you did, you would need to rebuild the toolchain, therefore, it is better (or at least: easier) to upgrade to the new release, or wait till it becomes available?

[DidierSpaier]

The corollary of the question is: at what point does it become inadvisable to upgrade your kernel, i.e., if you did, you would need to rebuild the toolchain, therefore, it is better (or at least: easier) to upgrade to the new release, or wait till it becomes available?

As f as I know and my understanding is nothing nasty will happen, provided that

• you leave alone the kernel headers shipped in the kernel-headers package, i.e. those extracted from a distribution kernel then copied to /usr/include/linux,
• you store the new kernel source in /usr/src/kernel-<version>

I think that the reason kernel headers can be safely upgraded among the same kernel series is that the kernel devs take care to provide backward compatibility in this context.

For instance, I have uploaded an unified diff between the kernel-headers packages 4.4.38 => 4.4.75 here: http://slint.fr/misc/4.4.38-4.4.75.diff

As you can see there are very few differences: no definition was removed, very few were added or modified.

[mimosa]

So it follows that actually, you probably can upgrade the headers within the same series - but there is still no need to (except perhaps for those who "know what they are doing"). Therefore, this remains good advice for normal Salix users:

As long as you do not upgrade your glibc package, you should not upgrade or remove the kernel-headers package.

It adds a certain perspective that as I understand Robbie Workman's post in the second linuxquestions link by ChuangTzu, the reason why there is a kernel headers package in the first place is to allow you to reliably upgrade the kernel without needing to rebuild glibc against it.

The whole "leave /usr/src/linux alone" is largely a remnant from the days when the kernel headers weren't shipped as a separate package. In those days, the distribution maintainer either copied or symlinked the kernel headers in /usr/src/linux-$VERSION/include/{linux,asm} to /usr/include/{linux,asm}. From what I've read, the symlink was more popular; essentially, the maintainers symlinked /usr/src/linux to /usr/src/linux-$VERSION, then made the include symlinks to /usr/src/linux. After the distro shipped, if the user installed a newer kernel and changed the /usr/src/linux symlink to point to the running kernel sources, then problems could (and often did) occur. In fact, see Linus Torvalds' explanation of what can happen: http://uwsg.iu.edu/hypermail/linux/k...07.3/0587.html

If I remember correctly, Slackware was one of the first (if not the first) distributions to start shipping a separate package of the kernel headers that were used to compile glibc, thereby making the symlink to /usr/src/linux completely irrelevant. Essentially, you should not remove or replace the contents of the kernel-headers package with the includes from a new kernel *unless* you plan to recompile glibc against those headers, and that's not something you need to do. Moral of the story: DO NOT try to use the kernel headers from the kernel version that you're running; the kernel headers should match those that were present when glibc was compiled.

[DidierSpaier]

So it follows that actually, you probably can upgrade the headers within the same series - but there is still no need to (except perhaps for those who "know what they are doing"). Therefore, this remains good advice for normal Salix users:

As long as you do not upgrade your glibc package, you should not upgrade or remove the kernel-headers package.

Yes. I will just add that in the specific case of an upgrade provided by Slackware in /patches as a security fix, it is safe to do this (which also upgrades the kernel-headers if a new package for that is included in the batch):

Code: Select all

slapt-get -u
slapt-get --upgrade # to upgrade all packages non blacklisted in /etc/slap-get/slapg-getrc
# The above command will also list the blacklisted kernel-* packages
# You can then just copy/paste this list as argument of the next command. For instance: 
slap-get -i kernel-generic kernel-headers kernel-modules kernel-source

Then update the boot loader (lilo or elilo or ...) as explained in How to install a different kernel

At least, that's what I do

All readers: do not blindly type the "slapt-get -i ..." line above, as the list of packages to upgrade depends on what is installed, and also on which upgraded packages are provided.

[ChuangTzu]

i do the same Didier.