On Fri, Nov 11, 2005 at 01:43:17PM -0500, Matt Price wrote:
> 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
^^^^^
should be "there" instead of "their"
> 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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
How about "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
^^^^^^^^^
hundreds
> 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
> `-
> --------------------------
--
Chris.
======
Reproduction if desired may be handled locally. -- rfc3
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
