Share your knowledge at the LQ Wiki.
Go Back > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Linux - Kernel This forum is for all discussion relating to the Linux kernel.


Closed Thread
  Search this Thread
Old 09-07-2007, 06:43 PM   #1
Registered: Aug 2007
Posts: 92

Rep: Reputation: 15

Compiling a new Kernel (and Reiser4).

This is the first of three articles to help you get your favorite Linux distro running on Reiser4 (that is, to get Linux installed, and functional, on a partition formatted with the Reiser4 filesystem). If you are not interested in Reiser4, then this first article, can be considered a guide to recompiling your kernel.

Download a recent kernel from I will use the linux-2.6.20 kernel, as it has a decent Reiser4 patch (since writing this NameSys has also provided a 2.6.21 patch). I will patch this kernel so that it understands the Reiser4 and Squash filesystems, but if you wish, you can totally forget about the Reiser4 and/or Squash filesystems, by ignoring the commands in blue.

If you use a different kernel, or other patches, you will have to change various details.

It is assumed that you are the root user.

First, make sure that you have the following programs and packages installed.

For SuSE 10.0: gcc libgcc glibc glibc-devel glib2 glib2-devel ncurses ncurses-devel gcc-c++ libstdc++ libstdc++-devel.

For Debian 4.0-r0 (Etch): emacs21 bzip2 gcc libncurses5-dev (libc6-dev linux-kernel-headers) libc6-dev-i386 (lib32gcc1) g++ (libstdc++6-4.1-dev). The bracketed items are installed automatically when the previous item is installed. The linux-kernel-headers are deceptively named. They are really libc headers and are installed to /usr/include/ (although similar files also occur in the kernel sources).

Then, download the following:

linux-2.6.20.tar.bz2 from
squashfs3.2-r2.tar.gz from
reiser4-for-2.6.20.patch.gz from, local copy here, or
reiser4-for-2.6.21.patch.gz from, local copy here, or
reiser4-for-2.6.22.patch.gz from, local copy here.

Save them to /usr/src/.

If you plan to use, both the linux-2.6.20 kernel, and compression, you may wish to use Riffard's patch from here. Riffard's patch works well for the more complex case of transparent compression (in fact, it seems faster) but causes corruption for plain Reiser4. Thus, we have the weird situation where the more complex case works fine, while the kernel "developers" "struggle" to get the simple case to work like it used to.

Change to the directory /usr/src/.

cd /usr/src/

Unpackage everything.

tar -jxf linux-2.6.20.tar.bz2
tar -zxf squashfs3.2-r2.tar.gz
gunzip reiser4-for-2.6.20.patch.gz

Change to the new kernel source directory.

cd /usr/src/linux-2.6.20/

Patch the kernel for the Reiser4 and Squash filesystems. You may wish to use the --dry-run option.

patch -p1 < /usr/src/reiser4-for-2.6.20.patch
patch -p1 < /usr/src/squashfs3.2-r2/kernel-patches/linux-2.6.20/squashfs3.2-patch

Copy the original kernel configuration file (that came with your distro) to .config

cp /boot/config-2.6.13-15-default /usr/src/linux-2.6.20/.config (SuSE)
cp /boot/config-2.6.18-4-amd64 /usr/src/linux-2.6.20/.config (Debian)

Look at the available kernel building options, with the command:

make help

Now run menuconfig (or xconfig or gconfig)

make menuconfig

On saving, menuconfig will have automatically updated the old .config file, to a current one. It turns out that "make menuconfig" is the same as running "make oldconfig" and continually hitting enter, to obtain the default option.

Now make the following changes:

File systems  --->
    <*> Reiser4 (EXPERIMENTAL)

File systems  --->
    Miscellaneous filesystems  --->
       <M> SquashFS 3.2 - Squashed file system support
<*> means that the feature is compiled into the kernel.
<M> means that the feature is compiled as a module.
< > means that the feature is ignored.

If you plan to install a Linux distro on a Reiser4 partition, then compile it into the kernel. Otherwise, just compile Reiser4 and Squashfs as modules. The Squashfs driver should be built as a module. This is because it will only be used on rare occasions. Building a driver as a module, means the size of the kernel is only increased when the driver is used. If you compile the driver into the kernel, then the kernels size increases forever, even when you are not using the Squash filesystem.

By "accident" the SuSE and Debian kernel configurations have both been changed slightly from what they actually were. This is apparent, as there is no ATA support in the configurations, yet the modules needed for ATA support mysteriously turn up in the initrd. This "accident" means, that many who compile their own kernel, will find that it will not boot. It seems that only one trap of this sort has been laid, and you can avoid it by configuring all the Serial ATA and Parallel ATA drivers, as modules.

Device Drivers  --->
   Serial ATA (prod) and Parallel ATA (experimental) drivers  --->
      <M> configure all 55 drivers on this page as modules
      <M> ------------ 
      <M> configure all 55 drivers on this page as modules
