Red Hat custom Kernel compilation mini-How-To for Red Hat 8-9
 

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 :D[/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! :D

Some more tips and tricks for compiling the kernel
 

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.

great job
 

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 :D) 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!

driver question
 

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

mystery module part n
 

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

Ok, you do that :)

I've tried the steps outlined here as well as the steps in the Kernel-Howto, but it still fails to work correctly in RH 9.

I decided to get back to basics and did the following:

cd /usr/src/linux

make clean
make mrproper
make clean
(as stated in the Kernel-Howto)

make oldconfig

make dep

make bzImage

make modules

make modules_install

cd /lib/modules

mkinitrd 2.4.8.20GB.img 2.4.8.20GB/

then

cp /usr/src/linux/arch/i386/boot/bzImage /boot/bzImage-new-kernel

cp /lib/module/2.4.8.20GB.img /boot/new-kernel.img

cp /usr/src/linux/.config /boot/config-new-kernel

cp /usr/src/linux/System.map /boot/System.map-new-kernel

Then, I include the new image in /etc/lilo.conf and run lilo

lilo

lilo -q

linux*
new-kernel

And at reboot, I select the new-kernel from the list of two kernels.

This then either ends in a kernel panic or it loads, but gives failure messages about it not supporting reiserfs, ext3, etc.

I would have thought that doing the make oldconfig would have taken the settings for the default, working kernel and then let me just proceed to build a copy of it.

Can anyone shed light on where I've gone wrong?

Thanks.

PS - I've done this with an installation of SuSE 8.2, but mkinitrd failed to run.

I went through all the other steps and rebooted to the new kernel option and it panicked.

But when I went back to /etc/lilo.conf and included the path for the working initrd image, it booted fine and runs fine.

Hmmmm....

If I use LOLO instead of Grub Will I need to o any configuration for the new kernel to get into the boot menu?

I figured that I had to run lilo -v to make it work.

Usually the installkernel program will take care of that.

If I understand correctly, you are trying to compile a 2.4.8 kernel?? You want to do a kenel downgrade??

In any case you should have no problem compiling the kenrel, but the problem regarding the panics seems to me like you have enabled some EXPERIMENTAL driver into the kenrel or in the modules. If you are using the LowLatency patch, you may need to re-nice some of the services the kernel starts, otherwise they will seg-fault. What does the panic say?? does it give any info at all (a dump core or something?) You may have hit a kernel bug rather than a compilation per se problem.

For the ReiserFS and EXT3 problem: Did you enabled support for those FS in the FS section? either as modules or into the kernel?

It didn't do that for me. If you use GRUB you wouldn't need to rewrite the MBR as the configfile is read, but with lilo you will have to. (At least I had to)

So doing a 'make install' did not work for ya with LILO?? that is a good addition to be made :cool:

The /etc/lilo.conf got updated by make install, but I had to execude lilo -v to update the boot sector accordingly.

But it's one more command to be run. So it's an addition needed for LILO.

kernel compilation/install errors
 

Okay, here's me, one experience richer: I compiled my own kernel. Too bad it was a dud :scratch:

I move that we start another thread called "kernel compilation/install errors". That way this thread don't get too far out of hand... be a good addition to this, though.

So I'll post my error messages and problems there!

Hi there.

I finally got time to recompile my kernel with low latency and openmosix support - all went well so thanks again Thetargos.

One question I have. I need to rebuild my drivers for ALSA and was trying to do it from the source RPM. I tried:

rpmbuild --rebuild --target i686 --define 'kernel 2.4.22' alsa-driver-0.9.6-1.fr.src.rpm

but it came back with the error message:

error: Failed build dependencies:
kernel-source = 2.4.22 is needed by alsa-driver-0.9.6-1.fr

Is there something else i'll need to download or will I need to compile all the ALSA stuff from source for the new kernel?

Cheers.

I printed & tried following your instructions on my system. I did a COMPLETE installation.

When I try to run the command 'make xconfig/config/menuconfig' I get an error:

