Kernel Krazy - Rebuilding the Redhat Engine

WARNING: Mechanic is NOT Licensed, use manual with CAUTION!

You can always recompile the Linux Kernel for a particular system and hence add functionality, or tweak it to get optimal performance. The fun part is that you don’t need to be a programmer to do this: there are built-in automated configuration scripts to help you out.

Optional Configuration Scripts:

The Standard Tool:
A sequential ‘make config’ that asks you hundreds of questions about almost every Kernel option that can be tweaked;

The Menu Config:
‘make menuconfig’ that gives you a menu-based interface to the same options;

The GUI Config:
‘make xconfig’ that gives you a graphical interface–quite like the menu-driven ‘make menuconfig’ in the X Window System.

But, before you set about exploring the exciting world of Kernel modules, make sure you have some necessary things with you. The first is the Kernel Source Code, itself. Almost all Linux distributions come with Kernel Source Code packages. You can install them using either the GnoRPM or KDE Package Managers, or manually, with the standard RPM Command Line. Just switch to the directory where the Kernel source RPMs exist and do an ‘rpm -ivh kernel-source*.src.rpm’. This should install the Kernel Source Code in the /usr/src/linux-x.x.xx directory, where x.x.xx is your version of the new Kernel.

Change to the /usr/src/linux-x.x.xx directory and run ‘make menuconfig’. This makes it easier to understand what each option means before you use them. If you’re running X, just type ‘make xconfig’ and you’ll get a GUI-based system to do the same work, while, in the ‘menuconfig’ mode, you can just type ‘?’ to access specific comments and help about a particular option. Make sure you read what a particular service can deliver before you plan to disable it. The same can be done in ‘xconfig’ mode by using the ‘Help’ button.

To ensure the Kernel re-mains small in size, load most options as Kernel modules rather than compiling them straight into the Kernel. Do this in the ‘menuconfig’ mode. A* in front of the option means it’s selected; an M means it’s to be loaded as a module; and a blank means the option is not selected. In the ‘xconfig’ mode, this is indicated by y (=”yes”), m (=”module”) and n (=”no”).

If you want to configure Linux for a server, you may want to eliminate support for things like sound cards, PCMCIA slots, unused file systems (everything except file systems like EXT2, DOS, ISO9660, Joliet and VFAT which are needed most of the time), IrDA support, Video for Linux, joysticks and amateur radio support. This makes the Kernel much smaller in size, without the risk of missing out on some devices.

If you feel you know what your system needs and fancy adventure, go into your computer’s network configuration to remove the extra network card drivers and tweak the TCP/IP options. That will make a difference, however small, in the Kernel size and performance. You can, of course, always select the processor type of your machine for compiling a Kernel optimized for that particular processor class.

Once you’ve made the selections, save your configuration to an alternate file for using it later, if needed. If using ‘menuconfig’, just select EXIT and it will ask you to save the configuration. Say YES, and it saves the configuration to the ‘makefile’. If you’re using ‘xconfig’, just choose Save and Exit.

Now ensure that you’re in the /usr/src/linux-x.x.xx and give the command ‘make dep’. This command ensures that all files needed for compiling the Kernel are in their proper place. Once this process is finished, type ‘make bzImage’ (note the ‘I’ is in the upper case). This begins the Kernel-Compile Process. In earlier Kernel versions, the command was ‘make zImage’–an option still available–which shows an error message saying the Kernel image is too large because it can’t handle the large-size code.

The Kernel takes time to compile. Be Patient! Once the process is complete and you don’t see any errors, you’ll have a file called ‘bzImage’ in the /usr/src/linux-x.x.xx/arch/i386/boot/ directory. This is your NEW Kernel.

Now RENAME this file and copy to the /boot directory, rename it to whatever you like ?kernel-test’. Then open /etc/lilo.conf or grub.conf (located in /boot/grub) in your favorite text editor. LILO will already have an entry used to boot your existing Kernel that looks something like this:

image=/boot/vmlinuz-x.x.xx-xx
label=linux
read-only
root=/dev/hda1

Clone this entry, as it stands, just below the last line in the file, and replace the ‘image=/boot/vmlinuz-x.x.xx-xx’ with ‘image=/ boot/kernel-test?. Now change the ‘label=linux’ to ‘label=TEST’. Save the file and exit the editor.

Quote:
LILO Sample:
image=/boot/vmlinuz-x.x.xx-xx
label=linux
read-only
root=/dev/hda1

image=/boot/kernel-test
label=TEST
read-only
root=/dev/hda1
Now type ‘lilo’ at the command prompt. This whole process adds your newly compiled Kernel to the boot list of lilo, the Linux loader, without removing your existing Linux Kernel. This ensures that even if the newly compiled Kernel doesn’t work as expected, you can still boot your machine with the older Kernel.

Now reboot your machine. And, the next time ‘lilo’ prompts to load an OS, just type or select ‘TEST’ to make a new Kernel boot-up. If this doesn’t work, don’t panic. Just reboot your machine and use the default Linux Kernel you used to boot it in the first instance and you’ll be back where you started.

This text is from www.fedoraforum.org.
I just show it on my page because the forum is so complex.

If you enjoyed this post, make sure you subscribe to my RSS feed!