Of course, if you have no SATA or PATA disks or DVD's, then you can forget this. However, configuring them as modules doesn't hurt, the modules will just not be used, and, if in the future you add such a disk, or DVD, the drivers will be waiting.

If you had been given the real configurations for the old kernels, you would not need to make any alterations to the new configurations (made by "make menuconfig") except to add new features. If you have a recent CPU, one new feature you may be interested in, is the kernel virtual machine support:

Device Drivers  --->
  Virtualization  --->
     <M> Kernel-based Virtual Machine (KVM) support
     <M> KVM for Intel processors support
     <M> KVM for AMD processors support
If there is any chance of overwriting an old kernel, adjust the "local version" option to avoid this.

General setup  --->
     (-my-kernels-name) Local version - append to kernel release
SuSE adds (-default) here. Debian, adds () nothing. I used ().

Ideally, you should compile all the drivers necessary to boot your system into the kernel (ie, drivers necessary to boot your system should not be built as modules). If you do this you will not need an initrd (initial ram disk) file. However, it is very difficult for someone who is new to compiling kernels, to be able to choose all the right features.

Since I wish this guide to be of use to everyone, I have tried to make it as simple as possible and have included the construction of an initrd file. If you are new to all this, then I suggest you do not compile the drivers (necessary to boot your system) into the kernel. Only, after having successfully built a new kernel and gaining some experience, should you try this. However, even with a little experience, your attempts to compile in all the necessary drivers, will often be rewarded with kernels that refuse to boot.

After adding any other interesting features that seem desirable, you should try to compile the new kernel. If you are using a distribution like SuSE, Mandriva, or Red Hat, you should build a RPM package with the command:

make binrpm-pkg which packages just the necessary stuff, or
make rpm-pkg which also packages the source code.

This can take quite a while, as we are building a large number of unnecessary (but potentially necessary) modules. When built, the RPM package is put in /usr/src/packages/RPMS/ under your architecture type. Install the package (you may have to un-install previous installs) with:

rpm -i /usr/src/packages/RPMS/x86_64/kernel-2.6.20-1.x86_64.rpm

You may wish to use the --test option if you are unsure how things will go. This will run through the install process, without actually doing the installing.

If you are using Debian, create a .deb package with:

make deb-pkg (Debian)

This can take quite a while. When built, the .deb package is put in /usr/src/. Install the package (you may have to un-install previous installs) with:

dpkg -i /usr/src/linux-2.6.20_2.6.20_amd64.deb

You may wish to use the --dry-run option if you are unsure how things will go.

Un-installing packages is a little unusual, as the installed name is not quite the same as the name of the package you install. Given a package, you can find its installed name with:

rpm -qp --info kernel-2.6.20-1.x86_64.rpm (SuSE, Mandriva, Red Hat, etc)
dpkg --info linux-2.6.20_2.6.20_amd64.deb (Debian)

Once you know the name/version, you can uninstall it with:

rpm -e kernel-2.6.20 (SuSE, Mandriva, Red Hat, etc)
dpkg -P linux-2.6.20 (Debian)

Of course, in Debian you can also use synaptic to uninstall the package.

For distributions not covered so far, use "make tar-pkg" or "make tarbz2-pkg" or build your kernel manually.

make tarbz2-pkg

To install it, use:

tar -jxf /usr/src/linux-2.6.20/linux-2.6.20.tar.bz2

The main kernel files, before packaging, can be found here:

