Okay, instead of just reciting a recipe without explanation, here's what the commands you need to know about actually do
and when you should use them. I won't beggar off with some poncey disclaimer, I'll say flat out I've been doing this for over a decade so you can print this out if you like--these instructions will be correct
- This attempts to revert the source tree to a pristine by deleting all stale object files, all configuration data, and anything resembling backup files it finds in the tree. On general principle, many people run this the moment they untar a new kernel source, just to be certain nothing hinky came along with it (and this is not a bad thing)
. Note that if you run this command, it will
blow away whatever configuration you were working on. (...and yes, it's pronounced "Mister Proper")
- This is similar to make mrproper
but less aggressive. It will delete stale object files, but leave the configuration intact. If, after you've compiled (and installed) your new kernel and modules, you want to free up a little disk space but still want to be able to do things like say, build the nVidia binary drivers, you can run this--your configuration will stay intact.
Note: If you are modifying a kernel configuration in an already-built tree in a manner that adds or removes from the core (non-modular) part of the kernel, or that changes an option from being in the core kernel to being a module, or vice-versa, you must run one of the two commands above (preferably `make clean`) to eliminate the stale object files or the kernel and modules you get will likely not be sane and will very likely misbehave horribly.
- Pretty much the oldest configuration tool there is. It will ask you about every single option and whether you want it or not, one at a time, seemingly endlessly
. If you answer something wrong once
you get to start over at the beginning. Primarily only of interest to hardcore masochists
- Much more user-friendly configuration tool. "menuconfig" uses an ncurses (text-based) configurator, "xconfig" uses a Qt-based configurator, and "gconfig" uses a GTK+-based configurator. All of these present the exact same information, just with a different face on it. These generate the /usr/src/linux/.config
kernel configuration file in a way that is supposed to always result in a compilable kernel.
Note: Manually tampering with the .config file can result in a file that is missing options that need to be set, or containing options that should no longer be set and can muck things up--meaning your build could fail at some point with a very cryptic error, if you're lucky.make oldconfig
- If you already have a configuration file and would like to apply it to an existing source tree, first clean up the source tree with make clean
, copy your configuration file to the root of the kernel source tree as ".config", and issue this command. Your screen will scroll madly
as the make config
configurator is called and fed all the existing options from your .config file.
- This is similar to make oldconfig
but less spammy on your screen. This makes it very handy for people configuring over a laggy ssh connection.
Note: The two options above are very useful for upgrading between reasonably similar kernels (for example, 2.6.20 to 18.104.22.168) because they will both stop when an option is reached that requires a decision to be made. Usually these options are new features in the kernel, and you can generally assume that if the existing kernel you are trying to recycle was working for you then you can simply hit 'm' to set the new code to be built as a module without having to worry too much about it.
- With the 2.6.x kernels, this is pretty much the "do it all" command. Gone is the need to type `make dep` or any of that other stuff. Like any good Makefile would provide, make all
will cause everything you'd reasonably want to be compiled to be
compiled, including both the kernel and it's modules. If you'd like to know what specifically is going on, type `make help | less` and all the targets that 'all' invokes will be listed with an asterisk next to them.
- Running make with no target mentioned is synonymous with running make all
. Use either one you like.
- This compiles the core kernel and only the kernel.
- This compiles just the modules and not the kernel (parts or all of which may actually get compiled anyway if it's needed to build the modules). If you used make menuconfig
to alter your kernel configuration and only added new modules that were not on at all before
and everything else is already built, you can simply run make modules
and it will quickly figure out which new module wasn't built yet, build it, and you can move on to the final stage rather quickly.
- Not really an installation target, per se, but close enough since there's not really an option to "just" install the kernel. This will give you a compressed kernel image as arch/i386/boot/bzImage that you can then copy to wherever you want.
- This will blow away the entire contents of the /lib/modules/`uname -r` directory (/lib/modules/22.214.171.124-smp for example) and then install all the modules in there.
- This is a command you do not
. The only people who should ever run this are people who build distributions from the ground up who just rebuilt glibc. People reading quick HOWTOs on building a kernel are categorically not such people. Doing this will screw your machine up.
- Running this command will likely not
do what you want. Without special preparation, this is just going to lob the System.map and kernel into somewhere which is probably not the place you
want them to be. If you have done this "special preparation" then this will install both your kernel and the modules in one step. The "special preparation" I mention is that the kernel Makefile looks for a script called 'installkernel' in either ~/bin or /sbin (whichever it finds first) and runs that to install your kernel and re-run lilo. Such a script has been written and can be downloaded from here
which you can chmod executable, copy to your /sbin directory and use immediately. It will copy the kernel, the System.map file, and a copy of your config to /boot using symlinks exactly as Pat does so everything stays nice and tidy. It's code is blisteringly simple to avoid any confusion about what it's doing. Your new kernel will be stored as /boot/vmlinuz-x.y.z with a symlink pointing to it from /boot/vmlinuz and so on.
Don't forget that if you didn't use `make install` you will likely need to edit your /etc/lilo.conf to point at wherever your new kernel is, and run lilo again to update the bootloader. Usually I make the default kernel image for lilo be the symlink of /boot/vmlinuz, and the second item explicitly /boot/vmlinuz-2.6.whatever. After awhile if the new kernel works properly I go back and update the explicitly-named image to point at the new kernel as well. If you are rebuilding the exact same version of the kernel as you did before, feel free to change the $EXTRAVERSION setting slightly, which is the first item under General Setup
. This will be reflected in the final filenames and avoid accidentally overwriting a build you intended to keep while fine-tuning things.
Now that we've covered all that, you can pretty much go from the top to the bottom of this list, and things should more or less make sense. Each of the four stages should be performed in order, and I can't stress enough how useful it is to enable (not as a module, you want <*>) "Kernel .config support" and "Enable access to .config through /proc/config.gz" are under General Setup
. If you do this, and you want to upgrade at some future point, you don't have to guess which iteration of the kernel you might be running... You can type `zcat /proc/config.gz > .config` and it will dump the configuration for the kernel you are using right then into place, ready to be absorbed with make oldconfig
. Considering how unbelievably important it is to build your kernel and your modules with the same configuration, this can be a lifesaver
if you need a new module some months down the road and don't have a copy of the configuration you used previously.
The last hint really worth mentioning is that if you have a SMP machine (either dual-CPU, dual-core, or hyper-threaded--if /proc/cpuinfo believes you have multiple CPUs you do for this purpose) you can use the -j switch to speed things up a bit. Simply specify the number of CPUs you have (plus or minus one at the most
, there is
a point of diminishing returns you quickly reach using say, -j9 when you only have two cores) like `make -j2 all` when you build and things will go much faster as make will spawn two children at once when building instead of just one (the default).
(Yes, this is all from a document I already had written, although it was a bitch to reformat it to use bbcode--and no, I don't do initrds.)