oreilly.comSafari Books Online.Conferences.


Advanced Linux Installations and Upgrades with Kickstart
Pages: 1, 2

Custom RPMs and Package Groups

It's not uncommon for a Linux-savvy shop to create custom RPMs, such as homegrown software or site-specific adjustments of third-party packages. Kickstart's ties to RPM (via Anaconda) permit you to transparently add these RPMs to the installation process. This requires that you copy your RPMs to the tree, create a new group in the comps file, and update package headers.

The first step is the easiest: copy your custom RPMs to {install tree}/Fedora/RPMS. Make sure the files have appropriate read-access permissions.

The comps file is Fedora/base/comps.xml in the install tree. It contains definitions of package groups, which are collections of RPMs that you can select and install en masse. (A detailed tour of the comps file is beyond the scope of this article, but you need to know very little to add a group.)

It's cleaner and more future-proof to put your custom RPMs in a new, separate group. For example, create a <group> tag in comps.xml:



  <name>Local RPMs</name>

  <description>home-built RPMs</description>


    <packagereq type="default">package1</packagereq>
    <packagereq type="default">package2</packagereq>
    <packagereq type="optional">package3</packagereq>

I find it easiest to define new groups at the top of comps.xml, or better still to store them in a separate file and insert them into comps.xml as needed.

The <id> tag is a unique identifier for the group. Specify this name in ks.cfg preceded by an @ symbol to install all of the group's packages:

@ local_packages

The body of the <name> tag will appear on the Package Group Selection screen during a manual install, provided <uservisible> is true.

The aptly named <description> tag provides a brief description of the package group.

A global shop could take advantage of localization. Add extra <name> and <description> tags, each with the xml:lang attribute, to set that language's code:

<name xml:lang="fr">Trucs</name>
...  <description xml:lang="fr">Les Trucs...</description> 

<packagelist> holds the list of this group's packages in <packagereq> tags. The type attribute reflects a package's status within the group: optional (addable), default (included by default), or mandatory (unremovable).

Don't rely on the filename for <packagereq>. If you're unsure, query the RPM itself for its internal name:

$ rpm -q --qf '%{NAME}\n' -p some_file.rpm

Package headers contain information about each RPM in the install tree, such as checksums and dependencies. The query process is rather I/O-intensive, so pre-generating the data speeds up the install process. To (re-)generate the package headers, run genhdlist (from the package anaconda-runtime):

$ /usr/lib/anaconda-runtime/genhdlist \
        --productpath Fedora \

{path} is the fully-qualified path to the parent of the Fedora directory. For the curious, the header data goes in Fedora/base/hdlist and hdlist2.

Related Reading

Learning Red Hat Enterprise Linux & Fedora
By Bill McCarty

Using Kickstart to Upgrade

Vendors release new versions more frequently these days, which means OS upgrades are fast becoming a regular occurrence. Why click through the upgrades by hand when Kickstart can do them for you?

Upgrades are similar to installs, though ks.cfg requires fewer directives:

  • upgrade (as opposed to install)
  • installation method (for example, url or nfs)
  • installation language (lang)
  • installed language support (langsupport)
  • device spec, if you need the device for the install (device)
  • installation process keyboard setup (keyboard)
  • boot loader configuration (bootloader)

(Refer to the previous article in this series or the Kickstart documentation for detailed explanations of these directives.) The upgrade process ignores most other options, because it shouldn't change settings such as the time zone, the root password, or the network setup.

I've provided a sample upgrade, ks.cfg. It is very generic, and accordingly, you could have a single such file for an entire site.

The upgrade operation otherwise functions similarly to the installation: boot from your preferred media, direct Anaconda to ks.cfg, and walk away. Please note that boot media has very strong ties to the OS revision; you must boot from the newer CDs to upgrade. However, the machine hosting the installation media needn't run the same OS version, nor even the same OS.

My experience is that Kickstart's upgrade is nondestructive: while it doesn't delete any files or alter disk layouts, it installs new packages (including new kernels, though, so watch out if you rely on a custom kernel). That said, test the process before turning it loose on your environment.


There are several ways to customize the Kickstart process. Applying these techniques to your Kickstart infrastructure should take you closer to a completely hands-off process for installing and retasking machines.


Q Ethan McCallum grew from curious child to curious adult, turning his passion for technology into a career.

Return to the Linux DevCenter.

Sponsored by: