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).

Pre requisites

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 have installed:
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):
You now have the sources for your newly donloaded kernel uncompressed and ready to build. But before building them, you must configure them!

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:
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 command:
make oldconfig 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

make menuconfig 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.

make xconfig 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.

make gconfig 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:
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 button/menu entry.

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:
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:
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.

[edit] A long needed edit here... now it should be fine [/edit]

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).
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!.

Addendum: 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:
Thanks Gramphos for the tip!

Needed update

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!

Excellent, I'll sticky this and leave it open for a few days:

If anyone has any additions to add to this to compile a kernel specifically for RedHat, please post them up. If the thread has become locked, contact me with your ideas.

Cool

Cool!

Patches

We often as newbies quick learn also about the existance of kernel patches, in fact this is one of the methods to upgrade your kernel into the next stable release subpatch version. But what are they (apart from the obvious)?? Why do I want to patch the kernel?? How do you apply them??

These questions (among others) are the most commonly asked. To answer that in order:

Patches are files that contain information about the source code of a given program (in this case, the kernel), they contain information like what line does need to be changed, in what file, add lines if necessary in a given section, etc. This is accomplished via two tools: diff and patch. diff (as you may have guessed) highlights the differences between two files when put into comparison. It is specially userful with files that contain hundreds if not 1000's of lines of code, and to apply the changes to just a few lines making this comparison by hand would take for ever. This program helps on automating this task and inserting (or removing) the pertinent lines, to the specified file in the correct path with the aid of the other program patch. Patches usually are composed of one file that contains the information about the file(s) to be patched. NOTE I am, by no means, an expert about patches, so if anyone out there would like to further this explanation would be swell!

You'd may want to patch the kernel for instance, if you wanted to improve a feature, solve a given problem with one feature or just to add another feature to your current kernel, or to upgrade to the next subpatch kernel version. The version of the kernel is determined by the major version number (2), the patch level (current version 4), and the subpatch level (improvements to the current patch level, in this case 22). But ofthen happens that a plain vanilla kernel lacks some features (like CPU scaling for powersaving on laptops), and in order to get those, you need to apply a patch. There are kernel hackers who do just this, they make code to add or improve certain kernel feature/option and publish these as patches. Other kernel hackers make an archive patch, contianing other people's patches into just one file, like the case of Alan Cox, Con Kolivas or the man himself: Linus Torvalds.

To apply a patch is usually simple: Get the patch you are interested in, uncompress it somewhere in your drive and then just change to the directory where you have your kernel sources, then simply issue the command:
After applying a kernel patch (or any other source patch for that matter) you will need to confiugre those options added by the patch and rebuild your kernel. A concrete example as to the need for a patch would be the problems that many users were experiencing with the AGPGART driver on nVidia nForce motherboards, that prior to kernel 2.4.22 the only way to solve it was by applying a patch to the kernel.

RPM kenrels

You can also build binary distributable versions of you custom made kenrel in the form of RPM packages. If you pay attention to the top level directory of your kenrel sources you will most likely find a file called kernel.spec. These files are used to build RPM packages. A good reason to build bianary versions of the kenrel would be if you have several computers similar to one-another in terms of hardware and sofware confiugrarions, making it easier to build just once the kernel instead of building it on every one of them.

