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 www.kernel.org. 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 www.kernel.org
squashfs3.2-r2.tar.gz from squashfs.sourceforge.net
reiser4-for-2.6.20.patch.gz from namesys.com, local copy here, or
reiser4-for-2.6.21.patch.gz from namesys.com, local copy here, or
reiser4-for-2.6.22.patch.gz from namesys.com, 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.
For more on this, see the article: The Linux Kernel Saboteurs.
Change to the directory /usr/src/.
tar -xf linux-2.6.20.tar.bz2
tar -xf squashfs3.2-r2.tar.gz
Change to the new kernel source directory.
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:
Now run menuconfig (or xconfig or gconfig)
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> 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 --->
<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, but do not un-install your presently working kernel) 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, but do not un-install your presently working kernel) 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.
To install it, use:
tar -xf /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/System.map (becomes /boot/System.map-2.6.20)
/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:
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/
reboot 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:
./NVIDIA-Linux-x86_64-1.0-9755-pkg2.run (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. For examples of this sabotage, see: The Linux Kernel Saboteurs.
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, namesys.com.
The 2nd article in the guide to installing Linux on a Reiser4 partition, can be found here.