[SOLVED] Back out kernel update - what about linux headers?

[kimmie]

Hi,

I have to go back to kernel 2.6.20 as 2.6.21 is causing me some headaches.

In the meantime (while running 2.6.21), I'd picked up the update to linux-headers-2.6.21 and rebuilt my glibc.

I don't completely understand the relationship between linux-headers and the kernel version; I know they're independent, but I also know that in order to use newer features in kernel X, I need to build programs against linux-headers version X.

So, my question is: when I go back to kernel 2.6.20, do I need to re-emerge linux-headers and rebuild glibc again, or not?

Gid

[didymos]

No, it's fine. You can even update to 2.6.22 headers if you wanted. As I recently learned, glibc won't use system calls not present in the running kernel, so it's kosher to build against a higher version of linux-headers. The only thing that really should be building against linux-headers is glibc, so you're OK. It's by building glibc against newer headers that newer features are enabled, but only when the running kernel supports them.
_________________
Thomas S. Howard

[kimmie]

Wow. Instant! Thanks very much

I'd like to ask another question... what is the /usr/src/linux symlink actually for? Sorry to bug you, but I've tried looking for an answer to this, and I'm obviously not thinking of the right search terms. Maybe there's somewhere in the gentoo docs I don't know about that has a full answer?

I know from building external kernel modules that it's /lib/modules/.../build that get used for that (at least, that's what vmware does)...

I grepped in sbin looking for /usr/src/linux and found it in the update-modules script... looks like /usr/src/linux is used in searching for a System.map file, although it would find /lib/modules/.../build first, fair enough.

Is it that there are some packages that actually do depend on the kernel (I know gpg used to be one of them), and want to see actual kernel headers? If so would that mean I should do a 'qdepends -Q gentoo-sources' after changing the /usr/src/linux symlink and rebuild those packages?

[didymos]

The symlink just points to a directory with the kernel sources in it. It's partly a convenience for the user, but also, it's simpler to have things that need to check for configured sources to just look there instead of trying to figure out which directory is the correct one. It's not about kernel headers. Some stuff does try to build against those, but unless it's a kernel module, it shouldn't. Mostly it's to see if the kernel has been configured with the right things enabled, so that the program actually works. If you look through various ebuilds, not just external module ones, you'll see CONFIG_CHECK a lot, and various config variables to check will be listed. That's why you want the symlink to point to the kernel you're running, and to have the sources configured in the same way as the running kernel.

One exception is when you've just installed new sources and have built the new kernel, but haven't yet booted it. That way, you can re-emerge kernel modules and they will build against the new kernel, so that when you boot it, all your stuff still works.

The other is when you're still using the same kernel version, but you've changed the kernel image by enabling or disabling something, like changing a module to built-in or enabling some capability that has to be in the image. In that case, you just install the new build and reboot.

As to the needing-to-rebuild issue: almost certainly not. For one, the new kernel probably has the same or equivalent features enabled. Two, the userspace kernel API is pretty damn stable. Internals change all the time, but unless it just can't be helped, upgrading the kernel should never break any program. Modules, yes, but those are a special case: external, but they have to use the internal kernelspace API. It's possible that stuff like iptables or ebtables would break, but if they would at all, it would be rarely.
_________________
Thomas S. Howard

[kimmie]

After I typed my previous message I rebuilt my kernel. I changed a couple of config options (1000Hz tick preemptible -> 250Hz voluntary preemption) I noticed that when running depmod, the external vmware modules had unresolved symbols (to do with preemption, makes sense). So I re-emerged vmware-modules.

But I couldn't work out why my 'qdepends -Q gentoo-sources' hadn't picked up vmware-modules; surely if the package depended on the running kernel it should be a dependency. After I read your message, I was sure it should be.

I did an 'equery depends gentoo-sources'. That did show up vmware-modules, as well as a few other packages. Then I realised that the direct dependency was actually virtual/linux-sources. 'qdepends -Q gentoo-sources' didn't work, but 'qdepends -Q linux-sources' does. Seems qdepends doesn't handle virtuals. I'll have a look into that, maybe it's worth filing a bug.

So now I know: if I do change my kernel config, and I'm suspicious I've removed some feature that a package depends on, I can use equery to find the packages I might have (but, as you say, probably have not) broken.

Many thanks for your answer I'm really happy I understand this now, I've wanted to know this ever since I started with gentoo!