Hacking Red Hat Kickstart

How to create a single CD for fast and easy customized installation.

Installing Linux is a relatively easy task. However, I was faced with the task of installing it on multiple machines repeatedly, which is time consuming and prone to errors. This problem affected our whole group and other groups that relied on us. So I started using Red Hat Kickstart to automate the installs. This helped, but there still was room for improvement. What I ultimately wanted was an automated installation that would fit on one CD, dynamically partition the hard drives and contain all of the updated packages. I wanted to be able to start an installation then walk away from the machine, returning only when it was done. To accomplish this, I supplemented Kickstart with a customized version of the Red Hat installation program, Anaconda.

Although not officially supported, Red Hat has made available several tools and documentation to assist in customizing an installation. I describe a few of the possible ways to do this here, which should give the reader enough information to get started.

The following topics are covered in this article: replacing packages with updates, reducing the installation size to fit on one CD, utilizing Kickstart in the custom installation and creating a custom message screen.

The reader should have a good understanding of Linux installations in general. I also assume that no esoteric hardware is being used, as other customizations may be needed to accommodate such hardware.

Setting Up the Build Machine

The first step is to prepare the build computer. Because the installer tools are specific to a particular release, the build computer needs to have the same Red Hat release as the one used on the target(s). For our example, Red Hat 8.0 is being used. There are some differences between Red Hat 8.0 and previous versions, and you need to investigate them if you use a previous version.

Once the build computer has the correct release installed, the Anaconda packages need to be installed. These usually are not installed by default, so they need to be manually installed. They are located on the second CD of the standard Red Hat distribution and are named anaconda, anaconda-runtime and anaconda-help (optional).

The next step is to create a directory structure where the installation files will be located. The partition should have adequate space available, approximately 3GB. The actual location is based on your preference; for this article, the base directory is located at /RH80. Under this directory, we create directories for each of the CDs:

mkdir -p /RH80/CD{1,2,3}

We are not concerned with the source packages, so CD4 and CD5 are not included.

We make an additional directory where we can create the custom installation:

mkdir /RH80/ONE_CD

Now we can copy the contents of the CDs to the respective directories. Mount the first CD, then issue this command:

cp -a /mnt/cdrom/* /RH80/CD1/
Repeat this step for CD2 and CD3.

Copy the contents of the CD directories to the ONE_CD directory, but hard link them instead of actually copying the files. This saves space and is quicker:

cd /RH80
cp -al CD1/* ONE_CD/
cp -al CD{2,3}/RedHat/RPMS/* ONE_CD/RedHat/RPMS/

You'll get an overwrite TRANS.TBL message; you can answer no.

Selecting the Packages

Next we trim down the contents of the ONE_CD directory so it fits on one CD. I assume the CD size to be 700MB. I will not go into detail on how to do this, as the list of files to remove from the distribution is different from one installation to another. However, here are some tips for trimming down the distribution:

  • Don't include the source RPMs.

  • Remove the dosutils directory, as these will be automated installs.

  • Remove any unnecessary packages. This can be complicated, because you need to make sure that the dependencies are still intact.

You should keep a record of the files that were removed. You can use this list in case you need to back out, and you will need it later if you edit the comps.xml file.

For the package selection, I logged to a file all of the base and core group packages with their dependencies (according to the comps.xml file). In order to find this information, I used the script getGroupPkgs.py (see Resources):

cd /RH80/ONE_CD/RedHat/base
getGroupPkgs.py comps.xml > /RH80/pkglist

Any additional package names can be appended to the end of this file. After my list was complete, I removed the packages not on the list by using the syncRpms.py script (see Resources). The arguments are the package directory and the list of packages is generated from getGroupPkgs.py. This script removes the packages not listed in the package list and prints out the package names. We redirect that to a file so we have a log:

cd /RH80
syncRpms.py ONE_CD/RedHat/RPMS/ pkglist > pkgs_rem
We can monitor the installation size by using the du command. The -h option displays the result in human readable format, and the -s option gives a summary of the whole directory tree:
du -hs /RH80/ONE_CD
The hdlist files actually decrease in size after they are regenerated (see below), because we removed many of the packages. This in turn reduces the size of the CD image.

The tricky part about removing packages is they may break dependencies. Even though getGroupPkgs.py resolved the dependencies base on the comps.xml file, they are not guaranteed to be accurate. Adding additional packages may break dependencies as well. One way to verify their accuracy is to create a temporary RPM database, and then do a test install on that database with the packages you have selected:

cd /RH80/ONE_CD/RedHat/RPMS
mkdir /tmp/testdb
rpm --initdb --dbpath /tmp/testdb
rpm --test --dbpath /tmp/testdb -Uvh *.rpm

Look for any error messages regarding failed dependencies. If any appear, resolve the dependencies by either adding or removing files that caused the discrepancy, and repeat the above test.

Once the package dependencies have been resolved, you can download the package updates pertinent for your installation. Put these files under a separate directory:

mkdir -p /RH80/updates/RPMS/

Remove the old files from the build directory and then link the updated files to the build directory. Do this for each updated package (where old_rpmfile is the previous version of the package):

cd /RH80/ONE_CD/RedHat/RPMS/
rm
# ... remove each old rpm
cd /RH80/updates/RPMS/
cp -l
# ... do this for each rpm
You should keep a record of the updated packages, in case you need to back them out. It's also a good idea to check the dependencies and size one more time, in case they changed after the packages were updated.

Next, we check the internal checksum of each package with the -K option to rpm. First we need to import the key:

cd /RH80/ONE_CD/RedHat/RPMS
rpm --import /usr/share/rhn/RPM-GPG-KEY
rpm -K *.rpm | grep "NOT *OK"

This isn't strictly necessary, but because we downloaded package updates, this verifies they are valid.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Hacking Red Hat Kickstart

bschwarz's picture

I guess I don't quite follow what you are saying (using Mandrake...); can you elaborate?

I looked into Mandrake a bit, at the time, it didn't seem to be keeping up with RH installers. In particular, RH 8.0 has some new features, that did not seem to appear in Mandrake. I wanted to specifically target RH 8.0 because of the new changes.

I really didn't have enough room in the article to talk about Mandrake (since it was different).

Re: Hacking Red Hat Kickstart

Anonymous's picture

First I want to say that your article is good.

I just want to state that if you use Mandrake for installation you can save the package options at install time to a floppy. Later one can use that floppy to get the same installation at another machine. But I realize that this does not solve the other two CDs might include wanted packages problem. Hms now I also see that how this is appropriate for a network install.

Re: Hacking Red Hat Kickstart

bschwarz's picture

Ah, ok thanks for clarifying. I believe SuSE also provides this feature, which is very handy. Thanks for the input.

Re: Hacking Red Hat Kickstart

Anonymous's picture

-- Posted on Tuesday, April 01, 2003 by Brett Schwarz --

A posting from the future ?? Hey.. how 'bout some winning lottery numbers ?

getting Error 15 after Installation from grub

john's picture

I successfully installed AS3 from the procedures you have provided.
But it is throwing error from GRUB.

root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-2.4.21-27.EL ro root=/dev/hda2

Error 15: File not found

Press any key to continue.

I tried several times but in vain getting the same error.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix