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 <email@example.com> 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 https://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 - firstname.lastname@example.org 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.