kernel-compile-troubleshooting -- help with a howto
Hi folks,
I've compiled my own kernel numerous times but am not
programming-literate; often I wish there was a howto that explained the
significance of certain common problems that I seem to have over and
over again. Haven't found one, though, so thought I'd write my own:
http://wiki.debian.org/KernelCompileTroubleshooting
Unfurtunatley, I'm so ignorant, I can't really answer my own
questions! Therefore, I'm asking for help. I'd like to hear what is
wrong, misleading, or justp lain missing from this document. The
current version is appended below, and feel free to carry on this
ocnversation eithero n the list, or by direct modification of the wiki
page (which is after all what wikis are for).
Thanks,
Matt
--------------------------------------
KernelCompileTroubleshooting
BuildYourOwnKernel
Please Do not Trust This Page! Author is Ignorant! Instead, Amend with
Corrections!
Sometimes the standard howto is not enough. This page describes some
factors that affect the success of kernel compilation and
installation, for non-programmers like the author who don't really
understand what happens when the kernel is
compiled. BuildYourOwnKernel and the link collected their is a much
better place to start!
1. Compile-time problems
setting gcc version
GCC is the gnu-c-compiler; it's the program used to compile all the
C-based programs on your system (that's most of them). New versions of
the compiler are periodically released, I guess either because the C
language standard changes, or because new hardware comes on line that
requires special implementations (I think, for instance, that it's
easier to use recent gcc versions to compile
64-bit-processor-compatible code; but I don't really know, I already
said I'm not a programmer!). In general, the linux kernel does not
compile equally well with all versions of gcc. It would be nice to
have a complete list of which kernel versions suggest/require which
gcc versions, but I don't have one; I do know, though, that Debian/Sid
kernels are currently (Oct. 2005) all compiled with gcc-4.0. However
I've had lots of trouble compiling kernels 2.6.12 and lower with
gcc-4.0.
On Debian, /usr/bin/gcc is a symlink, so in principle you can just
change the target from gcc-4.0 to gcc-3.4 whenever you like. This
however is not recommended, because many packages will expect the link
to point to a particular version of gcc (why is this? I'd love to know
the answer.).
Instead, we can easily change the version of gcc used by make-kpkg
using the "MAKEFLAGS" command:
*
MAKEFLAGS="CC=gcc-3.4" make-kpkg kernel-image
Question: Does this always really work? Or are there other factors in
your environment that can influence compile-time behaviour by
make-kpkg?
One thing to done here is that third-party modules built for the
resulting kernel must be built with the same version of gcc as the
kernel-package itself. You can do that thusly:
*
using module assistant:
o
CC="gcc-3.4" module-assistant auto-install
some_source_package
or
o
module-assistant --cc="gcc-3.4" auto-install
some_source_package
*
in the old-fashioned way:
o
./configure CC="gcc-3.4" make
Anyone know if this is really true?
Cleaning the Tree
When you compile a kernel, hundereds (thousands?) of new files are
created in the kernel tree. By default those files are left in place
after the kernel is built. That's great if you want to recompile the
kernel soon after -- maybe you forgot to include a module? -- the
computer just reuses the files from the last install, and the whole
process only takes a minute or two instead of an hour.
However, sometimes the files left behind can break your next
compilation. I don't really know why, but here are some things I've
seen:
*
You want to change the revision or "append-to-version" flags on
your compile (maybe because, after 10 or 20 tries, you've actually
made a kernel that compiles, installs, and boots, and you don't want
to delete that kernel when you install the next one). make-kpkg will
not let you proceed without cleaning the tree.
*
Somehow you've screwed up something in your build environment --
maybe on your last attempt you accidentally compiled with a different
gcc-version? -- and the files left behind on your disk are
corrupted. THen stuff further down the road will get screwed up too
(is this really true?).
So when compiling seems somehow harder than it should be, do this:
*
make-kpkg clean
Other Problems
Sometimes, no matter how many times I clean the tree or how carefully
I set the gcc-version, I STILL seem to have problems. I don't know
what causes them, but I think part of the issue is that the kernel is
very complex, and enabling certain options and not others can create a
set of build parameters which the developers didn't test -- thus
leading to compile-time failure. Usually I just run
make menuconfig
uncheck the failing module, and re-run; once or twice I've been unable
to do this because the failing module is one I absolutely need. In
such cases, I just rerun make-kpkg, cross my fingers, and hope it
works this time. Astonishingly, this method sometimes works, which
indicates to me that I REALLY don't understand what's going on!.
Boot Problems
Even when a kernel compiles, sometimes it will not boot
properly. Usually this is because some essential options are
missing. Listed here are some "showstopper" options which really must
be enabled if your kernel is to work:
Device Drivers
*
ATA/ATAPI/MFM/RLL support
o
Include IDE/ATA-2 DIST support
PCI IDE chipset support
Generic PCI bus-master DMA support
[your IDE chipset!]
File Systems
*
Second Extended fs support (I also say "y" to all further ext2
options)
Ext3 journalling file system support (I also say "y" to all
further ext3 options)
Initrd Support
The stock Debian kernels use an "initrd" or "initial Ram Disk" to
jumpstart the boot process -- a tiny virutal disk is created in
memory, and (as I understand it) a bunch of kernel modules are loaded
into that virtual disk. This means that, during the inital boot
stages, when the kernel may not be able to locate the root filesystems
(where modules are normally stored), the most important modules are
nonetheless available. Afterwards those modules can be unloaded. This
lets you build a very modular kernel.
So usually it's a good idea to build an initrd. Sometimes though it
doesn't seem to work -- for instance, I just cannot get
software-suspend2-patched kernels to load an initrd (despite howtos on
the website). In this case all showstopper modules must be built as
integral parts of the kernel, NOT as modules.
Also, I often uncheck initrd-related options from the kernel when I
make a non-initrd version. I think this is just superstition, though.
--------------------------
.''`. Matt Price
: :' : Debian User
`. `'` & hemi-geek
`-
--------------------------
Reply to: