Here is how I (Note from Marco: very probably this is from M. Fratoni, but I can’t remember for sure, sorry) used a fast computer to recompile the Linux kernel that came with rh9 to obtain vmlinuz-2.4.20-8RULE, the kernel RULE provides for boxes with older cpu’s than a 586, :
At the start
Box1 is a faster box running rh 9. It boots into KDE and the kernel sources package is installed. Box2 is an older box on which there is a RULE install of rh9 (Slinky was the installer). You will need to transfer files too large for a floppy from box1 to box2. I used nfs (a file sharing for a lan under Gnu/Linux). Firstly is a list of the actual commands. Then a few gotcha’s with ways around them. Lastly, there is a more detailed description of the process.
My actual commands on box 1
mv /boot /boot.orig cp -a /boot.org /boot mv /lib/modules /lib/modules.orig cp -a /lib/modules.orig /lib/modules (inserted rh9 cd 2) mount /mnt/cdrom rpm -ivh /mnt/cdrom/RedHat/RPMS/kernel-source-2.4.20-8.i386.rpm umount /mnt/cdrom (removed cd) cd /usr/src/linux-2.4.20-8 (now starts what I call cycle 1) (I already had RULE's kernel config file and copied it here, naming it co) vi Makefile (I chose extraversion=-sbpcd-1 and saved and closed vi) make mrproper make xconfig (clicked load configuration button and typed in the name co) (clicked the first section and said no to experimental options) (left the ability to load modules) (clicked the cpu section and chose 486 for my box2) (decided to leave all the rest this cycle and clicked the Save and Exit button) make oldconfig (these next two lines are actually all on one line) make dep && make clean && make bzImage && make modules && make modules_install && make install cp .config /boot/config-sbpcd-1 cd /boot ls -l rm -Rf grub rm -iv * (carefully said yes for everything except config-sbpcd-1, initrd-2.4.20-sbpcd-1.img, System.map-2.4.20-sbpcd-1, vmlinuz-2.4.20-sbpcd-1) cd mv /boot /boot-sbpcd-1 cp -a /boot.orig /boot
My actual commands on box 2
(boot with working kernel and login as root) (the nic gets recognised and the lan goes up) (/etc/fstab already has an nfs entry for box1) mount /mnt/box1 cd /boot cp -v /mnt/box1/boot-sbpcd-1/*-2.4.20-sbpcd-1* ls -l ln -s initrd-2.4.20-sbpcd-1.img initrd-1.img ln -s System.map-2.4.20-sbpcd-1 System.map-1 ln -s vmlinuz-2.4.20-sbpcd-1 vmlinuz-1 ls -l cd cp -a /mnt/box1/lib/modules/2.4.20-2.4.20-sbpcd-1 /lib/modules vi /etc/lilo.conf (add lines identical with those for the original kernel but use the new symbolic link names) (save and close vi) lilo (if there are errors go back and fix things) shutdown -r now (reboot with new kernel) (if it doesn't work as you want, call this cycle bad, go back and change less than before) (if all goes well, this cycle is good and move on to the next)
now starts the next cycle
On box1
cd /usr/src/linux-2.4.20-8 (if not already there) mv .config co (if the previous cycle was a success it is okay to overwrite the old co)
OR
mv .config co-bad mv co co-good (if the previous cycle was a failure, keep both and compare) (all the rest is the same as above just adjust the extraversion)
next, before closing down box1:
mv /boot.orig /boot mv /lib/modules /lib/modules-tests mv /lib/modules.orig /lib/modules
The gotcha’s
Possible problem 1
Box1 was a 486SX with hda a 1.0 GB drive. When I first set it up, the partitions were: hda1 was the swap for fastest access, hda2 was extended, and hda5 was the first and only logical taking all the available space. The plan was to have ample space in which to experiment. I’m a relative newbie so I did several compilations with different configurations before I found something useful. On the first couple of tries Lilo could see the kernels and started booting them. Even though I erased each failure before putting another I managed to get to the point where a new kernel landed up beyond the invisible but important boundary of 1024 cylinders. The tell tale sign is an error 04 and a halt. Now I’m stubborn about leaving the swap at the faster hda1 slot, so I repartitioned the extended into a small (5MB) logical (hda5) with the mount point /boot and the rest as hda6 with the mount point /. This resulted in each new attempt being placed inside the same 5 MB space which was inside the aforementioned invisible boundary!
Possible problem 2
Newer versions of the kernel than 2.4.20 tempted me and I had some from magazine cd’s. These were so- called “vanilla” kernels, i.e. they are unpatched and will compile with almost any minimum config you can dream up. Only problem was that RULE is running an almost standard rh9 (even if on a strict diet!) so when it boots the kernel it expects certain capabilities (some of which are not really necessary for such an install but as a newbie I don’t know what should go and what should stay.) Some of this has to do with what goes in the configuration and some with what has been “patched” in by rh. To make a long story shorter I stuck with the same version of kernel and used the source package which makes a kernel already “patched” by rh. This still leaves the configuration to play with. 
Possible problem 3
Choosing the right configuration is the one part of this whole process that is really challenging – at least for a newbie like me. Having box1 allowed me to use the gui front-end. There is a small help window for almost every option. Also, it allows for going only to sections you want to change in any particular cycle, saving and exiting.
Possible problem 4
Stock config files come with the package and RULE has its own config file. One of these will compile into a kernel that boots (and you don’t have to know why) but none of these gave me a kernel capable of recognising my cdrom. I started out using the motto “less is more”. Nothing like a lean kernel having nothing more than what I need (I said to myself.) Saying no to almost everything proposed in the config process results in a kernel that won’t compile! Even when I relented to the point where it would compile, box2 couldn’t boot it or when it could there were some “failed” messages (in red) when before there were all “ok” green ones. There is a saying in Greek (I live in Greece – the only reason I know this) whoever hasn’t the sense, has to use his/her feet. In this case, as I had only a bit of an idea what to leave in and what to leave out, I decided to start with RULE’s config file and, knocking off a little at a time, found that most of the time the kernel both compiled and successfully booted in box2. However, it took a lot of time before arriving at a lean, working kernel.
Possible problem 5
The gui front-end is a great tool but it sometimes fails to clean out options that had been chosen on an earlier try and are now no longer applicable because this time you said no to some option(s) which previously you said yes or module to. As always (well, nearly) someone else already had this problem and asked and someone else supplied the solution (long live the community!) All I am doing is passing it on… Look for it in step 10 in the process coming up.
Possible problem 6
Remember, this was not done using a vanilla kernel source. Some options had to be left in, so that ther would be no errors. These were pci and pci-related in General Setup, Enhanced Ide in Ide Chipset Support and I2C Support within Character Devices.
Are you still here?The process explained
Once the kernel source package is installed or the tarball has been unpacked in the subdirectory /usr/src (use the rh package, it’s simpler) it makes little difference whether it is the very first try or a subsequent one. Just follow these steps, go into the gui environment, open a console and become the super user with su (be very careful.)
1 - Back-up the entire /boot directory so whatever else happens eventually it is restored to its original state. 2 - Many would say, back-up the /lib/modules directory, too.It can't hurt. 3 - cd into /usr/src/linux 2.4.20-8 (or whatever is the version you are working with.) 4 - In the first attempt (referred to as cycle 1) copy the config file from box2 which you find in its /boot directory. It provides a working start point but has far more options marked as yes or modules than a leaner kernel would need. Call this file co In any subsequent cycle look at the listing ls -A and look for two files, co which was the starting point for the previous cycle and .config which was the config file created subsequently in the same previous cycle. (There is also a file called .config.old which you definitely don't want.) If the previous cycle was a success you are only interested in .config so rename it co, overwriting the older co. If the previous cycle was a failure rename .config co-bad and rename co co-good, open each with cat in separate windows to help you plan what to do in this cycle - the strategy I recommend is load co-good in the gui front-end, do just some of what you tried last time, save and exit, and hope this time all your changes (now they're fewer than before) DO work. If you lost .config there is a copy of it in the directory /boot-extraversion of the last cycle. There, it is called config-extraversion. 5 - Using your favorite editor, open the file Makefile in this same directory, go down to the line that starts Extraversion = and put something useful. I put .sbpcd-1 for the first time and only had to change to the next number up with each new attempt (i.e. cycle.) Save it with the same name and in the same location. 6 - Type the command make mrproper It doesn't take very long but is important to eliminate leftovers from the previous cycle. (You did do step 4, I hope, because this clean-up deletes the files .config and .config.old if they exist) but won't touch your copy called co (or whatever you used) even though it is in the same location. 7 - Type the command make xconfig This invokes the gui front-end for creating your new configuration. 8 - Click on the load configuration button and type in the name of whatever file you want to start with in this cycle (a short name like co is handy at times like this.) 9 - Remember, use a system, start with the first unchanged (from last time) section, click your choices, and don't make so many changes in one go in case it winds up either not compiling or not booting properly and you need to go back over what you did. Click the Save and Exit button. 10 - At last, here is the solution to problem5 above! Type the command make oldconfig. This takes very little time, sorts out what extra options xconfig missed. If it stops to ask for input, just type no and it then resumes. The result renames what xconfig created, from .config to .config.old and creates a new file .config. 11 - Now type the multiple command make dep && make clean && make bzImage && make modules && make modules_install && make install Here is where you go have a long break; my box1 took two or three hours, depending on the configuration. If there is a serious error the process stops. In this case the kernel "won't compile" so go back to step 4. 12 - Copy the file .config with a helpful name to the /boot directory. 13 - Look at a listing of /boot now. All the files that were in /boot before this cycle should still be there together with the following new ones:(1) the config you just put in (step 12) (2) a new initrd-2.4.20-extraversion.img (3) a new System.map-extraversion (4) a new vmlinuz-extraversion (did it get smaller?) (5) (6) the two symbolic links System.map and vmlinuz are still there but they now point to the newly created files and (7) the grub.conf file in the subdirectory grub has had a new entry added (since my box1 uses grub.) Eliminate the subdirectory grub within /boot, all the files that were copies from the original /boot and the new symbolic links (you will recreate links with better names in step 16.) This should leave you with a /boot directory containing just the files (1) (2) (3) (4) described above. 14 - Rename /boot to /boot-extraversion corresponding to this cycle. 15 - Create a new /boot from the original back-up cp -a /boot.orig /boot 16 - Copy the four files from the renamed /boot (step 14) to the /boot directory in box2. Always leave at least one set of the four files (and their symbolic links) from the previous cycle which succeeded so that in case the new cycle won't work box2 can always boot from that cycle at least. cd to /boot on box2 and create symbolic links to the new files (2) (3) (4) in step 13 with short names, incremented one number to correspond to this cycle. 17 - Back on box1, look at the listing of /lib/modules/ You should now find a new subdirectory labelled with your latest extraversion. Now you can appreciate why you need to do step 5 each time with a meaningful system. Copy this new subdirectory over so the /lib/modules of box2 also contains this newly created subdirectory. If space is tight on box2 you can safely eliminate older subdirectories from older cycles so long as you keep the subdirectory corresponding to the one last successful cycle. This should match the labels of the older files kept in /boot in box2 mentioned in step 16. 18 - Use an editor on box2 to add correspondig lines to /etc/lilo.conf. Watch out for two things while editing: (1) make sure the default= a label that had existed and succeeded before. If instead it points to a cycle you needed to eliminate to make space, just change it to point to an older, good cycle that remains in /boot; (2) lilo objects if the names or labels are too long; if so, shorten the line label= (but do NOT change the names of any files in /boot.) Instead, refer to the symbolic links, which have shorter names. 19 - Type the command lilo on box2 and make sure it doesn't give an error. If it does, go back to step 18 or double check to see if /boot on box2 has the files you expect. 20 - Reboot box2 and if it boots the new kernel and dmesg doesn't complain of any "fails", check to see if you can do everything you could before: recognition of hardware, nfs-client and nfs-server (if needed) etc. If yes, this latest cycle is now good. Go back to the start if you're hoping for a leaner, better kernel in the next cycle.
Whenever you are going to shutdown or reboot box1, don’t forgetto restore both directories: /boot.orig to /boot and /lib/modules.orig to /lib/modules (watchout on the second restoration that you, first of all, archive or erase – it is your choice – the directory /lib/modules that contain the new extraversion sets you have been making.)