APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

linux compiling kernel


What is this stuff?

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):



From: Eric Stewart <eric@spamdomainsbanned.lib.usf.edu>
Subject: Things I have learned about compiling a kernel
Date: Thu, 11 Oct 2001 10:16:38 -0400

    I'm writing this because I was encountering many posts in a search
on google about problems people were having compiling a kernel.  My
particular search was launched by an effort to get my Dell Dimension to
automatically power down (or off <- included for search reasons) when I
halted the system.

    Many people say "Oh that's not a problem, I've got my kernel
compiled X way and it works."  Others will say that "I've done the same
thing and it doesn't work for me."  And still, what I write here may not
work for you ... but it worked for me.



    I'm assuming here that the reader is capable of the basics in kernel
compiling, and is using something fairly compatible with my RedHat 2.4.3
kernel.  Also, the ability to use X on the machine will help.

    1) First step: make xconfig and once it's up, "Store Configuration
To File".  Trust me, you want to do this, because your next step will
(or has in my experiences) wipe out your configuration settings, and
this will stop you from having to go back through and completely redo
your config.  Quit make xconfig.
    2) "make mrproper".  Some of us (and I'd suspect, many of us) tend
to skip this step, possibly with the logic "I haven't changed much, so I
should just be able to start make dep ... " etc.  Well, depending on
what you change, skipping this can cause your kernel compile to fail.
Near as I can tell (and I'm no expert), this is pretty much like a "make
very_clean".
    3) Go back into "make xconfig" and then reload your stored
configuration ... unless you really  want to go back through the entire
xconfig and redo it by hand.

Now, I've got two Linux boxes; one is a dinky box used as a Masquerade
gateway (I'd suggest starting at http://ipmasq.cjb.net if your curious;
and it's this box that made me happy to use the "Store configuration in
a file" as there's a lot of "y"s needed for masquerading that default to
"n") and the other is just a workstation (the previously mentioned Dell
Dimension).  The issue that prompted this message being the "power off"
thing ... well, there are some things you should know if you want to get
this to work and can't seem to get it to work:

    4) In "make xconfig" under "Processor type and features," unless you
are actually using a multiprocessor machine, say "n" to "Symmetric
multi-processing support".  By the way, if you've previously compiled a
kernel with this active, and skip the "make mrproper", you'll probably
have problems when you switch this setting and attempt to compile the
actual kernel.  And say "n" to this on single processor systems because,
quoting the HELP for this feature:

The "Advanced Power Management" code will be disabled if you say Y here.

    5) In "make xconfig", under "General setup," for the magic power off
function, you'll want to say "y" to "Power Management support" ...
    5a) Now, in my experience, WITH "y" for "SMP support" mentioned in
(4), a machine *will* power off if you say "y" to "ACPI support".  But
as of the kernel I'm using, the help says that this is under development
and not a complete implementation.
    5b) I personally have "Advanced Power Management BIOS support" set
to "m", and have "Enable PM at boot time" set to "y".  Reading the HELP
for "Use real mode APM BIOS call to power off" will tell you that
chances are you want this to be "n".  I'll reiterate here: if you have a
"y" under "Processor type and features" -> "Symmetric mulit-processing
support", saying "y" to "Advance Power Management BIOS support" will do
you no good at all.



    6) When you're done with the make xconfig, before you quit and save,
you probably should "Store configuration to file" just to be safe.

    Complete your compile steps (make dep ; make clean ; make bzImage ;
make modules ; etc).  Pay particular attention to what goes on during
"make bzImage".  If it fails, go through the process again and make darn
sure it starts with "make mrproper".

    I hope there aren't too many "Well duh, of course, everyone knows
that"s after people read this, and hopefully there are a few "Ah ha!  So
that's what I'm doing wrong"s.

Eric Stewart - eric@spamdomainsbanned.lib.usf.edu
In Software Engineering, a good Requirement must be clear, unambiguous,
testable, modifiable, correct, and feasible.  A slide in an SE class said
the reqt "When the start button is pressed, the system shall transmute
an ounce of lead into a ton of gold" is all but feasible.  It occurred
to me that B. Gates must have given this reqt to the MS programmers
... and they made it feasible.




Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> -> linux compiling kernel ––>Things I have learned about compiling a kernel



Increase ad revenue 50-250% with Ezoic

Kerio Samepage


Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us





Software engineering is the part of computer science which is too difficult for the computer scientist. (Friedrich Bauer)





This post tagged: