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.
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.
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.
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).
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.
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).
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!
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.