|
|
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.
- Red Hat on a Qube 3: Introduction
- Using Flashtool to Upgrade Qube 3 Proms
- Inside the Cobalt GenIII Kernel RPM, Part 1: Preparing a Sandbox
- Inside the Cobalt GenIII Kernel RPM, Part 2: Making the Ext3 Patch
- Inside the Cobalt GenIII Kernel RPM, Part 3: Building to Spec
- Installing Red Hat Linux, Part 1: Stock Distribution
- Installing Red Hat Linux, Part 2: Customization for Cobalt
- Installing Red Hat Linux, Part 3: Booting the Qube 3
- Ideas for Managing Red Hat Linux on the Cobalt Qube 3
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.
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.
Luckily, the tarball of source code embedded in the Cobalt experimental kernel source rpm actually contains all the code necessary to support the desirable ext3 filesystem. It is merely disabled since the Sun/Cobalt engineers have not given their official acceptance of the filesystem on their Cobalt Generation III architecture devices.
Thus, the only task necessary to add ext3 support to the Cobalt kernel is to enable the wholly contained code. There is a file called defconfig inside the source code tarball which specifies which optional kernel features are enabled and disabled, and the ext3 choice is one of the features listed in that file.
In this section, one could simply untar the tarball, change the defconfig file in question, and repack the tarball. The resulting kernel would work just fine. However, this document walks through the steps of making a separate patch file which helps RPM manage this change separate from the actual tarball contents. This makes it easier in the future to incorporate and merge one's own custom kernels, without having to manually reapply simple and complex patches every time a new source code tarball version becomes available. Various collections of customization patches could then be enabled or disabled very simply, as will be explained in the next section.
This section outlines the creation of one patch file. Each patch file follows essentially the same procedure, but should have a short and mnemonic name for the patch. In this document, the name ext3fs is used for the patch to enable ext3 filesystem usage. Thus, a file called cobalt-linux-2.4.16C2_III-ext3fs.patch will be created and added to the source rpm build process.
Execute the source rpm's spec file's %prep section. The preparation section unpacks all listed source code, and then applies any existing patch files to that unpacked source code.
[me@desk:~/cobalt/rpm]$ rpm -bp SPECS/kernel-2.4.16C2_III.spec [...] + exit 0 [me@desk:~/cobalt/rpm]$ cd BUILD/kernel-2.4.16C2_III/linux-2.4.16C2_III/It is now easy to inspect the existing sources and create new patch files. They have been unpacked to the BUILD/kernel-2.4.16C2_III/linux-2.4.16C2_III/ area of the sandbox. (The kernel-* directory was named to match the rpm file; the linux-* directory was named or implied in the rpm's spec file for the destination of the source code tarball's contents.)
It may at first seem backwards to name the unmodified files according to the name of the patch. However, this scheme allows the changes to be made to the files with their rightful standard names. The makefiles and compilers might have a big problem with a modified something.c.mypatch, but can process a modified something.c just fine while ignoring the oddly named backup file. It may take a little practice and discipline to remember to make named backup files before editing, but some editors ease that task. All of these backup files are temporary, anyway, and will contribute to a single named *-ext3fs.patch file as explained below.
In reading the diff-style - and + notation below, this means to find and remove the first line, then add the second line in its place. This enables the ext3fs feature during subsequent compilation of the kernel.
If some patch required changes to more than one file, make named backups which match the patch's name for each file, and edit each of the other files under their original name, likewise.
[me@desk:~/.../i386]$ cd ../../ [me@desk:~/.../linux-2.4.16C2_III]$ gendiff . .ext3fs > cobalt-linux-2.4.16C2_III-ext3fs.patch [me@desk:~/.../linux-2.4.16C2_III]$ mv *.patch ../../../SOURCES/Making the diff file from the root of the expanded source tarball area makes a clean patch that does not contain the version-numbered directory names. This makes the patch file more robust if new tarballs with new version numbers are transplanted later.
It is a good idea to review the contents of the newly created *-ext3fs.patch file. The diff-style - and + notation will appear familiar, showing existing unchanged lines for context, and newly added or removed or replaced lines in each modified file.
The RPM build tool is able to read these diff patch files and re-apply the described changes to the files inside the tarball repeatedly whenever the rpm file is rebuilt. This makes applying changes to most future versions of the tarball much less painful and much more consistent than re-editing the files each time a new tarball version becomes available.
