Next Previous Contents

2. Binary install / upgrade

This chapter explains where to get and how to install (pre-built) binary kernels on the NetWinder. This is the most common form of upgrade that may be performed, and should be used by most people.

I'd like to stress the previous point. The official NetWinder kernels already contain pretty much all the drivers and functionality that you need (either built-in, or as loadable modules). In general, there should be no need to rebuild the kernel since all NetWinder models have the same hardware in them. If you are a driver author, please consider submitting your driver so it can be included in the official builds.

2.1 Preparation

Before installing a new kernel, it is wise to update the firmware as well. In particular, if you currently have a 2.0 kernel, then the firmware on your machine will probably not be able to boot a 2.2 kernel successfully. The version of the firmware is displayed on initial power-up of the NetWinder.

Firmware versions before 2.0.8h should definately be updated. At the time of writing the current version is 2.1.24, though there have not been any major changes since version 2.1.16. For information on how to update the firmware, please see the http://www.netwinder.org/~ralphs/howto/Firmware-HOWTO.html.

2.2 Where to get binaries

Official binaries for the NetWinder are available from ftp://ftp.netwinder.org/pub/netwinder/kernel/. They are distributed in RPM format for ease of installation. Kernels are identified by their official version number (eg. 2.2.13) suffixed with the release date (in the form YYYYMMDD). For each release there are two binary RPMS that should be downloaded:

        kernel-2.x.y-YYYYMMDD.armv4l.rpm
        kernel-headers-2.x.y-YYYYMMDD.armv4l.rpm

The first package contains the kernel itself and the loadable modules, the second package contains the corresponding header files. The latter will be required to compile applications and hence it is recommended that you always update both of these packages together.

2.3 Installation

Once the two RPM packages have been downloaded to the NetWinder, installation is accomplished with the usual RPM command sequence. Note that you must be logged in as root to execute these commands.

        rpm -ivh kernel-2.x.y-YYYYMMDD.armv4l.rpm
        rpm -ivh kernel-headers-2.x.y-YYYYMMDD.armv4l.rpm

Note to RPM veterans: unlike most other packages, you should not use the -U (upgrade) option on the kernel packages, just to be on the safe side. This is because `upgrade' will remove the old kernel version, possibly leaving you with an unbootable system. See the `Behind the scenes' section below for more details.

If the RPM fails to install, check that it was downloaded in binary mode - repeat if necessary. If that still doesn't work, then chances are, your machine has an old version of rpm. Consider upgrading to a more recent disk image (consult the Disk-Update-HOWTO).

2.4 Trying it out

The NetWinder needs to be rebooted in order to boot the new kernel. However before doing that, it is a good idea to record the names and version of the exising kernel on your system. In case the new kernel doesn't work on your machine, you will then be able to go back to the old version. The following command will list the names of the kernels installed on your system (including the new kernel you just installed)

        ls /boot/vmlinux-*

Write down the names, then reboot your NetWinder and the new kernel should be loaded. It should without any problems. Note that any errors reported after phrase INIT: entering runlevel N are problems with user-space applications or configuration settings, and not kernel problems. An error like VFS: unable to mount root fs is a kernel problem.

Going back to an old version

If you need to get back to the old kernel, you can do so by interrupting the firmware at the Autoboot prompt. The following command should then by entered to boot the old kernel, whose exact name you must specify (you did write it down, right?)

        setenv kernfile /boot/vmlinux-2.x.y-YYYYMMDD
        boot

To make this setting permanent you need to modify the symbolic link /boot/vmlinux so it points at the name of the kernel you wish to boot. Or you can set the firmware permanently to the specific name (but this is not recommended).

2.5 Cleaning up

While not strictly necessary, the purists among you will undoubtedly want to get rid of the old kernel that isn't needed anymore (assuming the new one works well of course!). This task can be accomplished with the following RPM commands.

        rpm -e kernel-2.x.y-YYYYMMDD
        rpm -e kernel-headers-2.x.y-YYYMMDD

Of course you should specify the old kernel version and date in the above command. If it fails with an error saying the package is not installed, then most likely the original kernel was not installed via RPM. You may manually delete the appropriate files in /boot and /lib/modules if you wish, though I'd recommend to just not worry about it - it will not cause any harm to leave them around.

That's all there is to it, you are done!

2.6 Behind the scenes

If you are uncomfortable with RPM doing all the magic work, or just are curious how it really works, here is a brief explanation. The firmware expects to load a kernel called /boot/vmlinux from the first partition on the disk (unless you tell it otherwise). Normally /boot/vmlinux is a symbolic link pointing to a real kernel (with version number and date).

For each kernel version there is a corresponding set of loadable modules (device drivers). They are located in /lib/modules/2.x.y-YYYYMMDD, and the kernel is smart enough to know to look in the right directory (since the kernel knows what its version number is).

When you install a binary kernel RPM, the real kernel and its modules are placed in the appropriate place. Then (in the rpm post-install script) the /boot/vmlinux symbolic link is adjusted to point at the newly installed kernel. Upon reboot then new kernel is then loaded.

The kernel-headers package operates similarly. It installs the header files into /usr/src/linux-2.x.y-YYYYMMDD and then adjusts the symlink /usr/src/linux to point at the specific version.

What about package removal? The RPM program removes all the files that were in the package, but not the symbolic links, since they were created by the post-install scripts. So you can safely uninstall old kernel packages without any side effects, so long as the symlinks still point to real files that are still installed.


Next Previous Contents