To build an RPM package of your kernel, you need to pass to the make command the argument rpm. Like this:
Many people have reported that they have trouble when building RPM packages of the kernel (I've been no exception) and there is also another issue with Red Hat 9 (ahd Phoebe): rpmbuild (the RPM builder) has by default turned on debugging information. This has the adverse effect of an abnormal rpm termination, because it can't find any debug lists in the source tree. To overcome this problem you should make an .rpmmacros (note the dot (.)) file in your home directory containing this line:
So the building process skips the debugging information. Mind that this change may not work for some people, because the process could complaint about a bad exit status from rpm.

I hope these two tips/additions will be also helpful to you.

Hooray! Thanks to you all. I finally had success compiling a kernel. I have had numerous failed attempts. (Or was that I didn't test it thoroughly/properly?). However, I also can't seem to make rpms.

Well, as a bonus (I think), v2.4.22 gave me hardware 3D acceleration! Let the (Linux) games begin!

Glad you achieved this!! Keep up the feed back, all you guys so I know if guides like this are being helpful or not.

Thanks.

Thanks Thetargos, this kind of guide is wonderful! I'm wanting to recompile my kernel for both low-latency and openMosix support and am going to upgrade from the stock RH8 kernel - this kind of advise is indispensable.

Cheers!

Just make sure you have all the pertinent documentation when doing those patchings, as a suggestion I'd tell you to rename the sources directory to that of what you are going to do finally, for example if applying the Con Koivas' patch set (for low lattency and desktop tuning) I usually rename the linux.-2.4.22 directory to linux-2.4.22-ck* so I keep my sources differenciated. Also make sure to what EXTRA_VERSION you set the top level Makefile. Take a loot at it! Other than that, happy compiling!

Now that I have my first successful compilation (see my previous post), I would like to back it up. I can't build an rpm using Thetargos's method above, so how can I back up the compilation? Please help.

Thx. for such nice readme, explained better than many officials.
Two questions or maybe three of them.
Is there some special trick to compile 2.6 test5 in manner this does not complain about qm_modules support and netfilter options?
How to compile 2.6 test5 and nvidia driver (for video) together,latest complains about kernelheaders misconf,but where i get ones for 2.6 test5?
is there anything why i should not use 7.3 and 2.6 kernel together?

From top to bottom:

What is the complaint you are getting about the qm_modules and netfirlter? (sorry if I cannot be of much asistance here).

At the nVidia linux forum there is a mini-howto on this, I cannot say, since I don't use nVidia products (just have to help others get theirs working, which made me learn some in the process ) if it helps (a bit) AFAIK you have to edit some files (macro definitions) on the nVidia source code so it would compile with 2.6

The only reason I may think for this as not being a good idea is that the new 2.6 kernel requires different modutils and binutils so it can actually boot (otherwise you may get what I did back when I copiled test1&2, about no INIT found), so other thatn that, if you are lucky getting those to work under 7.3, you should be fine!

So I got this file [w6692.c] from my isdn card manufacturer. It is a driver file, presumably, and had a vague howto attached to it.

My question is:

With all this talk about modularity, can I build this file into a new kernel module (or the HiSax module, which this is presumably a part of, with the rest of the module's sources)?

I mean, I have this 36 kb file, a "driver", and I need to recompile my kernel (which is not so very old, thank you)? That's what other sources have been telling me to do. Mind you, I got ntfs file system working for me by downloading th rpm, then installing it, total less than 1 minute.

Another question, while I'm at it (and since you seem to have hacked around your Red Hat quite a bit):

How do you like Red Hat customization guide's Appendix A as a help document for kernel compilation? It does seem to make some sense...

Okay, stupid questions, but it's almost 4 AM, and I'm feeling groggy by now, not having my isnd working on linux and having to boot back to windoze for web access.

Regarding your ISDN card: You'd have to compile the .c file separately, since there is no mention to it on the Makefiles of the Kernel or you may have a patched vesion of an already existing module, in this case you simply replace the old file with the one you downloaded. Or if you badly want to be able to compile your driver with every kernel upgrade, you should make a kernel patch, but that would demand way too much (and even more if you don't know anygthing about programming ). In any case, why don't you open up another thread with what the so called how-to states, and we'll work out a solution to your module problem

Regarding your second question, I preffer to compile my own Red Hat kernel, since I am a (so called) gamer, and there are known issues with the official Red Hat kernel, not that it is bad, I'm not saying Red Hat kernels are bad, just they're not fited for gaming. And that is the main reason I compiled my first own-made kernel (to be able to play StarCraft under Wine ). And yes the Red Hat customization gude's Appendix A is a good refference, in my opinion it only needs a little glue so it could drive better from point 'a' to point 'b', at least that in my opinion.

Asuscom's installation guide, the little it says, tells me that in .../drivers/isdn/hisax there should be a file by the same name (w6692.c), and I'm supposed to replace that, then recompile kernel.

All that aside, how about I open a new thread called "kernel isdn module customizing" so we get to talk about it there.

Ok, you do that