make: *** No rule to make target 'xconfig'. Stop.

Suggestions?

Your welcome! :D :o

For ALSA, just download the latest source packages from alsa-project.org, and compile them. Download all the packages, and install in this order:
alsa-lib
alsa-utils
alsa-oss
alsa-driver

to install just untar the tarballs (tar -jxvf <alsapackage>) change to the directory of the package and:
preferrably as root (make install should *always* be done as root).

For your driver, just add these options to the ./configure script:
To find out what is the name for the module for your card, and alternatively you may do this (if you want, of course!)
In the example above, I have stated to compile drivers for only the emu10k1 based card (in this case my card), the oss option is to add oss compatibilty to the driver (to play virtually any games) and the sequencer option is to activate MIDI support.

After you install you will see that the channels are muted, you unmute the channes by running the alsamixer command, but before that, make sure you run the makesnddevices script from the driver top level direcotry, otherwise the mixer will not be able to start. Another thing, you can add the alsasound init script to your init sequence, by
Then start it by:
Enjoy!

PS: Check the alsa-project page for refferences on specific card model and the modules options for modules.conf!!!, this is very important!

Are you sure you are under the directory linux-2.4.22?? Altenatively you may update your symlinks like this:

Hey Thetargos,

I already had ALSA working for the 2.4.18 kernel. I installed the packages from the rpms at freshrpms.net (I had to rebuild the src rpm for kernel-module-alsa for that specific kernel)

I was just wondering if there was a quick way to rebuild the kernel-module-alsa source rpm for the new kernel.

Cheers.

I have no experience with source rpm's for ALSA. I've always installed it from tarball, it allows (or at least, that is what I think) more control over the the compilation, like the fact that I wouldn't want the whole bunch of drivers compiled in, or to let me add or remove certain feature (like MIDI or AC97). So I'd rather download a newer rpm or simply install the latest sources. It'd be nice to have the guys from freshrpms to lend us the .spec file so we could build the rpms from within the already compiled code in the pure sources.

Hey Thetargos, just a follow up...

I got ALSA to work for the new kernel by just compiling and installing the alsa-driver tarball. I just compiled it with support for my soundcard and the new drivers worked fine with the already installed libs, utilities, etc.

Thanks again,
meeshka

Good to hear you got it right :)

First of all, Thetargos, thanks for the (amazingly clear) instructions on how to compile the kernel. Apparently I am the only one who has had problems with this, and I hope you can help me with this:

After following your instructions and running the 'make install' command, I got this error:

md5sum: WARNING: 1 of 13 computed checksums did NOT match
md5sum: WARNING: 1 of 13 computed checksums did NOT match
setup.S: Assembler messages:
setup.S:230: Warning: indirect lcall without `*'
Root device is (3, 2)
Boot sector 512 bytes.
Setup is 4767 bytes.
System is 890 kB
+ '[' -x /root/bin/installkernel ']'
+ '[' -x /sbin/installkernel ']'
+ exec /sbin/installkernel 2.4.22 bzImage /root/kernel/linux-2.4.22/System.map ''
/lib/modules/2.4.22 is not a directory.
mkinitrd failed
make[1]: *** [install] Error 1
make: *** [install] Error 2

What does this all mean? Thanks in advance for taking your time to answer a newbie's questions.

Hey Thetargos,

Just a question, in your original instructions you had:

$ su
password:
# make install
# make modules_install


should make modules_install come before make install?

I figured make modules_install had to come first too, and I ran that command then, and I got this nifty error (this is the redirected makemodules_install.err file):

md5sum: WARNING: 1 of 13 computed checksums did NOT match
md5sum: WARNING: 1 of 13 computed checksums did NOT match
setup.S: Assembler messages:
setup.S:230: Warning: indirect lcall without `*'
Root device is (3, 2)
Boot sector 512 bytes.
Setup is 4767 bytes.
System is 890 kB
+ '[' -x /root/bin/installkernel ']'
+ '[' -x /sbin/installkernel ']'
+ exec /sbin/installkernel 2.4.22 bzImage /root/kernel/linux-2.4.22/System.map ''
depmod: *** Unresolved symbols in /lib/modules/2.4.22/kernel/crypto/autoload.o
depmod: crypto_alg_lookup
depmod: *** Unresolved symbols in /lib/modules/2.4.22/kernel/crypto/proc.o
depmod: crypto_alg_sem
depmod: crypto_alg_list