/usr/src/linux-2.6.20/ (becomes /boot/
/usr/src/linux-2.6.20/.config (becomes /boot/config-2.6.20)
/usr/src/linux-2.6.20/arch/x86_64/boot/bzImage (becomes /boot/vmlinuz-2.6.20)

The modules, pci-tables, etc, are installed to /lib/modules/2.6.20/.

If a certain section of the code does not compile, then return to menuconfig and turn it off in the configuration. Then rerun "make the-pkg." If you absolutely need the feature corresponding to that section, then try a different kernel.

If you decided to compile in, all the drivers you need to boot, then you will NOT need an initrd file. Otherwise, you will need an initrd file. To build it use the command:

mkinitrd -k vmlinuz-2.6.20 -i initrd-2.6.20 (SuSE)
update-initramfs -c -k 2.6.20 (Debian)

Note that, if you do not specify a kernel, mkinitrd will make initrd files for all the kernels it finds.

Now you need to reconfigure GRUB. You need to change the menu.lst file.

emacs /boot/grub/menu.lst &

Do NOT delete the old boot entry. Keep it, so you can still start your system if things go wrong. Cut and paste a copy of it above the original. Then adjust the copy for the new kernel.

The vga and bootsplash settings (vga=0x317 splash=silent) often cause problems and should be disabled until your new kernel is up and running. After which, you can add them back. Your GRUB entries should look something like:

For SuSE:

title SUSE LINUX -- My New Kernel 2.6.20
root (hd0,2)
kernel /boot/linux-2.6.20 root=/dev/hda3 resume=/dev/hda5
initrd /boot/initrd-2.6.20

title SUSE LINUX 10.0
root (hd0,2)
kernel /boot/vmlinuz-2.6.13-15-default root=/dev/hda3 resume=/dev/hda5 vga=0x317 splash=silent
initrd /boot/initrd

For Debian:

title Debian GNU/Linux -- My New Kernel 2.6.20
root (hd0,1)
kernel /boot/vmlinuz-2.6.20 root=/dev/sda2 ro
initrd /boot/initrd.img-2.6.20

title Debian GNU/Linux, kernel 2.6.18-4-amd64
root (hd0,1)
kernel /boot/vmlinuz-2.6.18-4-amd64 root=/dev/sda2 ro
initrd /boot/initrd.img-2.6.18-4-amd64

Other distros, are handled similarly. Note that I have Debian on the 2nd partition and SuSE on the 3rd. You will have to adjust the (hd0,1)'s and /dev/sda2's etc, to suit your situation. With the above changes, the new kernel will be listed on the GRUB menu at boot.

If you do not have a NVIDIA or ATI accelerated graphics system, just reboot and see how things are.

Otherwise, before rebooting, you need to take care of these proprietary kernel modules. Unfortunately, I grew tired of ATI Linux drivers that never worked, and no longer have any ATI graphics cards on which to test things out. However, I now have a number of NVIDIA cards and can tell you what needs to be done in this case. First, you need to save your old NVIDIA kernel module, as the new install will delete it:

cp /lib/modules/2.6.13-15-default/kernel/drivers/video/nvidia.ko /tmp/


into single mode. You do this as follows:

When the GRUB boot menu appears:

1) Choose the SUSE/Debian -- My New Kernel 2.6.20 entry by using the arrow keys.
2) Type the letter e (as opposed to the usual return).
3) Use the arrow keys to select the kernel line.
4) Type the letter e (edit) again.
5) Edit the kernel line by adding the word single (or S) at the end.
6) Hit return.
7) Type the letter b (boot).

Of course, you could have temporarily added the word single (or S) in your menu.lst file, instead.

If your new kernel is OK, you will boot to a console where you can run the NVIDIA install script (which you can download from NVIDIA). Change to the directory containing the NVIDIA install script and run it with:

./ (note the ./)

Answer all the questions (say you do NOT want to download a module from NVIDIA).

Move the saved NVIDIA kernel module back:

mv /tmp/nvidia.ko /lib/modules/2.6.13-15-default/kernel/drivers/video/nvidia.ko

You will need this to boot your old kernel into graphics mode.

Now, reboot again and you should have your old system back, but with a brand new Reiser4 understanding kernel.


Both Laurent Riffard and Andrew Morton, have also provided Reiser4 patches. I have found these patches often do not work and/or have important functionality missing. Strangely, Riffard's patches causes corruption for plain Reiser4, but the more complex case of transparent compression seems to work just like it used to. So, we have the weird situation, where the more complex case works fine, while the simple case no longer works. For this reason I have not bothered with Morton's mm kernels, but who knows, maybe they have improved (but this is very unlikely). The reason for this strangeness is that certain kernel developers are quietly sabotaging Reiser4.

Of course, to use Reiser4 you also need to download, and compile, the libraries libaal-1.0.5.tar.gz and the programs reiser4progs-1.0.6.tar.gz from Hans Reiser's company,

Last edited by reddazz; 09-09-2007 at 02:36 AM. Reason: removed urls
Old 09-07-2007, 11:00 PM   #2
LQ Guru
Registered: Nov 2003
Location: N. E. England
Distribution: Fedora, CentOS, Debian
Posts: 16,298

Rep: Reputation: 77
Can you please resubmit this article to our tutorials section. Leaving it as a normal thread will just result in the article being buried and probably forgotten. Cheers.

Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Reiser4 and the politics of the kernel LXer Syndicated Linux News 6 09-05-2007 08:07 AM
LXer: Linux: Why Reiser4 Is Not in the Kernel LXer Syndicated Linux News 0 07-18-2006 03:33 AM
Unable to compile Reiser4 Support into 2.6.12 kernel SlackwareInAZ Slackware 11 07-19-2005 01:12 PM
Unable to patch kernel with Reiser4 mm patch SlackwareInAZ Slackware 9 04-26-2005 06:33 AM
reiser4 and wireless driver module-> 4kb kernel stacks? aminalshmu Linux - Hardware 0 08-29-2004 02:13 PM > Forums > Linux Forums > Linux - Software > Linux - Kernel

All times are GMT -5. The time now is 08:57 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration