Building a custom CentOS 7 kickstart disc, part 1

Note: this series of articles applies to CentOS 7; for CentOS 6, see this series.

CentOS (and of course, it’s upstream distro, Red Hat Enterprise Linux) has an extremely powerful, but somewhat poorly documented, tool for rapidly deploying machines and managing their configuration: kickstart. Kickstart lets you build a custom installation that can run hands-free. So not only is the installation quick and easy for you, you can be confident that your machines are configured exactly the way you want them to be.

Imagine that you have 25 web servers (or a mix of web servers, database servers, mail servers, etc.). It would be highly desirable to install identical software packages on all of those machines. In that way, you know that any application you build will run the same way on all machines.

If you use the standard install DVD, achieving such uniformity can be challenging. During the installation, it’s always possible that you might accidentally select a different mix of packages for one machine, especially if you are not using one of the standard installation types. Further, it’s quite likely that for your production environment you might need some additional packages that are not part of the standard CentOS distribution. For example, in our environment, we add apps like aide, httperf, zabbix, iftop, memcached, and swatch. If you have to add these packages manually after installation, you’ll spend a lot of time, and you might overlook a machine or a package, leading to inconsistent behavior down the road.

In addition to your software packages, you will likely need to make various system and software configurations. For example, you may need to configure httpd or mysql, or maybe you need to add a group to /etc/group or a user to /etc/passwd. It is critical that these configurations be done consistently on all machines.

The solution is to predefine your package selections with kickstart and let the automated installer guarantee the installation of the same applications on all machines. Further, the postinstaller capabilities of kickstart will allow you to install non-distro applications and perform any system configuration that you can do from a shell script.

If you want to make your life really easy, you can set up your kickstart to run from a single DVD.

Prepare a build system

You will need a CentOS 7 machine on which to assemble the packages and build the custom ISO file. This can be a physical or a virtual machine; my build machine runs under VMWare Fusion on a Mac. Download the DVD ISO for the install media. Be sure to validate your checksums before you get started. If you are going to build on a physical machine, burn the ISO to DVD. If you’re using a virtual build machine, you can just mount the ISO directly.

Install CentOS 7 on your build machine; choose “Desktop” for the installation type (unless you plan to build custom packages from source; if you need to do that, you’ll need to install the development tools as well).

On the build system, create a build directory: ~/kickstart_build. Create subdirectories like this:

Copy all the files from the isolinux directory on CentOS DVD into your ~/kickstart_build/isolinux directory.

Copy .discinfo from the CentOS DVD into your ~/kickstart_build/isolinux directory

Recursively copy the contents of the images directory on the CentOS DVD into your ~/kickstart_build/isolinux/images directory.

Copy the contents of the LiveOS directory on the CentOS DVD into your ~/kickstart_build/isolinux/LiveOS directory.

Get the comps.xml file from repodata. This file is named with a unique hex string for each release. In CentOS 7.0.1406, for example, it is called 4b9ac2454536a901fecbc1a5ad080b0efd74680c6e1f4b28fb2c7ff419872418-c7-x86_64-comps.xml.gz. Copy it to ~/kickstart_build/comps.xml.gz and gunzip it so that you have ~/kickstart_build/comps.xml.

Your kickstart config file will go into ~/kickstart_build/isolinux/ks. I like to have a separate directory for this, because I build a series of different config files for different machines or classes of machines.

Start from a sample configuration file

It is always best to start with a sample configuration file. CentOS makes it easy for you to get your hands on one. Just perform a standard installation on a machine. After the install, look in look in /root/anaconda-ks.cfg to get a sample kickstart configuration file.

Copy this file into ~/kickstart_build/isolinux/ks/ks.cfg.

If you want your kickstart to run completely unattended, you will need to make sure that the installer clears any existing partitions on the system before installing. Change this line:


Of course, if you’re not installing to sda, you may need to modify this line.

Do not use the --all option if you plan on running your kickstart to install to a multiboot system; you will blow away all your operating systems. Then again, I don’t know that kickstart makes much sense in such a scenario. You’re much safer installing manually.

Note: it seems that in CentOS 7, anaconda writes a line into this file that is not valid according to the kickstart installer. This line:

should be:

Note that the drive configuration here reflects the configuration of your build machine. If that is different from your target machine (for example, your build machine might use IDE drives, and your target might use SCSI, or you may want to use software RAID on the target machine), you’ll have to edit some of these lines. When you’re getting started, it’s easiest if you use a build machine configured identically to your target machine.

