Mailinglist Archive: opensuse (4547 mails)

< Previous Next >
Compiling a Vanilla Kernel
  • From: Bruce Marshall <bmarsh@xxxxxxxxxx>
  • Date: Sun, 23 May 2004 10:50:47 -0500
  • Message-id: <200405231150.47352.bmarsh@xxxxxxxxxx>
Someone asked for directions for compiling a 'vanilla' kernel from

Below are some notes on how to do that.... Feel free to shoot holes in it.

I download the kernel files to a directory named '/ftparea' so the following
instruction will use that in the examples.

I would think that the module-init-tools that come with 9.1 would be the
latest because the tools haven't changed in quite awhile. But remember that
whenever you go to grab a new kernel from, that you should check
to see if there is a newer version of module-init-tools in:

The latest module-init-tools is: module-init-tools-3.0.tar.gz

Assuming you have downloaded:



1) cd /usr/src

2) rm -r linux (removes sym link to current kernel source but does not
erase the main directory)

3) tar xjvf /ftparea/linux-2.6.6.tar.bz2 (extract the new kernel source
into /usr/src/

4) ln -s linux-2.6.6/ linux (make a new symlink)

5) cd linux

6) make mrproper

Note: Make mrproper should be issued just once, immediately after you load up
the new source files. make mrproper will do some setup but it WILL ALSO GIVE
YOU A DEFAULT .config file. The .config file is your configuration file.
Since you are going to be making changes to the .config, you don't want to
lose those changes later on after spending a lot of time configuring your

7) make xconfig (see notes below)
8) *** Not used for 2.6.x kernels but does no harm. make dep
9) make clean
10) make bzImage (note the capital 'I')
11) Assuming no errors, make modules
12) Assuming no errors, make modules_install
13) cp -p arch/i386/boot/bzImage /boot/vmlinuz.266
14) Modify /boot/grub/menu.lst
a) copy your current kernel line(s) to a new group and modify with the name
of the new kernel (vmlinuz.266)
b) Remove the entry for mkinitrd if you compile everything needed at boot
time into the kernel (best). Otherwise make a new initrd file for the new
kernel and name it properly. (mk_initrd)

15) Re-boot

That's it!

At this point (after 15 above) you would have:

1) A new kernel for 2.6.6 in /boot which is separate from your current
kernel (use uname -r to see the name of any running kernel)
2) A new entry in /boot/grub/menu.lst that is separate from your current boot
3) A set of modules that are totally separate from your current modules.
(see /lib/modules)

In otherwords, everything is separate! and you can always reboot to the
original (current) kernel. Nothing has been destroyed. Play to your hearts

Now for a few additional notes: (you knew that was coming, didn't you :o)

Note: All of the above assumes you have the needed parts to do a kernel
compile such as the gcc compiler. You may have to load things that have
been missed.

Step (8) make xconfig

The above assumes you are running under KDE or some gui interface. If not,
use: make config or make menuconfig for text mode. (there are other
ways of setting up a .config) If you get an error about a display not being
available while running as root in a term console, go back to being a
normal user and issue 'xhost +' and then go back as root and continue where
you left off.

Now... you can always bring over a .config file from a previously compiled
kernel (such as 2.6.5 if you had compiled for that) but in the case of
using the stock SuSE kernels, I would suggest that you branch off and start
fresh. The SuSE kernel has almost every bell and whistle turned on since
they don't know what hardware will be running.

There is a way to bring over an SuSE .config called cloneconfig but I've
never used it. In fact, I have to admit that I have never done anything with
the SuSE versions of kernels but feel that I have avoided a LOT of problems
because of that.

The make xconfig will present you with a LOT of options, many of which
you won't know anything about, but there will always be a HELP button or
information to click on which will explain the option. (the explanation
will sometimes go over your head too but they usually give a 'best option'
suggestion such as "if you don't know whether you want the hydradublicab
option, say No here")

Plan on spending some time with the xconfig but you will learn a LOT about
linux in the process.

Modules: It is good in almost all cases to check off any options you want as
'modules' rather than have them compiled in if there is a modules option.
The one exception to this rule is for hardware items that are needed at boot
time. For example, compile in the drivers needed for your HD's and your
eth0 interface (if any). Compile in ANYTHING needed at boot time since (a)
then you won't have to worry at all about INITRD problems and b) there's no
sense in making them modules anyway since they would get loaded right off and
stay loaded forever. (see /etc/sysconfig/kernel and the label INITRD_MODULES
for those things currently in mkinitrd. Best to compile them into the

But for most options, there's no harm in making things modules and in fact,
there may be options you're not sure you want but if they are made as
modules, they really don't cost you anything in storage or performance if they
are not used, yet they are there to use if/when you wish.

Your hardest item in the above lists will be making up the .config, but
once you've made it up (about a 1/2 hour) you're pretty well covered for
ever. You can bring forth any .config file for new kernels and you will by
then know enough about the .config process that it won't take long to start
from scratch.

It may take you a couple of tries to find the right option mix. In general
this is not a problem, but it *is* possible to pick an option that might
conflict with another and cause a compilation error or have some hardware that
isn't picked up properly.

You will lose your graphical boot screen  (the initial one where all the boot
messages fly by) when you use a vanilla kernel.   Some people think this is a
big loss but then, if you boot that often, maybe you have bigger
problems.  :o)  There are supposed to be some patches on the SuSE site to put
it back if you really have to have it.

I didn't mention how to add a new boot item to lilo.

I don't use lilo but basically you take your current boot-definition such as:

  image  = /boot/vmlinuz
  label  = linux
  root   = /dev/sda6
  initrd = /boot/initrd
  append = "enableapic"

and duplicate it with a new label and new image:

  image  = /boot/vmlinuz.266
  label  = linux-2.6.6
  root   = /dev/sda6
#  initrd = /boot/initrd
  append = "enableapic"

Note that I have commented out the initrd.  That assumes you have compiled
the necessary drivers into the kernel as I described.  Take a look in
/etc/sysconfig/kernel  for the line:

INITRD_MODULES="aic7xxx scsi_mod xfs"

for the modules which are needed at boot time.  These are the drivers that
should be compiled into the kernel.


< Previous Next >
Follow Ups