[lfs-support] LFS-BOOK-7.0:Section 8.3: Linux 3.1 Compilation.

Ken Moffat zarniwhoop at ntlworld.com
Mon Aug 13 13:27:50 PDT 2012

On Tue, Aug 14, 2012 at 12:11:41AM +0530, Emerson Yesupatham wrote:
> Hi Team,
> I am currently working on Section 8.3 of Book 7.0. Section is about Linux
> 3.1 compilation.
> I am new to kernel compilation from Scratch. Book recommends to do the
> kernel compilation from Scratch, is there any online material to go through
> or I should go through the README present in Linux tar ball?

 When you use 'make menuconfig' you can use the help.  Select 'Help'
when the cursor is on 'General Setup' for general help about
menuconfig, then use 'Help' on anything you are not sure about -
occasionally, it is useful!  The results of 'lspci' on the host
system (google the devices it reports) should give you a minimal
view of what might be needed.

 However, please remember that your kernel needs to be differnet
from the distro kernel - they use an initrd, which allows them to
build an enormous number of things as modules - even including disk
drivers and filesystems.  For an lfs kernel you will need to ensure
that the filesystem(s) you are using (e.g. ext3 or ext4), and the
drivers for the disk hardware (for SATA or IDE disks, something in
Device Drivers -> Serial ATA and Parallel ATA drivers) are built in,
NOT as modules.

 In General Setup, kernel .config support is very useful (it means,
when you have a kernel which boots, you can look at the
configuration in /proc/config.gz).

 The process normally takes some interations - first, to get a
kernel which boots, then to add anything that was missing.  I
normally add an EXTRAVERSION in the kernel Makefile when I have to
do this (e.g. -A, -B, ...) and save the different kernels as
vmlinux-3.x.y-{A,B,...} so that the 'duff' kernels and sets of
modules can be removed.

 You might also want to save the kernel .config files for each new
build, until you have a kernel that you regard as good.

> I spent sometime to figure out the options shown in make menuconfig GUI but
> it was difficul to understand each and every options.
> I also copied .config (/usr/src/kernels/
> from host system and gave "make menuconfig" but it was asking for so many
> questions one-by-one in the command line.

 Possibly, because fedora have enabled almost everything (all areas
in the device drivers, experimental code, security features), so
anything new will raise a question.
> Not sure whether I should give "make oldconfig" in this scenario ( that is
> copying .config from host PC).

 I would start with 'make oldconfig', but it will still ask a lot of
questions.  For my own fairly-slim configs, going from one kernel to
the next (e.g. 3.4.0 to 3.5.0) will still ask me about perhaps 20
drivers (maybe more, I don't usually count them).

> I went through the README and found there is
> something called  "allyesconfig", can I try that?

 If you have time, and a fast system, yes - but it can take a very
long time, and will build an excessively large kernel.  It *ought*
to boot, but no guarantees ;)
> Kindly suggest.
> My Host PC details:
>  [root at cag73 ~]# cat /proc/version
> Linux version (mockbuild at x86-16.phx2.fedoraproject.org)
> (gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #1 SMP Mon Oct 18
> 23:56:17 UTC 2010
> [root at cag73 ~]# uname -a
> Linux cag73 #1 SMP Mon Oct 18 23:56:17 UTC 2010 i686
> i686 i386 GNU/Linux
> Thanks,
> Emerson

 Unfortunately, those only tell use about the distro, not about your

 One suggestion I saw recently on the kernel list was 'make
localmodconfig' : try to access everything you *need* to use, so
that the distro's modules which relate to your hardware have been
loaded, before you run that, then run 'make menuconfig' and change
the filesystem and disk drivers to built-in.  I haven't tried this,
but it sounds useful.  It isn't mentioned in the README, it's
mentioned in 'make help' (I'm on 3.5, not sure when it first
appeared), found from grep and scripts/kconfig/Makefile.

 Looking at it, 'make localyesconfig' might be a better place to
start - not sure if modules are still enabled by that, or if you
have to re-enable them (some people like modules for things that
only get used infrequently, and since we've built
kmod^Wmodule-init-tools [ just noticed you are still on 7.0], we can
still use them).

 Whichever way you go, don't expect to get it all correct the first
few times!  First, you need to get a kernel which boots and lets you
log in.  After that, you can work on any other issues.

 Also, in 7.0, we didn't advise you to use devtmpfs - it certainly
existed at that time, and is now required, so you ought to enable


 That page also has links to a hint, and to the kernel part of
BLFS's longindex.

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

More information about the lfs-support mailing list