[lfs-support] 8.3 - Kernel Build

Ken Moffat zarniwhoop at ntlworld.com
Wed Nov 6 05:47:42 PST 2013

On Wed, Nov 06, 2013 at 01:22:23PM +0000, Richard wrote:
> Hello again,
> I am surprised and confused by the warnings and instructions in Section 8.3 - can someone please elaborate on the points below?
> I have previously rebuild the kernel several times on a variety of distros and although instructions differ there has always been one unshakable thing in common: the kernel sources always always always live below /usr/src/linux. I have just checked my host system (a recent clean install of slackware - running 3.2.29-smp) and it too has a symlink from /usr/src/linux to the current source tree. So the obvious questions arise:
> - Where should the kernel source be kept? Presumably below /sources with all the rest?

 Keep it anywhere you like!  Or don't keep it extracted [ I believe
that certain iptables-related things want kernel source, but that is
extremely unusual and certainly iptables itself doesn't need the
kernel source for normal builds ].  Apart from during the build of
LFS, where root is the only user, there is no need to build the
kernel as root.

 For years, my kernel source lived in /home/ken.  I only moved it out
of there to avoid the waste of backing it up : as long as you can
recreate the .config, an extracted kernel tree isn't needed.

> - What are these dire consequences which are alluded to in the warning box at the end of 8.3.1?
> - Is this a LFS-specific problem or are other distro making a mistake? As just stated there seems to be such a symlink on slackware and I had a brief flirtation with gentoo which I am sure also store kernel source below /usr/src/linux?
 I have a very vague recollection that one or two packages (probably
not in BLFS) used to pick up kernel details by looking at
/usr/src/linux , if it existed, in the very distant past.  ISTR they
actually wanted to know the capabilities of the _running_ kernel.

 But yes, we consider that everyone making an unnecessary
/usr/src/linux symlink is mistaken, just as we consider that
updating the kernel headers when updating the kernel is wrong.

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

More information about the lfs-support mailing list