Novell Home

Converting An Existing Development System To The 2.6 Linux Kernel

Novell Cool Solutions: Feature
By Kevin Burnett

Digg This - Slashdot This

Posted: 16 Nov 2004
 

Kevin Burnett
System Integration Consultant
Tenacious Integration Services, Inc.
kburnett@gettenacious.com

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. In order to fully realize the performance of the Linux 2.6 kernel, many system configuration changes must be made.

In this article we will look at things to be aware of when you upgrade to the Linux 2.6 kernel.

Why Would You Want To Change Things For The 2.6 Kernel?

Not unlike any operating system, the Linux Kernel is central to the Linux operating system. The kernel is responsible for tracking all resources, processes, and threads required by the Linux operating system. One feature of Linux, that other operating systems usually don't provide, is the ability to modify and reconfigure the kernel. The advantage of a reconfigureable kernel is that you can add or remove functionality effectively modeling the kernel to your specific use. Also, if you choose, you can minimize the memory requirements of the kernel, making it very sleek for embedded systems.

With the introduction of the 2.6 kernel, many enhancements have been added to an already robust operating system. However, to effectively take advantage of the 2.6 kernel, especially at the device driver level, require you to make appropriate changes to the administrative utilities that govern them. Startup scripts, on the new 2.6 systems, need to be updated to deal with new module naming conventions, to be able to use new configuration files, and to use other 2.6 kernel features such as the sysfs file system.

Note: The sysfs file system is a virtual file system that maintains a hierarchical view of all of the devices in use on your system, very similar to the way the proc file system provides information for processes and status.

Granted, the sysfs file system was designed from the ground up to be used internally with your Linux system. However, the 2.6 kernel gives you options for new types of file systems, which you use to store your data. Regardless of the file system you choose to use, be it JFS or XFS, or the new networked file system OpenAFS, you will be required to have complementing, current, up-to-date file system-specific utilities.

When installing the new utilities, you don't need to get carried away, you only need to install the utilities associated with the 2.6 kernel features you are using. An example would be if you choose not to use the JFS file system, you can significantly reduce the size of your kernel. Likewise, you can reduce the size of you kernel by disabling JFS support. Along these same lines, you have the option of reducing the size of your root file system, which the 2.6 kernel uses, by removing, or not installing for the fact, JFS-related utilities, because you will not need them.

So what type of Linux distribution of Linux are you using? If it is an off-the-shelf variety, usually bought at a store, then you can be assured that the utilities included with the box will work with the included kernel. This would be true of an off-the-shelf release based on the 2.6 kernel. However, if you pieced it together, you will need to verify that the versions you are using, of the various packages, have all of the features required for use with the Linux 2.6 kernel. If you are behind in keeping your Linux system up-to-date and you upgrade to the 2.6 kernel, you will have to update your system to the newer versions of the utilities and packages.

Verifying and Updating Packages

First let's look at what a package is. Linux packages are a set of related files that are provided and installed together. These can be pre-compiled binaries or binaries that you have custom compiled. Typically, a Linux distributor such as SUSE Linux, will provide Linux distributions that include package and dependency management software that will verify that other software that a package needs is installed on your system and if installed, that the version is correct to run with the package. Also, by default behavior, these package managers maintain a system-wide database of installed application and their versions. The most common package format, and the one used in SUSE Linux Linux is the Red Hat Package Manager (RPM), this manager is also used with the Fedora, Mandrake, and of course Red Hat Linux distributions. The other popular package format is DEB, used by Debian Linux, Knoppix and Xandros distributions. Other package formats, such as gzipped tar file (TGZ) format, used by Slackware Linux distribution, do not include dependency information in the package itself.

Software Package Minimum Version Command to Show Version
binutils 2.12 ld -v
e2fsprogs 1.29 tune2fs
gcc (GNU C Compiler) 2.95.3 gcc --version
make (GNU make) 3.78 make --version
module-init-tools 0.9.10 depmod -V
procps 3.1.13 ps --version
util-linux 2.10o fdformat --version

Table 1 - Typical Software Package Versions Required for the 2.6 kernel

If we look at the previous major release of the Linux kernel, 2.4, Table 1 lists various software packages that are used with this kernel. Also, if you are currently running the Linux 2.4 kernel, you will most certainly use these packages in a development environment.

Note: If you requires a specialized development environment, such as that for embedded systems or automated mechanical systems, you may not use or requires all of these packages in the root file systems that you deploy. However, for a general development, it is very important to understand how to update these packages.

When upgrading to the Linux 2.6 kernel, it is imperative to do the following things:

  1. If you are upgrading a desktop Linux system to the 2.6 kernel, the only place to verify these packages is on your desktop system.
  2. If you are migrating a specialized system such as an embedded Linux configuration, you need to update any cross-compilers and associated software that you are running on your desktop Linux system so that you can correctly build software for the embedded system.
  3. You need to then upgrade your system with the packages identified in this article.

Looking back at Table 1, the first column gives the name of a software package that may require updating for use with the 2.6 kernel. The second column provides the minimum version required for compatibility with the 2.6 kernel.

Note: Any version greater (newer) than the noted version should also be fine.

The last column gives a sample command that you can execute to determine the current version of the utility software that is installed on your installation.

Note: In addition to the packages listed in Table 1, if you run specific file systems, hardware, device drivers, or administrative mechanisms, you might need to update additional packages as appropriate.

Module Init Tools

This section will focus on the module-init-tools package, listed in Table 1. This package requires special care during an upgrade if you want to be able to dual-boot your system with either a 2.6 or 2.4 kernel.

So what exactly is the module-init-tools package? The module-init-tools package provides the system applications for module loading via insmod and modprobe, unloading via rmmod, listening via lsmod and dependency analysis via depmod. Unfortunately, since there are many changes in module naming and loading mechanisms, you can not take the simple upgrade choice and write over the existing versions of these utilities with the newer versions. If you choose to overwrite the existing utilities with the new ones, you will not be able to work with and manage the 2.4 kernel modules correctly. As a result, it is critical that you do or have done one of the following:

  1. Rename the existing 2.4 kernel specific module-init-tools package to utility.old. This will preserve this version of the utilities for you when you boot the 2.4 kernel.
  2. Better yet, verify or compile yourself, the module-init-tools package for support for backward compatibility. Luckily this is the default option, so odds are you already have this functionality. With this set, the utilities in the package will automatically execute the 2.4 versions of these utilities whenever you boot the 2.4 kernel.

If you are into doing things automatically by using a prebuilt package such as DEB or RPM, and desire dual boot functionality using the 2.6 or 2.4 kernel, it is very important to check that the package file includes a pre-install script that renames your existing module-related binaries before installing the new version. A much better way of doing this is to build the module-init tools from the source code for your system. One of the make targets when building this package from the source is moveold, which copies your existing module-related binaries so that they are not lost when the new versions are installed. One way that you can build and install the module-init-tools from scratch is as follows:

./configure -prefix=/
make moveold
make
make install

Looking at these commands, the first line configures the module-init-tools package so that it installs in the same location as the original module-init-tools package, as apposed to subdirectories of /usr/local. The next line's commands rename the existing binaries from a previous installation of the module-init-tools package, with details above. The third line's command builds the applications in the module-int-tools package. The last line installs the packages.

Note: Building and installing the module-int-tools package from source will not upgrade any database of installed applications that is maintained by your package manager, but it is recommended unless you are a true package wizard and know how to extract and examine pre-install scripts from existing packages.

To bring closure to the mod-int-tools part of this article, when you install the new version of the mod-int-tools package, you should run a shell script that converts the entries in the module configuration file used by Linux 2.4 series kernels, /etc/modules.conf, to equivalent entries in the module configuration file used by the 2.6 kernel, /etc/modprobe.conf. The script is named generatemodprobe.conf. This script take only one argument, which is the full pathname of your existing modules.conf file. Lastly, after running the script file, you may need to go back and examine the new file and possibly update it to contain changes in device naming between the Linux 2.4 and Linux 2.6 kernels.

Updating Additional Packages

In Table 1 we listed several packages that are used on most Linux systems and which must be a minimal version or newer on a system that is running the Linux 2.6 kernel. There is a very real possibility that you will need to update additional packages if you happen to be using the features that these packages support on your system.

Let's look at Table 2, below. Table 2 shows packages that you will need to check out if you are using their associated features. You will need to make sure that your version of each package is at the minimum level, at the least, for each package.

Software Package Minimum Version Command to Show Version
isdn4K-utils 3.1pre1 isdnctrl 2>&1|grep version
jfsutils 1.1.3 fsck.jfs -V
nfs-utils 1.0.5 showmount --version
oprofile 0.5.3 oprofiled --version
pcmcia-cs 3.1.21 cardmgr -V
ppp 2.4.0 pppd --version
quota-tools 3.09 quota -V
reiserfsprogs 3.6.3 reiserfsck -V 2>&1 | grep progs
xfsprogs 2.6.0 xfs_db -V

Table 2 - Additional Software Package Versions Required by the 2.6 Kernel

Note: The packages listed in Table 2 are not required for a Linux 2.6 kernel base system, but if used, and these are popular packages, you will need these versions or greater.

The packages in Table 2 are integral parts of certain Linux distributions. They are specific to optional subsystems or drivers such as ISDN, isdn4k, PCMCIA cards, pcmcia-cs, kernel profiling analysis, oprofile, file system quotas, quota-tools, and specific types of networking or journaled file systems. For example, nfs-utils, jfsutils, reiserfsprogs and xfsprogs.

As we have talked about earlier in this article, you will only need to install or upgrade the specific packages and versions if you are using the software functionality that they are relevant to. It would be highly recommended to install or upgrade packages that you are likely to use at some point down the road. You may want to envision where your development efforts, with Linux, are headed and try and foresee where you will be in six months, a year. One package that I would recommend would be the nfs-utils package. If you don't install the packages you may need in the future now, you will need to remember that you will need to install or upgrade the other packages listed in Table 2 if activate the related kernel features.

Focus on ALSA (Advanced Linux Sound Architecture)

Are you an audio aficionado? Do you go beyond your computer's built in speaker and its associated beeping? If so, then you will be interested in one of the key changes present in the Linux 2.6 kernel, that being it's adoption of the Advanced Linux Sound Architecture (ALSA). Linux now uses LASA as the default digital audio architecture for playing and managing audio recording and playback. Acutally, ALSA has been available for quite a while, but it was chosen to replace the Open Sound System (OSS), because it is much more mature sound processing system. (The Linux 2.4 kernel release used OSS.) Granted, ALSA provides an OSS emulation mode to support legacy applications, but switching your system to ALSA is recommended for long-term solutions.

ALSA is quite a feature-filled audio package. Discussing all the ins and outs of this system is beyond the scope of this article. If you want all things ALSA, I would suggest that you visit their website at: http://www.alsa-project.org/. At the ALSA website, you can also view and download their very good and concise documentation. In talking to several Linux Guru's, the general consensus is to convert your Linux 2.4 kernel-based system to ALSA before you upgrade you system to the Linux 2.6 kernel. This eliminates several possible problems with your Linux 2.6 kernel upgrade, because it ensures that ALSA works on your existing hardware. As a result, any problems with sound that you run into during your upgrade will not be related to ALSA rather they will be with other components/packages of Linux 2.6 kernel. Another reason for doing this allows you the comfort that the ALSA module configuration commands are present and correct in your /etc/modules.conf file before you create the 2.6 equivalent /etc/modprobe.conf file, described earlier in this article.

It will be beneficial to go over the highlights of the ALSA upgrade process. Here they are:

  1. Make sure you have the latest version of the ALSA drivers, library and utilities. These can be your preference of source code or pre-packaged packages that can be installed on you system. ALSA drivers are also included in the 2.6 kernel source, but it is recommended that you get the drivers packages from the ALSA website so you can upgrade your 2.4 system to ALSA first, as recommended above, in this article. However, if you have a need to use ALSA's OSS emulation mode, you will need to get its source code and build and install this package as well.
  2. If you need to, configure, compile and build these packages. If you have the pre-compiled binaries, install them on your system.
  3. Configure the ALSA software using the alsaconf application. This application will look for your sound hardware, generating the correct module loading information. It will also, optionally, update your /etc/modules.conf file.
  4. Enable ALSA using the alsamixer application, which un-mutes your ALSA configuration. (Take note that 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 the 2.6 kernel.

To sum up ALSA, ALSA has many advantages over OSS. Some of these include support for more audio interfaces and soundcards. Also included are modularized drivers that are thread-safe, and a good separation between kernel and user space that simplifies writing and maintaining drivers and applications. Once again, for more information check out the ALSA project's website.

Updating System Configuration Files

Now you are somewhat familiar with the packages that will need to be updated when moving to the Linux 2.6 kernel. However, you will usually need to manually update some of your system startup and configuration scripts in order to mount and or use the new file systems and to deal with the kernel module naming scheme used by the Linux 2.6 kernel. The following section will give an overview of the primary system configuration files that you must update, followed by a section on upgrading system startup scripts.

Mentioned earlier, the new sysfs file system has been designed to reside in memory, thereby providing a hierarchical view of the system's device tree, by utilizing system and device status information. The system information that is dynamically maintained in the sysfs file system is quite similar to the process status information that is dynamically maintained in the proc file system.

When you upgrade to the Linux 2.6 kernel, you need to add a line for the sysfs file system to your system's file system table file which is /etc/fstab. The entry you make should look similar to the following:

none    /sys     sysfs     noauto     0     0

Commenting on this entry, this will give your system the information that it needs to identify and mount the sysfs file system on the /sys directory. Granted you must create this using a command such as mkdir /sys. Now if you only want to run the Linux 2.6 kernel and are not worried about back-revving to the Linux 2.4 kernel, you can choose to specify the defaults mount option rather than choosing the noauto mount option. By doing this, your Linux system will mount the sysfs file system whenever you system executes the mount -a command, which typically occurs during system startup.

Now if you do need to back-rev to the Linux 2.4 kernel, you do have a way to setup your system to allow the booting of an appropriate file system for each kernel. The noauto mount option will prevent your system from automatically trying to mount the sysfs file system when booting the Linux 2.4 kernel-based system. All you would then need to do is add an explicit mount for the file system to your system's startup scripts. We will look more at scripts in the next section.

If you need or want more detailed information about the organization of the /etc/fstab file and the meaning of each of the fields in an entry, check out the online reference information for this file by running the man fstab command on your Linux system.

Updating System Startup and Shutdown Scripts

As talked about earlier in this article, when you upgrade to the Linux 2.6 kernel, the changes that are made , such as different file names, module name, 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. In this section we will look at the types of changes needed on a standard desktop system such as SUSE Linux or Red Hat Linux systems.

Granted, the files that you need to change depend on your system's boot sequence and the startup and shutdown scripts that are run. The files and packages you use during the boot process are quite different across different Linux distributions, though collectively, most are based on the Sys Vinit and initscripts packages. You may want to check with your Linux distribution vendor to see if they offer enhanced scripts that will handle both 2.4 and 2.6 startup procedures. If your vendor does not have an enhanced package, then this section is for you.

Assuming that you want a system that can boot and run both 2.4 and 2.6 Linux systems, you can modify your startup scripts based on the version of the kernel that you are currently booting. The easiest way to do this is to set an environment variable based on the identity of the running kernel, as follows:

VERSION=`uname -a | sed -e 's;.*  \(2\.6\).*;\1;'
if [ "x$VERSION" = "x" ] ; then
	VERSION="2.4"
fi

This modification sets the environment variable VERSION to 2.6 for a 2.6 kernel and to 2.4 otherwise. You then have the ability to check the value of this variable and execute the commands appropriate to your kernel version.

if [ "x$VERSION" = "x2.6" ] ; then
	Action $"Mounting sysfs filesystem: " mount -n -t sysfs /sys /sys
fi

One of the first changes you should make when running the Linux 2.6 kernel is to add commands that mount the sysfs file system, as above. One of your system's startup scripts, a good chance it is probably /etc/rc.sysint or /etc/rc.d/rc.sysinit, contains an entry that mounts the proc file system on the directory /proc when your system boots. You will need to add a parallel entry for mounting the sysfs file system on the mount point /sys at a similar location in the file to where the /proc file system is mounted.

Note: If you don't have a /sys on your system, you will need to create it with the mkdir /sys command.

To accomplish effective debugging, it is nice to have the OS symbol information available. With the Linux 2.6 kernel, the name of the proc file system that contains the kernel symbol information has changed. To make sure that your startup scripts have access to kernel symbols, you should change any instances of /proc/ksyms in your system startup files to /proc/kallsyms, which is the name of the file used by the Linux 2.6 kernel.

Something else to note is that some files that were located in the proc file system for the 2.4 kernel have moved to the sysfs file system for the 2.6 kernel. For example, the USB device 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.

Lastly, you should make equivalent changes to any scripts called during your system's shutdown procedure. An example, on Red Hat systems, the shutdown process invokes the script /etc/init.d/halt during system shutdown, which references the proc file system but not the sysfs file system.

Compiling the Kernel

If you are a true Hacker and decide to rebuild the Linux 2.6 kernel, either for experience, modifications, or just to say you can do it, 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 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.

Note: Simply running make oldconfig may not create a kernel configuration that has all of the features that you want.

A few good ideas for smoothly migrating an existing system to the Linux 2.6 kernel follow:

  1. Change as few things as possible at the same time. It makes debugging easier!
  2. Remember the suggestion about ALSA. Install it on your 2.4 system first, then upgrade to 2.6.
  3. Also, if you are interested in experimenting with devs, don't switch to devfs during your initial migration to 2.6. You can always add it later by rebuilding your kernel, once you have the 2.6 kernel working correctly on your system.
Migrating Off-The-Shelf Systems to the 2.6 Kernel

If you are like me, you are probably running an off-the-shelf version of Linux. Something like SUSE Linux, Red Hat or other. One thing nice about these varieties of Linux is that they are built with integrated or loadable kernel module support for almost anything you would encounter on a random PC or on a specific embedded board. Nice!

If you upgrade via an off-the-shelf product and you have source code and configuration files for the kernel that you are running, you can migrate this configuration file to the 2.6 kernel by following the examples given previously in this article. It is also quite straight forward for activating any other features that you might want including ALSA. You should then be able to build and install your 2.6 kernel, any associated modules, reboot to test your system with the 2.6 kernel.

If you need a default configuration file, since you don't have a custom one, you can make one by executing the make defconfig command in the 2.6 kernel source directory. Granted the list of available kernel configuration variables differs for each architecture and often across different types of processors. For example, if you can't locate a specific flavor of Linux that supports your hardware platform, 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. The following example is for the Power PC (PPC) system:

make defconfig ARCH=PPC

Once you have generated a default 2.6 kernel configuration file, you need to then configure the kernel to provide drivers for the hardware in your system, either built-in or as loadable kernel modules.

Note: Giving an in-depth discussion about the details of hardware identification is beyond the scope of this article. However, two of the most useful utilities for identifying your hardware are the lspci and psusb utilities found on most Linux distributions. The lspci utility displays information about all of the PCI buses detected on your system. This utility lists the devices that are connected to them. This utility is quite useful for X86 motherboards with integrated sound and/or graphics adaptors, since it helps identify the actual chipsets used in the onboard PCI circuitry. The lsusb utility is a lot like the lspci utility expect it provides like information for the USB buses and attached devices in your system.

If you are creating your own kernel configuration file, one other item you may want to provide is information about the specific type of CPU used in your system hardware. You can set up this information by using the make xconfig configuration editor's Processor or Processor type and features pane. Resulting information about your processor is in the file /proc/cpuinfo, which you can display by running the cat /proc/cpuinfo command.

Lastly, you may still need to make changes to your new kernel configuration file based on custom kernel features that your system is using. You should check the file systems that are supported by the kernel that you are using. You can get information about the file systems that you are using from the file /proc/filesystems. You can read this information by running cat /proc/filesystems command. For example, the root file systems used by SUSE Linux Linux systems are usually reiserfs file systems, but the reiserfs file system is not active in the Linux 2.6 kernel by default. In the same vein, using an initial RAM sick in not active by default in the Linux 2.6 kernel, and neither is support for accessing SMB or CIFS file systems.

Conclusion

Once you have completed all the items in this paper, all that is left to do is to compile the kernel itself and install it. You build the kernel by executing the make command from the top-level kernel source directory. It requires the versions of gcc, make and binutils discussed in this article. Once the make command completes successfully, how you install the kernel and modules depends on the type of system you will run the kernel on. Say you are compiling this for an X86 system. Then you can use the make install and make modules_install commands. If you are creating the Linux 2.6 kernel for an embedded system, the make targets that you use for installation depend on where and how your kernel binaries are installed for use by the target system.

However, if you choose to use the prepackaged Linux distributions, such as SUSE Linux, your hardware should be detected automatically and the upgrade should go with few hitches.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell