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

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.

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

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:

1. 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.
2. Configure, compile, and build these packages (if necessary) or install the binaries on your system.
3. 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.
4. Enable ALSA using the alsamixer application, which un-mutes your ALSA configuration. (ALSA is always initially muted.)
5. Link the /etc/rc.d/init.d/alsasound startup file into the sequence of command files executed when your system starts up.
6. 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 from TimeSys on Migrating to Linux kernel 2.6. The series includes:

• Customizing a 2.6-based Linux kernel
• Migrating device drivers to Linux kernel 2.6
• Using the 2.6 kernel with your current system
• Migrating custom Linux installations to 2.6
• Migrating applications to the 2.6 kernel and NPTL

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.