[lfs-support] LFS 7.1 rebuilding a kernel with a newer version

Ken Moffat zarniwhoop at ntlworld.com
Tue Aug 21 15:19:10 PDT 2012

On Tue, Aug 21, 2012 at 06:02:57PM -0400, Lewis Pike wrote:
> After a week and a half of wrestling with LFS, I have successfully
> built up what appears to be a working system.  This was my third
> attempt and well, you know what they say.  Thanks to all of the
> maintainers for this wonderful resource.
> In section 6.7.1 of LFS 7.1 I installed the headers for linux-3.2.6.
> By the time I made to actually building the kernel proper I grabbed
> linux-3.2.27 from kernel.org.  Though it is only a different bugfix
> version, it just occured to me that I am mixing Linux versions
> nonetheless.
> Can I safely leave the kernel headers from an earlier Linux version
> in place when rebuilding the kernel proper.

 Yes - anybody building pre-release kernels does this all the time.

>  Are the Linux headers
> guaranteed to be stable across security/bugfix versions?

 Probably not - there are bugs in -stable kernels (even though many
of them only affect one or two people), and there are cases where it
is eventually discovered that a recent change broke an ABI.  In any
case, the guarantee is worth nothing - at most, you could sue for
what you paid to buy the kernel.

 In LFS, we take the view that the headers should be those against
which glibc was compiled.  Distros might take a different view, but
I've never seen problems with keeping one set of headers for the
life of a system, even running the latest and greatest kernels.

>  If Linux
> headers do need replacing when upgrading, are they easily removed?

> Does the kernel ship with a simple tool to clean out these headers?
 No - any *system* will offer 'rm' but I do _not_ recommend that you
use it for this.  Also, at least in the recent past, some of the
include directories contain a mix of userspace and kernel headers.

das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-support mailing list