So, you have downloaded the needed RPMs mentioned on the Preparations page and you are ready to go for it. Take your time. Don't panic if you encounter errors: the current kernel is stored safely in system memory and on your disk. As long as you install the new kernel along the old one and you have a boot floppy at hand, nothing serious can happen.

Installation

Download all the kernel RPMs you need to a local directory, 'cd' to that directory, switch to the 'root' account and run

rpm -i kernel*

If you got all the packages, that should work out fine. You might use M's 'urpmi' instead of pure 'rpm'.
Notice that you can't have two different versions of the packages 'kernel-source' and 'kernel-headers' installed.

Once you have successfully booted the new kernel, you should generate a new boot floppy via the Mandrake Control Center or the 'mkbootdisk' script.

section index top

Checking System Configuration

Usually you don't have to do anything at all with the exception of those who are booting from RAID or SCSI devices: the RPMs do all the necessary configuration upon installation and the system initscripts check upon each boot which kernel you are booting and are changing the symlinks in the '/boot' directory accordingly.

If you need SCSI or RAID devices at boot time, create a new 'initrd image':

mkinitrd /boot/[initrd image] [new kernel version]

You can choose any name for [initrd image] as long as it is different from the old one. You have then to add entries for this image either to '/etc/lilo.conf' or '/boot/grub/menu.lst'. Older versions of M featured a standard 'initrd' entry in '/etc/lilo.conf', remove it if you don't need it.

section index top

Checking LiLo Boot loader Configuration

Open the file '/etc/lilo.conf' in your favorite editor or use 'DrakBoot' in the Mandrake Control Center. You will notice that it now contains another entry for the new kernel at the end of the file.
The only things you might want to change is the label of the new and / or the old kernel and which kernel should be booted by default.
If you are doing this in an editor, do not forget to run the lilo command afterward, otherwise changes made in '/etc/lilo.conf' will not take place in 'Lilo'.

section index top

Checking GNU GRUB Boot loader Configuration

Installing a new kernel will add an entry to '/boot/grub/menu.lst' with the kernel version as the menu entry. A standard 'menu.lst' file will then look like this:

timeout 5
color black/cyan yellow/cyan
i18n (hd0,0)/boot/grub/messages
keytable (hd0,0)/boot/us.klt
default 0
title Linux
kernel (hd0,0)/boot/vmlinuz root=/dev/hda1
[2 more entries]
title 2.2.16-9mdk
kernel (hd0,0)/boot/vmlinuz-2.2.16-9mdk root=/dev/hda1

(The line kernel (hd0,0)/boot/vmlinuz tells GNU GRUB: "boot a GNU/Linux kernel called 'vmlinuz' in the directory '/boot'. '/boot' is on the first partition of the first hard disk". The root=/dev/hda1 entry tells the kernel where '/boot' is located.)

You might want to adjust some things, either by loading '/boot/grub/menu.lst' into an editor or by using 'DrakBoot' in the Mandrake Control Center:

• Append an entry for an 'initrd' image, if needed (initrd /boot/[name of initrd image].
• default 0 boots the first entry by default. If you want to boot the new kernel by default, change the number to that of the entry (in this example it's the fourth entry, but since GNU GRUB starts counting from 0, the entry would be default 3).
• You might also want to adjust the title field from 2.2.16-9mdk to something more descriptive, like New Kernel.

Having made the changes, save the file (or choose 'Done' in 'DrakBoot') and reboot.

Having rebooted, run uname -r. This will tell you if your system is really running on the new kernel.

If everything has worked out fine, you can delete the old kernel RPMs with rpm -e or urpme to regain some hard disk space.

section index top

Rebuilding & Customizing the Mandrake Kernel SRPM

(Contributed by Mandrake Linux user Roger with kudos to the Mandrake Kernel team)

Prerequisites:

• A working knowledge of rpm (man rpm)
• Some past experience with building the kernel (read the README in the kernel source for building the kernel)

Process:

1. Download or obtain the 'kernel-2.4.xx.xmdk.src.rpm' and install it:

   rpm -ivh kernel-2.4.xx.xmdk.src.rpm

2. Now customize it to your liking by copying the config file from the SRPM to the Linux source directory and running the kernel configuration utility on it. After configuration, copy the the changed config file back:

   1. rpm -bp /usr/src/RPM/SPECS/kernel.spec

   2. cp /usr/src/RPM/SOURCES/kernel-2.4.xx.x-i586.config /usr/src/RPM/BUILD/linux/.config
   3. cd /usr/src/RPM/BUILD/linux/
   4. make xconfig
   5. cp .config /usr/src/RPM/SOURCES/kernel-2.4.xx.x-i586.config

3. Now start the build process:

   rpm -ba /usr/src/RPM/SPECS/kernel.spec

It will take along time to build as the mdk kernel.spec wants to build everything (documentation, enterprise, smp, up, secure, etc). You can further tell the kernel.spec not to build what you don't want by either editing the top of the kernel.spec file yourself or doing:

rpm -ba --without enterprise --without smp (the top of the kernel.spec file contains complete list of options)

If you have an i686 platform, the rpm build might complain something about the arch. You'll need to:

cp /usr/src/RPM/SOURCES/kernel-2.4.xx.x-i586.config
/usr/src/RPM/SOURCES/kernel-2.4.xx.x-i686.config

In Closure:
Mandrake does a very good job of making sure that the max amount of modules are built and available to users while making sure of compatability. So, if you try to slim down your kernel, you may find that it might break the build because you either: a) choose not to build some module required by other modules or, b) you choose to build a module which was experimental or has problems building statically instead of only as a module.

So, I usually only worry about providing explicit support for my i686 cpu's and maybe to adjust the APM module. I keep it simple incase the build does break. This way, I'll have an easier type debugging.

Note: Users can also denote which patches they want omitted from the build process, but this is more of an advanced topic as it requires one to actually READ & UNDERSTAND the kernel.spec scripting.

Usually, tho, if a person wants to omit a certain patch (because of conflicts with a 3rd party driver or "what not"), they would simply comment-out the patch# listed within the top of the kernel.spec after tracing the patch number back to the "title of the patch source".

Upgrading via compiling