qube3 Red Hat Linux on the Cobalt Qube 3

 

Installing Red Hat Linux on the Cobalt Qube 3 Appliance

The following is a technical recipe or "howto" document for one successful procedure to install the Red Hat Linux distribution onto a Sun Cobalt Qube 3 model internet appliance.

Warning! Use this procedure at your own risk.

Inside the Cobalt GenIII Kernel RPM, Part 1: Preparing a Sandbox

The Sun/Cobalt team has been working on a new version 2.4 series Linux kernel that works with the Qube 3 "Generation III" architecture hardware. As of this writing, this work is not yet completed, not fully tested, and not supported.

However, the engineers have made this kernel available for daring Qube 3 owners who don't mind voiding their warranty and support for their appliances. The quality of the new kernel is pretty strong.

Your choice: ext2 or ext3?

The experimental kernel provided by the Cobalt engineering team has not been compiled with support for the ext3 journalling filesystem. While this feature is the default standard for Red Hat Linux 7.2 users, and has generally been found to be a very robust feature for that distribution, it is still not tested enough on the Qube 3 architecture for the Sun folks to have enabled that filesystem in their kernel.

This document provides one major critical choice: whether to accept Sun/Cobalt's ext2-ready kernel as-is, or to rebuild the kernel to allow for the use of ext3 for greater filesystem integrity.

Also, since the Cobalt team developed their Linux distribution to use the Red Hat Package Manager (or RPM) tools, they have standardized the kernel development process on this tool as well. This is good for software development in general, as it makes for more consistent and automatable building processes, which makes for higher quality releases in general.

(A good book on the many benefits and techniques of using the RPM toolset is Maximum RPM, distributed freely online and also in book form by Red Hat, Inc.)

This section and the next walks through the installation and rebuilding of the kernel rpm files, which may be an unfamiliar process, even for those who have built kernels the "old-fashioned" way from source code tarballs. The next two sections walk through modifying the spec file and creating manageable patches for the srpm, by patching the kernel configuration file to enable the ext3 support. These three sections are worthwhile, but still optional.

The remaining sections of this document will have only minor distinctions that depend upon the ext2/ext3 choice made at this point. These distinctions will be labeled clearly.

Download the unsupported Cobalt kernel-* packages to the desktop machine. Read the available text files thoroughly.

ext2: To use the experimental Cobalt kernel as-is, which supports ext2 but not ext3, then download the .i386.rpm binary packages. The .src.rpm source code package is not required.

ext3: To use the experimental Cobalt kernel, rebuilt to support ext3 journalling, then download the .src.rpm source code package. Rebuilding this .src.rpm source code package will generate new releases of all three of the kernel-*.i386.rpm binary packages.

ext2: To use the experimental Cobalt kernel as-is, which supports ext2 but not ext3, then the steps outlined in the remainder of this section and the next section are not required. Proceed to Installing Red Hat Linux, Part 1: Stock Distribution.

ext3: To use the experimental Cobalt kernel, rebuilt to support ext3 journalling, continue this section and the following section.

Prepare an RPM-building sandbox on the desktop machine. This is a directory in a non-root user's home account space. Red Hat Linux provides an environment on the /usr/src/redhat tree, but this document will avoid using that area for two reasons.

The standard building sandbox has the mnemonic subdirectories: "SRPMS will BUILD from SOURCES via SPECS generating RPMS." Also include a private temporary directory. 

[me@desk:~/cobalt]$ mkdir rpm
[me@desk:~/cobalt]$ cd rpm
[me@desk:~/cobalt/rpm]$ mkdir SRPMS BUILD SOURCES SPECS RPMS tmp

The first reason for avoiding the /usr/src/redhat build area: avoiding cross-compile comingling. This procedure is developing new binary RPMs for a potentially completely different architecture from the one used on the desktop machine. Building Cobalt-ready RPMs in the non-Cobalt desktop's RPM-build area is an unnecessary mingling of unrelated files.

The second reason for avoiding the /usr/src/redhat build area: avoiding root risk. While many people build kernels as the root user, this is not recommended for this procedure, nor for rpm building in general. The root account is for administration, not for software development. The RPM build process is a highly script-execution oriented process, which increases the risk of catastrophic filesystem damage if something minor is wrong in the makefiles or RPM spec files. This document will edit the Cobalt RPM spec file to be non-root buildable. Hopefully more RPM spec files from leading developers will be made non-root buildable in the future.

Specify this clean sandbox in the user's .rpmmacros file before using RPM tools. 

[me@desk:~/cobalt/rpm]$ vi ~/.rpmmacros

+ %_topdir     %(echo $HOME)/cobalt/rpm
+ %_tmppath    %{_topdir}/tmp

The above assumes that there is no such file. The + notation used here indicates that we're adding these two lines to the file. If there is already a ~/.rpmmacros file, replace the existing definitions, or consider replacing the whole file for the duration of this procedure.

Place the experimental kernel source rpm file retrieved from Tim Hockin's site onto the desktop machine. Verify the files are ready. 

[me@desk:~/cobalt]$ ls -asFC
    [...]
30120 kernel-2.4.16C2_III-1.src.rpm

The modutils package from the same site will not be required for this procedure, as the package which Red Hat Linux provides works well on the Qube.

Install the experimental Cobalt kernel-2.4*.src.rpm into the sandbox area. 

[me@desk:~/cobalt/rpm]$ rpm -ivh ../kernel-2.4.16C2_III-1.src.rpm

When a source RPM is installed, it is installed to the currently configured build sandbox area. There are generally two categories of files embedded into a source RPM: a spec file installed to the SPECS/ area, and one or more source or patch files installed to the SOURCES area.

The core of the RPM build process lies in the spec file. The spec file describes a number of facets of the build process, including the process by which the source files are unpacked and patched and compiled, and also the manifest of all files which should be stored in the resulting binary RPM file, and also any extra installation checks or tasks to ensure the package, file and installation integrity. It also provides the rpm database meta-data such as the builders, the authors, the release license, version information, prerequisites, provided capabilities, and the changelog for the package.

In the case of this kernel source rpm, there is one "source" file. This is the .tar.gz tarball containing all of the mainline source code files for the 2.4 series kernel. While many people build kernels from just this sort of tarball directly, this procedure will show one example of how RPM can help the developer manage one or more independent patches separately, aiding customized kernel projects like this.

Next Section: Inside the Cobalt GenIII Kernel RPM, Part 2: Making the Ext3 Patch

Text and artwork are Copyright © 1996-2002 Ed Halley.
Linux is a registered trademark of Linus Torvalds.
Red Hat, and Red Hat Linux is a registered trademark of Red Hat, Inc.
Sun, Cobalt, and Qube are registered trademarks of Sun Microsystems, Inc.
Many thanks to Dax Kelson of Guru Labs, and to Tim Hockin of Sun Microsystems for their assistance and tools.
Copying in whole or in part, with author attribution, is expressly allowed.