New kernel dir

Richard Lightman richard at
Fri Nov 29 03:15:52 PST 2002

* J_Man <jeremy at> [2002-11-29 10:51]:
> In article <000501c29765$5c158340$3200a8c0 at cheeezexp>, "The Cheeze" wrote:
> > [...] If I wanted to compile
> > the 2.4.20 kernel that was released today, can I simply delete the
> > 2.4.19 kernel dir I already have and then untar 2.4.20 and build it
> If you followed the LFS book to the letter, you should not have a symlink
> in existence, pointing to /usr/src/linux.

ls -l /lib/modules/$(uname -r)/build

If you followed the book precisely, this should be a symlink to
/usr/src/linux. If you were more careful, the kernel sources would be
in /usr/src/linux-<version>, and /lib/modules/*/build would point at
the right places.

>  That's why we copy the headers
> instead of symlink them, because the headers GlibC was built with are the
> ones that need to be present.
Copying the headers is the right answer for glibc. There are some
things (like alsa) that need the real kernel sources for the kernel
that the software will be running under. You can prevent things from
finding the wrong sources by not having a directory called
/usr/src/linux. Packages should not be looking there anyway, they
should (and most do by now) use /lib/modules/$(uname -r)/build unless
you say otherwise.

> So, to answer your question, yes you should be safe to just delete the
> old 2.4.19 source.
The answer is still yes, but you can make your system a little more
bomb proof by thinking about where /lib/modules/*/build should really
link to. I will when I am sure 2.4.20 is working, I will delete
/usr/src/linux-2.4.20-pre8. I forget to delete
/lib/modules/linux-2.4.20-pre8, /lib/modules/linux-2.4.20-pre8/build
will be a broken link, and hopefully cause errors if something tries
to use it.

I have heard that the recent 2.5.* kernels unpack into linux-2.5.*
to save people the trouble of renaming them.

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-support' in the subject header of the message

More information about the lfs-support mailing list