Migrating to Linux
kernel 2.6 -- Part 3: Using the 2.6 Kernel with Your Current System
by William von Hagen (Feb.
24, 2004)
Foreword
-- This whitepaper is the third in a series from TimeSys’s "2.6
Linux Resource Center" on using the new Linux 2.6 kernel.
Authored by TimeSys Senior Product Manager William von Hagen, the
whitepapers in this series place special emphasis on the primary
issues in migrating existing drivers, applications, and embedded
Linux deployments to a Linux distribution based on the 2.6
kernel.
Material presented is largely vendor-neutral.
Enjoy!
. . .
Converting an existing development system to the 2.6 kernel
The
white papers in this series highlight primary issues in migrating
your existing drivers, development systems, applications, and custom
Linux deployments to the 2.6 Linux kernel. The previous white paper
in this series, "Migrating
Device Drivers to 2.6", provided an overview of
2.6-related changes to device drivers, explained the new device
driver compilation process, and discussed the implications of some of
the new features of the 2.6 kernel to existing device drivers. This
installment in the series provides an overview of converting an
existing development system to use a 2.6 kernel.
Why change
things for the 2.6 kernel?
The kernel is the heart of the
Linux operating system, managing all system threads, processes,
resources, and resource allocation. Unlike most other operating
systems, Linux enables users to reconfigure the kernel, which is
usually done to reduce its size, activate or deactivate support for
specific devices or subsystems. Reconfiguring the kernel to remove
support for unused devices and subsystems is quite common when
developing embedded systems, because a smaller kernel requires less
memory, increasing the resources available to your
applications.
Many of the new capabilities present in the
Linux 2.6 kernel, especially at the device driver and system software
levels, require parallel changes in the administrative utilities that
interact with them. 2.6-based systems require new startup scripts
that must understand new module naming conventions, use new
configuration files, and use new 2.6 features such as the sysfs
filesystem. The sysfs filesystem is a virtual filesystem that
maintains a hierarchical view of all of the devices in use on your
system, much as the proc filesystem provides for processes and status
information. The sysfs filesystem is designed to be used internally
by your Linux system, but the 2.6 kernel also provides integrated
support for new types of filesystems for storing user data. New
journaling filesystems such as JFS (introduced late in the 2.4 kernel
series) and XFS, and new networked filesystems such as OpenAFS all
require up-to-date, filesystem-specific utilities.
You only
need to install the utilities associated with new 2.6 features that
you are using. For example, if you are not using the JFS filesystem,
you can reduce the size of your kernel by disabling JFS support.
Similarly, you can reduce the size of the root filesystem used with
your kernel by removing (or simply not installing) JFS-related
utilities, because you will not need them.
If you are not
using an off-the-shelf Linux distribution based on the 2.6 Linux
kernel, you will need to verify that the versions of various packages
installed on your Linux system have all of the features required for
use with the Linux 2.6 kernel. If sufficiently recent versions of
these packages are not installed on your system, you will have to
update your system to newer versions of these packages.
Verifying
and updating critical packages
A package is a set of
related utilities that are provided and installed together, either by
building them from source code or by installing binaries that someone
else has prepared. Different Linux distributions provide package and
dependency management software that verifies that any other software
that a package depends on is installed on your system and is of a
sufficiently recent version. These package managers also typically
maintain a system-wide database of installed applications and their
versions. The most common package formats that provide and use
dependency information are the RPM (Red Hat Package Manager, also
used by the Fedora, Mandrake, SuSE, and Turbolinux distributions) and
DEB (Debian Linux, also used by the Knoppix and Xandros
distributions) package formats. Other package formats, such as the
standard gzipped tar file TGZ format used by the Slackware Linux
distribution, do not include dependency information in the package
itself.
Table
1 lists various Linux software packages that are present in
most standard 2.4-based Linux systems, and certainly on all desktop
Linux installations used for software development. Specialized
distributions targeted for markets such as embedded computing may not
require or use all of these packages in the root filesystems that
they deploy. However, if you are upgrading a specialized system such
as one used for embedded computing, it is critical to understand
where these packages must be updated.
If you are upgrading a
desktop Linux system to the 2.6 kernel, the only place to update and
verify these packages is on your desktop system. However, if you are
migrating a specialized system such as an embedded Linux
distribution, you must first update any cross-compilers and related
software that you are using on your desktop Linux systems to build
software for the embedded system. You must then update any of the
packages identified in this white paper that are used in your
embedded system's filesystems. The next white paper in this series,
"Migrating Custom Linux Installations to the 2.6 Kernel",
provides an overview of upgrading these types of specialized systems.
Software Package |
Minimum Version |
Command to Show Version |
---|---|---|
binutils |
2.12 |
|
e2fsprogs |
1.29 |
|
gcc (GNU C Compiler) |
2.95.3 |
|
make (GNU make) |
3.78 |
|
module-init-tools |
0.9.10 |
|
procps |
3.1.13 |
|
util-linux |
2.10o |
|
Table 1: Standard Software
Package Versions Required for a 2.6 Kernel
When preparing
to use a 2.6 kernel with an existing system, you must verify the
versions of any of the packages listed in Table
1 that are installed on the system that you are migrating,
and update them to appropriate versions if necessary. The first
column in this table gives the name of a software package that may
require updating for use with the 2.6 kernel. The second column
identifies the minimum version required for compatibility with the
2.6 kernel - any version newer than the specified minimum version
should also be fine. The third column provides a sample command that
you can execute in order to determine the version of the software
that is currently installed on your system.
In addition to the
packages listed in Table
1, you might also need to update additional packages if you
plan to use specific filesystems, hardware, or administrative
mechanisms on your 2.6-based system. These additional package updates
are discussed later in this white paper.
Special handling
when upgrading module-init-tools
Of the packages listed in
Table
1, the module-init-tools package requires some special care
during an upgrade if you want to be able to dual-boot your system
with either a 2.6 or a 2.4-based kernel. The module-init-tools
package provides the system applications for module loading (insmod
and modprobe
), unloading (rmmod
),
listing (lsmod
), and dependency analysis
(depmod
). Due to changes in module naming and
loading mechanisms, you can't simply overwrite the existing versions
of these utilities. If you do so, you will not be able to manage
2.4-style kernel modules correctly. Therefore, part of the process of
upgrading the module-init-tools package is to rename the existing 2.4
versions of these utilities as utility.old, which preserves the
versions necessary for 2.4 kernels. If the module-init-tools package
has been compiled with support for backward compatibility (which is
the default), the utilities in the package will automatically execute
the 2.4 versions of these utilities whenever you boot a 2.4
kernel.
If you are updating your module-init-tools binaries
using a prebuilt package file such as a DEB or RPM package and need
to be able to dual-boot your system using a 2.4 or 2.6 kernel, you
should check that the package file includes a pre-install script that
renames your existing module-related binaries before installing the
new version. A simpler approach is to build the module-init-tools
package for your system from source code. One of the make
targets when building this package from source is moveold
,
which copies your existing module-related binaries so that they are
not lost when the new versions are installed. A suggested sequence
for configuring, building, and installing module-init-tools from
scratch is the following:
./configure --prefix=/ make moveold make make install
The first command
configures the module-init-tools package so that it installs in the
same location as the original module-init-tools package (as opposed
to subdirectories of /usr/local
). The second command
renames the existing binaries from a previous installation of the
module-init-tools package, as explained in the previous paragraph.
The third command builds the applications in the module-init-tools
package, and the fourth line installs them.
Of course,
building and installing this package from source will not update any
database of installed applications that is maintained by your package
manager, but it is safest unless you are a true package wizard and
know how to extract and examine pre-install scripts from existing
packages.
A final step when installing the new version of the
module-init-tools package is to run a shell script that converts the
entries in the module configuration file used by 2.4-series kernels
(/etc/modules.conf
) to equivalent entries in the module
configuration file used by the 2.6 kernel (/etc/modprobe.conf
).
This script is the aptly-named generate-modprobe.conf
script, and takes a single argument, which is the full pathname of
your existing modules.conf
file. After running this
script, you may also need to examine the new file and update it to
reflect changes in device naming between the 2.4 and 2.6 kernels.
Additional packages that might require updating
Table
1 listed packages that are used on most Linux systems and
which must be a specified version or newer on a system that is
running the 2.6 kernel. You might need to update additional packages
if you happen to be using the features that these packages support on
your systems. Table
2 shows packages that you will need to verify or update if
you are using associated features, but which are not used by default
on all Linux distributions. These packages are specific to optional
subsystems or drivers such as ISDN (isdn4k), PCMCIA cards
(pcmcia-cs), kernel profiling analysis (oprofile), filesystem quotas
(quota-tools), and specific types of networking or journaled
filesystems (nfs-utils, jfsutils, reiserfsprogs, and xfsprogs).
Software Package |
Minimum Version |
Command to Show Version |
---|---|---|
isdn4k-utils |
3.1pre1 |
|
jfsutils |
1.1.3 |
|
nfs-utils |
1.0.5 |
|
oprofile |
0.5.3 |
|
pcmcia-cs |
3.1.21 |
|
ppp |
2.4.0 |
|
quota-tools |
3.09 |
|
reiserfsprogs |
3.6.3 |
|
xfsprogs |
2.6.0 |
|
Table 2: Additional Software
Package Versions Required by a 2.6 Kernel
As mentioned
earlier, you only need to upgrade or install the specified packages
and versions if you are using the software functionality that they
are relevant to. We suggest that you install or upgrade packages that
you are likely to use at some point, such as the nfs-utils package.
You must simply remember that you will need to install or upgrade the
other packages listed in this section if you activate related kernel
features.
System changes for ALSA
If you use any
of the audio capabilities of your system beyond its built-in speaker
and associated beep, one of the key changes present in the 2.6 Linux
kernel is its adoption of the Advanced Linux Sound Architecture
(ALSA). ALSA is now the default digital audio architecture for
playing and managing audio recording and playback. ALSA has been
available for quite a while, and replaces the Open Sound System
(OSS), the default in stable kernels prior to 2.6. Even in the 2.6
kernel, ALSA provides an OSS emulation mode to support legacy
applications, but switching your system to use ALSA is certainly the
right long-term solution.
Discussing all of the nuances of
converting your system to use ALSA is outside the scope of this white
paper and would largely duplicate the excellent documentation
available on the ALSA
Project web site. TimeSys has found that it is generally wise
to convert your existing 2.4-based system to ALSA before upgrading
your system to the 2.6 kernel. This eliminates several variables in
your 2.6 Linux upgrade, because it ensures that ALSA works on your
hardware. Any problems with sound that you encounter during the
upgrade are therefore related to the upgrade rather than to ALSA
itself. Upgrading a 2.4 system to ALSA before upgrading to the 2.6
kernel also ensures that the ALSA module configuration commands are
present and correct in your /etc/modules.conf
file
before you generate the 2.6 equivalent /etc/modprobe.conf
file (as described earlier in this white paper).
The
highlights of the ALSA upgrade process are the following:
Get the latest versions of the ALSA drivers, library, and utilities in source format or as pre-prepared packages that you can install on your system. ALSA drivers are also included in the 2.6 kernel source, but we suggest getting the drivers package so that you can upgrade your 2.4 system to ALSA first, as suggested previously. If you want to use ALSA's OSS emulation mode, you will also need to get its source code and build and install this package as well.
Configure, compile, and build these packages (if necessary) or install the binaries on your system.
Configure
the ALSA software using the alsaconf
application, which probes for your sound hardware, generates the
correct module loading information, and optionally updates your
/etc/modules.conf
file.
Enable
ALSA using the alsamixer
application, which
un-mutes your ALSA configuration. (ALSA is always initially muted.)
Link
the /etc/rc.d/init.d/alsasound
startup file into the
sequence of command files executed when your system starts up.
Execute the
generate-modprobe.conf
script to migrate your
ALSA module configuration to the /etc/modprobe.conf
file used with the module utilities required for a 2.6 kernel.
ALSA has many advantages over OSS,
ranging from support for more audio interfaces and soundcards,
modularized drivers that are SMP and thread-safe, and a good
separation between kernel and user space that simplifies writing and
maintaining drivers and audio applications. For more complete
information, see the ALSA
project's Web site.
Updating system configuration
files
In addition to updating packages or verifying that
you have sufficiently recent versions installed, you will usually
need to manually update some of your system startup and configuration
scripts in order to mount and use the new filesystems and to take
into account the kernel module naming scheme used by the 2.6 kernel.
This section provides an overview of the primary system configuration
files that you must update; the next section provides an overview of
upgrading system startup scripts.
The new sysfs filesystem is
designed as an in-memory repository for system and device status
information, providing a hierarchical view of the system's device
tree. The system information that is dynamically maintained in the
sysfs filesystem is analogous to the process status information that
is dynamically maintained in the proc filesystem.
When
upgrading to use the 2.6 kernel, you must therefore add a line for
the sysfs filesystem to your system's filesystem table file,
/etc/fstab
. This entry should look something like the
following:
none /sys sysfs noauto 0 0
This entry gives your system the
information that it needs to identify and mount the sysfs filesystem
on the /sys directory (which you must create using a command such as
mkdir /sys
). If your system will only boot the
2.6 kernel, you can specify the defaults
mount
option rather than noauto
, so that your system
will mount the sysfs filesystem whenever your system executes the
mount -a
command, which is usually run during system
startup.
If you want your system to boot either a 2.4 or 2.6
kernel, the noauto
mount option in the example
entry prevents your system from trying to automatically mount the
sysfs filesystem when booting a 2.4 kernel. You would then add an
explicit mount for this filesystem to your system's startup scripts,
as discussed in the next section.
For detailed information
about the organization of the /etc/fstab
file and the
meaning of each of the fields in an entry, consult the online
reference information for this file by executing the man
fstab
command on your Linux system.
Updating
system startup and shutdown scripts
As mentioned earlier,
2.6-related changes such as different file names, module names, and
new features, make it necessary to update your system's startup
scripts when adding a 2.6 kernel as a boot option on an existing
2.4-based system. This section provides an overview of the sorts of
changes necessary on standard desktop systems such as Red Hat Linux
systems.
The files that you need to change depend on your system's
boot sequence and the startup and shutdown scripts that it executes.
The specific files used during the boot process differ across Linux
distributions, though most are based on the SysVinit and initscripts
packages. Enhanced versions of these packages that handle both 2.4
and 2.6 startup procedures may be available from the vendor (if any)
who supports your Linux distribution. If they are not available, this
section and the subsequent white paper in this series ("Migrating
Custom Linux Installations to 2.6") will help you identify the
changes that you need to make.
If you are creating a system
that can boot and run both 2.4 and 2.6-based kernels, and your Linux
vendor does not provide updated and flexible startup and shutdown
scripts, conditionalizing your startup scripts based on the version
of the kernel that is booting is an excellent solution. The easiest
way to do this is to set an environment variable based on the
identity of the running kernel, as in the following example:
VERSION=`uname -a | sed -e 's;.* \(2\.6\).*;\1;'` if [ "x$VERSION" = "x" ] ; then VERSION="2.4" fi
This sets the environment variable VERSION to 2.6 for a 2.6 kernel and to 2.4 otherwise. You can then subsequently check the value of this variable and execute the commands appropriate for your kernel version, as in the following example:
if [ "x$VERSION" = "x2.6" ] ; then action $"Mounting sysfs filesystem: " mount -n -t sysfs /sys /sys fi
One of the first changes that you
should make to your startup scripts when using a 2.6 kernel is to add
commands that mount the sysfs filesystem (as shown in the previous
example). One of your system's startup scripts, probably
/etc/rc.sysint
or /etc/rc.d/rc.sysinit
,
contains an entry that mounts the proc filesystem on the directory
/proc
when your system boots. You will need to add a
parallel entry for mounting the sysfs filesystem on the mount point
/sys
(which you may also need to create using the mkdir
/sys
command) at a similar location in the file to where
the /proc filesystem is mounted.
Similarly, the name of the
file in the proc filesystem that contains kernel symbol information
has changed in the 2.6 kernel. To guarantee that your startup scripts
have access to kernel symbols, you should change or conditionalize
any instances of /proc/ksyms
in your system startup
files to /proc/kallsyms
, the name of the file used by
the Linux 2.6 kernel.
Next, some files that were located in
the proc filesystem for the 2.4 kernel have migrated to the sysfs
filesystem for the 2.6 kernel. As an example, the USB device list
that was stored in the file /proc/bus/usb/devices
when
using a 2.4 kernel is now stored in the file /sys/bus/usb/devices
under the 2.6 kernel.
Finally, you should also make equivalent
changes to any scripts invoked during your system's shutdown
procedure. For example, on Red Hat systems, the shutdown process
invokes the script /etc/init.d/halt
during system
shutdown, which references the proc filesystem but not the equivalent
sysfs filesystem.
The items listed in this section are the
primary system startup and shutdown changes that most people will
need to make to use a 2.6 kernel with a 2.4 Linux root filesystem.
Depending on the extent to which you have customized your system's
startup process and installed additional utilities or drivers, you
might find that other changes are required. A sample rc.sysinit file
that has been conditionalized to work with both the 2.4 and 2.6
kernels is available online in the TimeSys
Resource Center. The sample file was created for use on a
system running Red Hat 9, but shows the types of changes that you
will need to make regardless of which Linux distribution you are
running.
Kernel compilation suggestions
The
first white paper in this series, "Customizing
a 2.6-Based Kernel", provided an overview of configuring
the 2.6 Linux kernel. If you are installing the 2.6 Linux kernel on
an existing system and are building the kernel yourself, the easiest
way to correctly configure your 2.6 kernel is to reuse the kernel
configuration file from your current system. You can do this through
the kernel's make oldconfig make target, which is a text-mode
interface that takes an existing configuration file and queries you
for settings for any configuration variables found in the kernel
source but not in that configuration file. Using this make target to
migrate an existing configuration file was explained in the first
white paper in this series. Using the make oldconfig
kernel configuration target gets you most of the way towards building
a 2.6 kernel that will boot successfully on your system, but note
that simply running make oldconfig may not create a kernel
configuration that has all of the features that you want.
A
good suggestion for smoothly migrating an existing system to the 2.6
kernel is to change as few things as possible at the same time. The
packages, system configuration files, and startup scripts discussed
earlier in this white paper are necessary changes for using a 2.6
kernel. However, if you are also adding ALSA support and followed our
suggestion to upgrade your 2.4 system to ALSA before moving to 2.6,
keep ALSA support as a loadable kernel module until you're sure that
your 2.6 system is working correctly. At that point, you can always
rebuild your 2.6 kernel with integrated ALSA support - but at least
you know that ALSA worked correctly with your 2.6 system. Similarly,
if you're interested in experimenting with devfs, don't switch to
devfs during your initial migration to 2.6. You can always add it in
later by rebuilding your kernel, once you have a 2.6 kernel working
correctly on your system.
Migrating an off-the-shelf system to
the 2.6 kernel
If you're migrating a system running an
off-the-shelf distribution to the 2.6 kernel, you might never have
had to worry about the exact hardware details of your system. One of
the advantages of off-the-shelf desktop distributions such as Red Hat
or SuSE or an off-the-shelf embedded distribution such as TimeSys
Linux is that they are built with integrated or loadable kernel
module support for almost anything that you would encounter on a
random PC or on a specific embedded board.
If you are
migrating an off-the-shelf system and have the source code and
configuration file for the kernel that you are running, you can
migrate this configuration file to the 2.6 kernel by following the
instructions given in the previous section and activating support for
any new features that you are interested in, such as ALSA. You should
then be able to build and install your 2.6 kernel, any associated
modules, and reboot to test your system with the 2.6 kernel. If this
is the case, skip to the next section of this white paper.
If
you do not have a configuration file for the kernel that your system
is running, you can generate a default configuration file by
executing the make defconfig command in the 2.6 kernel source
directory. The list of available kernel configuration variables
differs for each architecture and often across different types of
processors. If you are migrating a PowerPC (PPC) Linux system to the
2.6 kernel, you may want to start with kernel source code such as
TimeSys Linux 2.6 Reference PPC Distribution which includes verified
support for selected PPC processors. TimeSys' enhancements to the 2.6
kernel for the PPC processor are actively being submitted to the Open
Source community and should be available in the main kernel source
tree soon. Alternately, you can see the configuration options
available for different architectures in any kernel source tree by
specifying your target on the command line for your configuration
command, as in the following example for a PowerPC (PPC) system:
make defconfig ARCH=ppc
Once you have generated a default 2.6
kernel configuration file, you must then configure the kernel to
provide drivers for the hardware in your system, either built-in or
as loadable kernel modules.
Discussing all of the details of
hardware identification on any platform is outside the scope of this
white paper, but two of the most useful utilities for identifying
your hardware are the lspci and lsusb utilities found in most Linux
distributions. The lspci
utility displays information
about all of the PCI buses detected on your system, listing the
devices that are connected to them. This utility is especially useful
for x86 motherboards with integrated sound or graphics adapters,
because it helps identify the actual chipsets used in the onboard PCI
circuitry. The lsusb
utility provides the same sort of
information for the USB buses and attached devices in your
systems.
If you are creating your own kernel configuration
file, some other hardware information that you might want to supply
is information about the specific type of CPU used in your system.
You can configure this information using the make xconfig
configuration editor's Processor
or Processor
type and features
pane. Information about the type of
processor in your system is available in the file /proc/cpuinfo
,
which you can simply display by executing the cat
/proc/cpuinfo
command.
Finally, you might still
need to make changes to your new kernel configuration file based on
custom kernel features that your existing system is using. For
example, you should check the filesystems that are used or supported
by the kernel that you are currently using. Information about the
types of filesystems available on your system is available in the
file /proc/filesystems
, which you can simply display by
executing the cat /proc/filesystems
command. For
example, the root filesystems used by SuSE Linux systems are
typically reiserfs filesystems, but the reiserfs filesystem is not
active in the 2.6 kernel by default. Similarly, using an initial RAM
disk is not active by default in the 2.6 kernel, and neither is
support for accessing SMB or CIFS filesystems.
Putting It
All Together
Once you've migrated or created your kernel
configuration file and configured it as described in the previous
section and in the first white paper in this series, you're ready to
build and install the kernel and any modules that you have specified.
Building the kernel is is done by executing the make
command from the top-level kernel source directory, and requires the
versions of the gcc, make
, and binutils
packages that were discussed earlier in this white paper. Once the
make command completes successfully, how you install the kernel and
modules depends on the type of system for which you are building the
kernel. If you are updating a desktop x86 system, you can install the
kernel and associated modules using the make install
and make modules_install
commands. If you are
cross-compiling a 2.6 kernel for a target embedded system, the make
targets that you will want to use for installation depend on where
and how your kernel binaries are installed for use by the target
system.
As described in this white paper, migrating a desktop
system to the 2.6 kernel has a fair number of steps, but is actually
quite easy to do even if you are relatively new to Linux. Migrating
specialized Linux systems, such as those used in embedded computing,
is somewhat more complex, but is also manageable. TimeSys's TimeStorm
Linux Development Suite (LDS) makes it easier to migrate
specialized systems to new kernels and new hardware. TimeSys's
TimeStorm
Linux Verification Suite (LVS) makes it easy to verify that
your updated system and applications are working correctly and will
satisfy your requirements. The next white paper in this series,
"Migrating Custom Linux Installations to the 2.6 Kernel",
provides an overview of upgrading these types of specialized systems
and provides insights into how powerful but easy-to-use software can
simplify and expedite the migration and update process.
About
the author: William von Hagen is a Senior Product Manager at
TimeSys Corp., has been a Unix devotee for over twenty years, and has
been a Linux fanatic since the early 1990s. He has worked as a system
administrator, writer, developer, systems programmer, drummer, and
product and content manager. Bill is the author of Linux
Filesystems, Hacking the TiVo, SGML for
Dummies, Installing Red Hat Linux 7, and is the
coauthor of The Definitive Guide to GCC (with Kurt Wall)
and The Mac OS X Power Users Guide (with Brian Profitt).
Linux Filesystems is available in English, Spanish,
Polish, and traditional Chinese. Bill has also written for
publications including Linux Magazine, Mac Tech, Linux Format,
and online sites such as Linux Planet and Linux
Today. An avid computer collector specializing in
workstations, he owns more than 200 computer systems.
Next!
The next
installment of this series of white papers provides an overview of
the types of changes that you may need to make to a customized or
specialized Linux installation in order to use it with the Linux 2.6
kernel, building upon the configuration file and administrative
updates that were touched upon earlier in this white paper. For
additional white papers and other related information, please visit
TimeSys.
TimeSys also offers webinars
on 2.6-related topics.
This article is part three of a
series of whitepapers by von Hagen on Migrating to Linux kernel 2.6.
The series includes:
Migrating custom Linux installations to 2.6 (coming soon)
Migrating applications to the 2.6 kernel and NPTL (coming soon)