This full static mirror of the Run Up to Date Linux Everywhere Project is kept online by Free Software popularizer, researcher and trainer Marco Fioretti. To know how you can support this archive, and Marco's work in general, please click here

RULE: using a fast computer to compile the Linux Kernel for a slow computer

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
  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,
  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
  ln -s vmlinuz-2.4.20-sbpcd-1 vmlinuz-1
  ls -l
  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)
  (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)


  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
  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
  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
  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 (4) a new vmlinuz-extraversion (did it
  get smaller?) (5) (6) the two symbolic links 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
  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.)

RULE = Run Up to Date Linux Everywhere
This entry was posted in Docs. Bookmark the permalink.