# Can I have linux-headers newer than the running kernel?

## Jarjar

I'm still running 2.6.28, and the ebuild for those (or older) linux-headers has been removed. Along with masking newer kernels for the time being, I masked linux-headers; now emerge tells me

```

!!! The following update has been skipped due to unsatisfied dependencies:

sys-fs/udev:0

!!! All ebuilds that could satisfy ">=sys-kernel/linux-headers-2.6.29" have been masked.

!!! One of the following masked packages is required to complete your request:

- sys-kernel/linux-headers-2.6.32 (masked by: package.mask, ~amd64 keyword)

/etc/portage/package.mask:

# Until the next kernel upgrade...

- sys-kernel/linux-headers-2.6.30-r1 (masked by: package.mask)

- sys-kernel/linux-headers-2.6.29 (masked by: package.mask, ~amd64 keyword)

(dependency required by "sys-fs/udev-149" [ebuild])

For more information, see the MASKED PACKAGES section in the emerge

man page or refer to the Gentoo Handbook.

```

Is it safe to unmask linux-headers and have linux-headers-2.6.3* installed while running 2.6.28?

----------

## Sadako

Yes, it's absolutely safe.

There's a variable you can add to make.conf for glibc, which determines the oldest kernel you can boot the kernel with.

As long as this isn't set to the value of your installed kernel headers version (which is the max value you can use), then there would be no issue.

The variable is "NPTL_KERN_VER", and 2.6.9 has been the default for ages, so technically you could use a kernel that old.

----------

## depontius

Given that we can't even find a kernel that old, are there any advantages to be gained by moving NPTL_KERN_VER to something a bit newer?  I would see the big gotcha being if one booted a LiveCD with a really old kernel, and then tried to chroot into an install with a newer NPTL_KERN_VER, but even that's unlikely.  Besides, it's an excuse to throw out old install and rescue CDs, and burn a current set.

----------

## Jarjar

Great, thanks  :Smile: 

Why exactly are linux-headers not packaged with the kernel tarball itself, though?   :Embarassed: 

----------

## Sadako

depontius;

I typically do that when doing a new install, setting it to the stable linux-headers version, and haven't encountered any issues.

Once I did get actually caught, were I needed to chroot from a livecd, and the latest kernel on the only cds I had handy was one version behind the NPTL_KERN_VER value, which did kinda suck, but usually the stable linux-headers version lags behind the most current kernel release to provide a decent safety margin.

In theory it should make glibc use a little less kruft for older kernels, and be a little more efficient, but tbh I doubt there are any noticable gains to be had (I'm still gonna continue doing it anyways, because why not?).

Oh, FWIW, when you run `file` on a binary it should tell you what the minimum version kernel that binary will run under, as a result of this setting.

----------

## Sadako

 *Jarjar wrote:*   

> Great, thanks 
> 
> Why exactly are linux-headers not packaged with the kernel tarball itself, though?  

 This has come up a lot...

The linux-headers package contains a sanitized version of the kernel headers for userspace apps to include when compiling, and bugs within the kernel headers are not uncommon, even using the latest ~arch version of the linux-headers package typically causes a few other packages to fail to compile.

edit: actually, the linux headers are included in the kernel tarball, most of what the linux-headers package installs under /usr/include/linux (and a few other dirs) can be found under /usr/src/linux/include.

----------

## depontius

 *Hopeless wrote:*   

> depontius;
> 
> I typically do that when doing a new install, setting it to the stable linux-headers version, and haven't encountered any issues.
> 
> 

 

Rats.  I have a system at home in the midst of "emerge -uav world" right now.  This would have been the perfect time, had I known this just a little bit sooner.  

For backward-compatibility reasons, really it all boils down to linuxthreads, I'd kept that machine at glibc-2.5, which also meant keeping it at gcc-4.1.4, etc.  Over time I've had to mask more an more packages because of the ancient gcc and glibc levels.  Finally I decided that I haven't run across those incompatibilities lately, so I decided to let it upgrade.  I'm also going to use it as a testbed for xorg-server-1.7.5 and the new fun stuff, soon as I have it running 2.6.33.

----------

