Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
By Thetargos at 2004-04-28 21:27
I posted this some time ago in the RedHat forum, but users from other distributions have also found it useful, that's why I decided to post virtually the same text (with some needed updates addeds, of course) here. I hope you find this information useful.
If you want to compile a 2.6.x kernel, before you do any actual configuration or compilation, refferto the 2.6.x notes at the end of this document for additional information.
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 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):
$ 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 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
$ 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
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:
$ 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!.
Since 2.6.x kernels have appropriate support for the ATAPI interface on CD-Burners and DVD-Rom, CD-Rom drives, you may not need to pass the hd*=ide-scsi argument to the kernel, however if you are still required to due to your system's set up, it's advised to include support for SCSI emulation anyway. Most noticed for the case of cdrdao which in many cases will refuse to work with ATAPI based burners (there's also an update to that in the project's official site http://cdrado.sf.net).
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, 3D graphics users (when using ATi or nVidia propietary closed source drivers), 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. Of course if you use a card (Radeon classic, R7500, etc) that requires the DRI drivers, then, by all means, do not forget about this.
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:
$ make dep
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.
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
# 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!.
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:
patch -p1 < /path/to/patch/file
patch -p1 -i /path/to/patch/file
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.
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:
# make rpm
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.
2.6.x kernel notes
Before you try to compile one of these kernels, make sure you have a recent version of the module-init-tools (moduitls) package, you can find this package at: http://www.kernel.org/pub/linux/kern...rusty/modules/. Alternatively Red Hat 9 users may download the modutils package for Fedora, however it's adivced you try find an updated package for RH 9!.
Since the 2.6.x series of kernels, modprobe will look for the default modules and their options in /etc/modprobe.conf instead of /etc/modules.conf, so make sure you generate one after installing the newer module-init-tools with
For kernels 2.6.x, you will also 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 llet me know!