I posted this same text on www.rage3d.com
linux forum, I just wanted to share it here.
I post this, because when you are newbie to Linux and have certain problems getting your system to work, you often hear (or read in this case) that you should re-compile your kernel in order to get what you want working. Well that is exactly the reason I'm posting this. To aid those new comers to Linux (the Red Hat way).
In order to be able to build a software package (and the kernel is no exception) you first must make sure to have all the relevant software packages installed on your Red Hat system to be able to do so. From the compiler (gcc) to the make environment (gmake, automake, autoconf), to diverse libraries needed. In order to accomplish this, and if you are new to Linux, often the recommendation as what to install is install everything!
, to certain extent this is accurate, since you will not have to worry about any failed dependencies (some packages relay on very esoteric
ones). But if you are limited on hard disk space or simply don't want to install all of the software packages that come with the distribution, you have an ally: redhat-config-packages. Open the program up and you should be presented with a window which contain all of the possible package that either are installed or can be installed on your system (you may have to supply root's password).
So, from here you should go to the develpment tools
section and make sure you have at least installed gcc, make, automake, autoconf, etc (there are a total of 46 possible packages, you'll need at the very least 15). The following is a list of what I
patchutils (to apply patches to source code)
Of these you should as a minimum have the Basic tools and diffstat-patchutils in order to apply patches.
Getting the Kernel
To build a fully custom kernel, you should get one of the latest sources from www.kernel.org.
Red Hat tends to lay behind regarding kernel releases (because of the custom patches they apply). The latest (stable) kernel version (as of this writing) is 2.4.22 and the latetst test for the stable release is 2.4.23-pre3. So go grab one of these kernel sources.
Once you have the kernel sources on your hard-drive, you can either: copy the sources from that directory to /usr/src (some say it is not recommended) and uncompress them, or uncompress them where you downloaded them. In order to uncompress the tar.bz2 file you just downloaded you'll need to issue this command (for these procedures you don't have to necesarily be root):
$ tar -jxvf linux-<version>.tar.bz2
# cp linux-<versoin>.tar.bz2 /usr/src && cd /usr/src && tar -jxvf linux-<version>.tar.bz2
You now have the sources for your newly donloaded kernel uncompressed and ready to build. But before building them, you must
Configuring the kernel
Basically everyone has his/her own way to configure the kernel, depending on expertise level, system needs and even taste! But as a general rule you should first start off with some known parameters... so if this is your first time compiling the kernel under Red Hat you can use a config template from Red Hat. This template is located at /boot/config-<kenrel version>. So, lets say you have kernel version 2.4.20-20.9 (latest official kernel for RHL 9), and you just uncompressed the sources at /home/me/kernel/linux-2.4.22. All you would have to do to use this configuration template from Red Hat into your 2.4.22 kernel source tree would be to copy the file over:
$ cp /boot/config-2.4.20-20.9 ~/kernel/linux-2.4.22/
Now you are ready to start making your own changes to the default
Red Hat kernel configuration. To do so, change directory to the top level source (/usr/src/linux-2.4.22), you need to start one of either tools: oldconfig, config, menuconfig, xconfig. You start these tools with the make
$ make oldconfig
$ make config
$ make menuconfig
$ make xconfig <-- Basen on QT in 2.6.x
$ make gconfig <-- New in 2.6.x, based on GTK and not TCL-TK
will attempt to configure the current kernel using the parameters fed from an old configuration file .config.old or .config, since the file we copied has not this name making oldconfig will result on a series of text based questions, equivalent to make config
will result in a text based GUI which lets you load up an already existing configuration file (if you have a .config) or an alternate configuration file (like our config-2.4.20-20.9 file). This menu depends on ncurses, so you will have to see if these libraries are installed correctly on your system.
is yet another GUI X based configuration tool which makes it easier and clearer to configure the kernel, this option also allows us to load an alternate configuration file (such as config-2.4.20-20.9). This GUI relys on the TCL-TK library (found in the kernel development section of redhat-config-packages). This GUI has gone a major change in 2.5/2.6 it requires KDE-devel packages.
The GTK front end of the Kernel confiugration GUI for kenrel 2.6.x, it is structured almost identical to that of the new xconfig. Aimed for the GNOME 2.x Desktop Environment. Requires some GTK development packages.
To the ends of this guide, we'll be using either menuconfig or xconfig (to make it easier on you) to configure the kernel. So lets start by opening one of either:
$ make menuconfig
$ make xconfig
Once the GUI has started, find the button/menu entry that reads load configuration from file
. The dialog that appears takes by default the current directory (i.e the kernel sources directory) so just write config-2.4.20-20.9 (or the version of your kernel). The program will load the options found on that file. Now you can navigate the entire tree structure by features and decide whether to include a feature or not. Be warned, you must
read all the help entries on the options listed! To do this you can simply press the help button on the side of the feature/option (xconfig) or move with the arrow keys sideways to highlight the help button (menuconfig).
You will notice that you can compile the features in two ways: as modules (m, [M]) or into the kernel (y,[*]), or simply leave out an option (n, ). Compiling as modules has the side effect of making a lighter kernel, with just what it needs to do its job and rely on modules to load or unload drivers on the fly.
Options that you may surely want
First off you will *need*
to enable loadable modules support
into the kernel, otherwise Red Hat will complaint... a lot (and may not even boot)! And speaking of complaints, you should take a look at your /etc/modules.conf file before
deciding whether or not you want something as module or into the kernel (I usually never touch modules.conf and let RH be, except for cases like ALSA, or my IOMEGA Zip Drive). For example, you may decide to compile into the kernel USB support, but when you boot for the first time, the system will complaint about not finding the USB modules (declared in modules.conf). Also remember that the beauty of Linux is that the kernel has the ability of being modular
which means that it can load/unload pieces of it (mostly drivers) without requiring you to reboot (sound familiar? And yes I may sound repetitive, but it is a common tendency to compile a whole bunch of things into the kernel, getting a monolithic, unflexible kernel)
Some options are recommended to enable as modules, like the IDE CD-Rom support with SCSI emulation, you will need to either answer yes or module to the scsi support, and SCSI-CD-Rom support as module <-- This is very important to have ide-scsi emulation!
for CD-Burners and even some DVD drives!.
As far as IDE chipset support goes, in my experience it is recommended to leave the Red Hat defaults for that part (I messed with them once and ended with a lousy HDD performance), unless you really
know what you are doing. You may screw up the UDMA function of your chipset (and end like me with a losy HDD perfomance, recompile needed).
When it comes to sound support, you may want to compile it as module, because in that way if you want to install, for instance ALSA, it will be easier for ALSA to correctly intialize, or simply because you'll be able to trouble shoot if a problem is dependent on the sound modules.
For the cases of us, Radeon users, we "MUST"
(and I can't stress that enough!) not compile even as modules, any
other DRM driver (tdfx [3dfx] driver often comes compiled into the kernel in some distros), otherwise when we build our fglrx module, it will complaint (yet again) about another module loaded. In this section (character devices) you should also pay close attention to the agpgart driver, compile it as module, not into the kernel (remember fglrx problems regarding agpgart?)
For file systems support, you most surely (now a days it is quite often to do so) want to enable support for Fat, NTFS, Joliet, Transparent decompression, nfs, SMB (samba), etc. What I often do is to compile into
the kenrel ext3 and ext2 (second extended) file systems, and leave the rest I'm interrested as modules.
Remember that if in doubt, Read the help!
, some options have no help entries, so you may want to leave those as they are if you don't have a clue what do they do.
Note: On modern systems (specially with nForce motherboards) you may want to pay close attention to local APIC for UniProcessor machines (and IOAPIC) and ACPI (notice the different spelling, this is not a typo!). If in doubt consult www.nforcershq.com.
If you consider you are done configuring, procede to the next section. Like in a math test, I recommend you to double check your options before proceding, it can save you a lot of time and headaches. Exit with the save and exit
Compiling the kernel
I use an abreviated method to compile the kernel, but for the sake of clarity I'll expose first the unzipped
method and then the compressed one
Once you are happy with your kernel configuration you must build the kernel and the sections you selected as modules. They are built in separate states. So lets first build the kernel, shall we?
You noticed that when you saved your configuration file (it is stored in the .config file) a message was displayed stating you should now run make dep
. This is to build up the dependencies. This method is deprecated and is no longer used for kenrel 2.6 (the software should be intelligent enough to know where to depend, right). Anyway, we'll do just that:
This command will check the code for a while and when it finishes, you'll have your prompt back. Now you can build either the modules or the compressed kernel image, I usually build first the modules and then the image, the following steps may be run in the order you preffer:
$ make bzImage
$ make modules
There are a lot of things that may go wrong, and to help you find out where the problem is, you'll constantly see/hear the recommendation to save the compilation output to a file, to that end you can do this:
$ make bzImage 2> kernel_make.err
$ make modules 2> modules_make.err
The "2>" serves to redirect the standard error
output to a file, in this case the file will be located on the top level directory of your kernel source tree. If the process finishes too soon or just want to make sure (any ways you should do it) check the contents of those files. If you encounter any Error message it will be there. Because warnings are treated as errors, it is most likely that you will find many lines of output from glibc/gcc complaints, these should not be very
important. If everything went Ok, then you can continue with the installation. For these next two steps you will need to become root.
 A long needed edit here... now it should be fine [/edit]
# make modules_install
# make install
Your kenrel is now installed. To try it out reboot and select it from the GRUB menu.
"Compressed compilation method"
I usually tend to use this method rather than the above, because it fits all steps into one long command line. Problem is that if anything goes wrong I usually have to re-run the part that crashed and send its output a file to see what the error(s) was (were).
# make [clean] dep modules modules_install install
Depending if it is a first time compiling this code I omit the clean argument, otherwise I always include it, and finish with a make clean
statement to erease from the tree any residual binary file, once the kernel is installed, of course!.
According to some other users, the make install
secuence will just update lilo.conf (if using LILO) but will not
re-write the boot sector with the updtated information, so an extra command is needed:
# make [clean] dep modules modules_install install
# lilo -v
Thanks Gramphos for the tip!
For kernels 2.6.x you will need to include support for your root partition (/) file system into
the kernel and not as a separate module. If you are using the ext3 file system you will need at the very least
ext2fs support compiled directly into the kernel, otherwise you'll prolly get an error regarding VFS not being able to mount the root partition. Also, if you use other FS than ext2/3, then you will have to replace the grub entry root=LABEL=/ (or something similar) to your actual disk partition (e.g. root=/dev/hda2) in order for the kernel to appropriately boot.
My thanks to all the folks that have found this guide useful and made observations regarding this document
That should do it, at least for now!.
PS: If you have any annotations, corrections or comments, please let me know!