I got the same errors with make install afterwards...

So I go back to see if the problem lies within the earlier steps,
I ran make bzImage 2> bzImage.err, whose output was:

md5sum: WARNING: 1 of 13 computed checksums did NOT match
md5sum: WARNING: 1 of 13 computed checksums did NOT match
setup.S: Assembler messages:
setup.S:230: Warning: indirect lcall without `*'
Root device is (3, 2)
Boot sector 512 bytes.
Setup is 4767 bytes.
System is 890 kB

I also ran make modules 2> modules.err, and its output was this:

md5sum: WARNING: 1 of 13 computed checksums did NOT match
make[2]: Circular /root/kernel/linux-2.4.22/include/linux/netfilter_ipv4/ip_conntrack_helper.h <- /root/kernel/linux-2.4.22/include/linux/netfilter_ipv4/ip_conntrack.h dependency dropped.


So far I can see that this 1 of 13 computed checksums error is consistent within all the error log files I've made... coincidence? I sure wish I wasn't a newbie.

Yes, indeed, you are both right. I assumed make install would only make the base bzImage and then install it (but learned latter that it needs /lib/modules/<kernver> to do its job). As I said at the end of the guide, I noramally use the compressed method:
So I just sit back and watch the compile porcess (which is kind of cool with a nice desktop image, the terminal maximized and set its background to transparent :D)

About what I posted previously, the kernel did compile, in spite of the errors. After running it on my laptop thru grub (I compiled the kernel in my laptop and in my desktop, both got the exact same errors), I was distraught to see that my ethernet card didn't work (but fear not I just made it work... it seemed that since I had compiled the drivers for my previous kernel, it wouldn't work on this one.

The real problem is that it doesn't recognize my mouse. It's a kensington usb pocketmouse, which it recognizes perfectly in my previous kernel installation. The touchpad works fine though. I had both working fine on my 2.4.20-8 kernel. Also, I have a few games installed, and they run terribly slow now... I checked my video card config and it's just fine (the enable 3d hardware acceleration checkbox is checked).

In the kernel configuration (i ran menuconfig), i enabled all the usb devices, as well as mouse and keyboard usb support... I don't know what could be the problem... And if that wasn't enough, at bootup, it still gives me that error that says

*** Unresolved symbols in lib/modules/2.4.22/kernel/crypto/autoload.o
*** Unresolved symbols in /lib/modules/2.4.22/kernel/crypto/proc.o

I truly have no idea what any of it means.

ok, I tried running insmod manually to install the autoload.o file, and this is the error that I got:

root]# insmod /lib/modules/2.4.22/kernel/crypto/autoload.o
/lib/modules/2.4.22/kernel/crypto/autoload.o: unresolved symbol crypto_alg_lookup
/lib/modules/2.4.22/kernel/crypto/autoload.o:
Hint: You are trying to load a module without a GPL compatible license
and it has unresolved symbols. The module may be trying to access
GPLONLY symbols but the problem is more likely to be a coding or
user error. Contact the module supplier for assistance, only they
can help you.



I assume I am getting closer to the answer, though I dunno who the module supplier is, or what in the world GPL is.

Hello,

firstly THANK YOU sooo much for writing this guide. I had no installtion problem. But after I rebootet GRUB showed me 3 Kernels

1.---2-4.20-8smp
2.---2-4.20-8
3.---2-4.22

Which is ok, #1 #2 work fine. But #3 says after a while, Kernel Panic unable to mount "vfs" It cant find the root file system.

Do you have any tips for me :D

Thanks

-Florian

GPL: General Public License (by the GNU project) go to www.gnu.org for information about this.

Regarding the problem you [b]did[b] compile with cryptographic support into the kernel. This was one of the reasons I never could re-compile an official Red Hat kernel (and hence decided to go on my own with a plain vanilla kenrel) try to compile [b]without[b] cryptographic support.

make sure you did compile with support (either as module or into the kernel) for your local disk format file system. That should do it.

Tip: I usually compile with ext3 support and ext2 (second extended) directly into the kernel. To me it sounds like a network file system problem verify that too..

Hello after running in one problem I am now facing the second :p

I finally got it to read the .config file from the original 9.0 kernel. Upon editing some stuff, I get the following error in booting

mount: error 19 mounting ext3 (maybe not a file sys suppport)
umount /initrd/proc failed:2
Kernel Panic= no init found

Thanks

Florian

PS: Altough I am a :newbie: I will not give up :-)

:Pengy: FOREVER

ok I see what you're telling me... since recompiling a redhat kernel is such a hassle, is there a way i can remove the kernel i just installed?

btw, thanks for your answer.

Make sure you have support for ext3 filesystem. You have to make sure you have, otherwise the kernel will not be able to mount your partitions :)

Yes, just make sure you delete any reference to the newly compiled kernel from: /boot, /lib/modules, and edit your /etc/grub.conf in order to take out any instance of it.
This should do it.

I have some additional questions regarding the difference between kernel modules and compiling into kernel. For example: should the different ACPI modeules like processor, fan and battery be compiled into kernel or should those be set as modules and is there some kind of a referance document which specifies the correct setting for difftent options or is it just a “personal preferance” whether something will be a modele or part of the kernel.

And thank you for the great guide to comiling the kernel. I am firly new to linux and without this guide I would probably never attempt to compile my own kernel.

It is most adviseable to compile as many things as you can as modules, in that way, you can stop execution of that particular kernel code at run-time, by simply un-loading such a module, whereas compiled directly into the kernel, if the module fails, you most probably would have to re-boot your computer in order to get your system back to normality.

As for documentation, I''ve been unable to find more than that supplied by the kernel itself, either in the form of Help tid bits, or in the Dcumentation directory (which is, needless to say, adviseable for you to read).

Regarding your question about ACPI, compile just as modules... remember to keep your core kernel as light as possible.

Thanks man...to remove the kernel I used the script you made on that other thread and it was easy as nothing... then I edited the grub.conf and now it's back to normality... btw, what do you advice redhat users to do when it comes to compiling or patching the kernel? should we just stick to the kernel available thru up2date (for some reason redhat upgrades kernels realllly slowly) and just compile any features we want onto the current kernel?

As a matter of fact, I only would recommnd any Red Hat user to compile their own Vanilla Kernel in the event that there are problems with the current official Red Hat kernel, you have either a device that is not working or it's working un-properly, or simply if you are (like me) a hard core gamer, who wants the most out of your system, and you simply like Red Hat way of things (you could always try another distributions, like Gentoo, for instance).

I really compile my own kernel due to two things: Some of my hardware works best with the most recent kernel drivers (needless to say that two versions behind wont help much), and because there are known issues with official Red Hat kernels and some gaming situations, most noticeably WineX and some old DXdraw games (StarCraft, WarCraft II, even Diablo; or Monkey Island 3, etc, etc); and you come to the conclusion it is because of a kernel problem that lags these processes and gives them less priority. Again Red Hat sacrifices speed for stability (which for most enterprise/Home users is OK, just not for gamers). That is why I compile my own kernels :)

Well i haven't try it all ready (it's too lait and in a few hours a have a school to go to) but, i can assure you i will make a kernel compilation next thing after school. I had a couple of failed recompilation of kernel my self (no sound, no 3d hardware acceleration, no 32 bit colour depth).

In short: YEAH, WE NEED THIS KIND OF POSTS! AND THANK YOU!