Copy the RPMs

You will need access to all the RPMs that you might possibly include in your kickstart (along with all their dependencies). These will be located on your install media in the Packages directory.

You will probably find it more convenient to copy them all to your local disk; I use this directory: ~/kickstart_build/all_rpms. This will allow you to combine RPMs from different install media or multiple repos if necessary.

Determine which packages to include

Look in the file ~kickstart_build/comps.xml (which you copied from repodata/comps.xml on disc 1 of the CentOS distribution). This defines the packages and their groups.

Your baseline kickstart configuration file will list the packages that are to be installed (under %packages). Groups are noted with a leading @. You can edit this list, but leave @core in the file, since that group has system-critical packages in it.

Add groups and packages to this list. If you want to really trim down your package list to make a tight distribution, you can use individual packages rather than groups, which may include more than you need. You can include a group and then explicitly exclude a specific package by listing the package with a - prepended to the name.

Next comes the most challenging part — compiling the RPMs and resolving dependencies.

Part 1 • Part 2Part 3Part 4

9 thoughts on “Building a custom CentOS 7 kickstart disc, part 1

  1. Hello,
    This is a great tutorial, thanks for putting this together.

    I have a workspace where I build the iso from a simple ks.cfg, where the only think I change from the default is set the network address on the interfaces and also add some static route in the %post section of the ks.cfg.

    I now have a requirement to add some custom rpms that I need in the machines. I noticed all these days when I am building the iso, I do NOT have a comps.xml. I do see the ‘@core’ in the %packages section of ks.cfg, however I do not see the comps.xml anywhere in the hierarchy. So I copied over the standard one that comes with the CentOS 6.5 (the OS I need), and I edited to add some rpms and remove ‘less’ (primarily to test to see if the comps.xml got picked up). Once I install the iso, I do NOT see the rpms I added and I still see ‘less’ when I had removed it from the comps.xml.

    I am terribly confused on where the ks.cfg is picking up the packages from because to being with I did not have a comps.xml. Is there a easier way to trace where it comes from?

    Thanks for your help!


  2. Followed your steps and got the kickstart install working. So many other resources online but none of them lay it down in such a precise manner. Although your RPM dependency checks did not work for me the way I thought it would, I was able to ensure the dependencies were satisfied in a different manner.

    Thank you very much for putting this together!

  3. Which release are you using?
    I’m using 1611 and having errors with the script.

    Can’t locate XML/ in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at ~/kickstart_build/utils/ line 3.
    BEGIN failed–compilation aborted at ~/kickstart_build/utils/ line 3

  4. Hi

    Thanks for this helpful article. I’m following your instructions to create a kick start image in Cantos 7.1.
    Copy .discinfo from the CentOS DVD into your ~/kickstart_build/isolinux directory
    I cant any file like that in my source USB. Any idea about that?

    Thanks in advance .

  5. After burning a DVD from the resultant ISO, the install failed with what appears to be a very early service that does a checksum on the installer. Obviously it’s going to fail as “my” ISO is now custom and doesn’t match the “factory” ISO. Has anyone else experienced this?

    I read back through the blog to see if I missed a step and it doesn’t appear that I did. I either missed something or these instructions work for a distribution earlier than 7.2.1511 where “something” changed.

    Any words of wisdom would be greatly appreciated.

  6. Previously in Red Hat Enterprise Linux 5 & 6, there was an image install.img which one was able to decompress as follows.

    [[email protected] ~]# unsquashfs install.img

    Then it would be edited by changing/appending some custom information in the file /squashfs-root/usr/bin/anaconda
    Where is the file which replaced install.img ?
    How do one expand it?
    Which file do one need to update instead of /squashfs-root/usr/bin/anaconda?
    How do one rebuild the new .img file?

  7. hello,i have a problem
    Previously in Red Hat Enterprise Linux 5 & 6, there was an image install.img which one was able to decompress as follows.

    [[email protected] ~]# unsquashfs install.img

    Then it would be edited by changing/appending some custom information in the file /squashfs-root/usr/bin/anaconda
    Where is the file which replaced install.img ?
    How do one expand it?
    Which file do one need to update instead of /squashfs-root/usr/bin/anaconda?
    How do one rebuild the new .img file?

Leave a Reply

Your email address will not be published. Required fields are marked *