Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells


News Installation Recommended Books Recommended Links Modifying ISO image to include kickstart file Creating a boot image that is using a remote kickstart file to install Red Hat Kickstart Pre- and Postinstall Scripts
Installation of Red Hat from a USB drive Installing RHEL via HTTP Minimization of boot ISO Kickstart Cheatsheet Installing via NFS VNC-based Installation in Anaconda Loopback filesystem
Minimization of boot ISO Networking Move config files from one server to another   Sysadmin Horror Stories Humor Etc

Note: This page is based on RHEL documentation


Automated installation method is useful if you have similar machines and absolutely necessary if you have cluster. Major Unix flavors such as Solaris used to have jumpstart. To compete, Red Hat created the kickstart which is implemented differently, as a special interface to Anaconda installer. Kind of Anaconda scripting interface.

At the end of each installation Anaconda writes the file with selected installation parameters in /root/anaconda-ks.cfg.

Anaconda creates a sample kickstart file based on the options that you selected during installation and write it to /root/anaconda-ks.cfg  at the end of each Red Hat install. A kickstart file is essentially a "response file" for the Anaconda installer;

To install a new system you need to modify this file, changing the configuration to suit the specification of the new system. If system is identical then just static IP needs to be changed (DHCP systems can be cloned without any changed of kickstat file)

The kickstart file contains the answers to all the questions that Anaconda asked during installation.

Using it allows to automate a RHEL installation as all you need is to find sufficiently similar system, borrow existing /root/anaconda-ks.cfg and modify IP stack parameters and possibly some other (partitioning, packages).

Typical steps in installing the system using kickstart

Kickstart installations can be performed using a local CD-ROM, a local hard drive, or via NFS, FTP, or HTTP. We will discuss HTTP based installation.

HTTP-based installation

To install a system using kickstart, you need to perform the following steps

  1. Create or modify existing on the other system kickstart file (see below)
  2. Create a boot media with the kickstart file or make the kickstart file available on the network.
  3. Make the installation tree available.
  4. Boot your system with a Red Hat Enterprise Linux 6 DVD and after it loads the installation screen,

    press the "Tab" key on the first option that reads "Install or upgrade an existing system."

    After pressing tab the following line should appear:

    vmlinuz initrd=initrd.img

    Edit the command line so that it retrieve kickstart file from the network. This assumes that the computer is connected to a network via the eth0 network interface and DHCK is present on the segment. For example:

    vmlinuz initrd=initrd.img ks= ksdevice=eth0


The kickstart file

Unlike current and crazy fashion of using XML configuration files even in cases where they definitely are not optional, the kickstart file is a simple text file, containing a list of items, each identified by a keyword. So it can be created and maintained with a regular text editor. And that's good, because in many case where XML is used, simple text file is sufficient. It is simpler to edit and less prone to errors.

Typically you borrow kickstart file from a similar system and then modify either using the Kickstart Configurator application, or manually. As at the end of each installation Anaconda writes the file /root/anaconda-ks.cfg. with all the installation parameters you specified for the system.

The only problem is that it assumed current partitioning preseved. So you need copy of MBR for the server to restore the sever from scratach.

If you are careful with the selection of packages and partitioning you should be able to reuse this file for similar servers.

Kickstart file is retrieved using either local storage (typically USB drive) or several networking protokols (NFS, HTTP. and FTP).

This allow the use of a single kickstart file to install Red Hat Enterprise Linux on multiple machines, for example belonging to a cluster.

Kickstart file should contain relevant network option

The network option allows you to specify how Anaconda should configure your network card(s). You can choose automatic configuration through either DHCP or BOOTP, or you can specify the IP address mask and gateway manually.

You have a couple of options here. As already mentioned, you can create customized kickstart files for each server and then hard-code the IP address into them.

Or if the segment on which the server resides has DHCP you can specify DHCP and then manually change it to static IP.

You can also do this in the %post section. This could involve looking up the IP address on a remote server or anything else that you come up with. The network configuration tool does accept command-line arguments, so it is possible to script this setting IP address, netmask and gateway for the server. Of course, for this to work, the server would need some form of network connectivity to start with, either a fixed IP that all machines being built use (although that really restricts you to building one machine at a time) or ideally DHCP.



Kickstart Configurator

32.1. Basic Configuration
32.2. Installation Method
32.3. Boot Loader Options
32.4. Partition Information
32.4.1. Creating Partitions
32.5. Network Configuration
32.6. Authentication
32.7. Firewall Configuration
32.7.1. SELinux Configuration
32.8. Display Configuration
32.8.1. General
32.8.2. Video Card
32.8.3. Monitor
32.9. Package Selection
32.10. Pre-Installation Script
32.11. Post-Installation Script
32.11.1. Chroot Environment
32.11.2. Use an Interpreter
32.12. Saving the File
Kickstart Configurator allows you to create or modify a kickstart file using a graphical user interface, so that you do not have to remember the correct syntax of the file.  It is pretty buggy.

To use Kickstart Configurator, you must be running the X Window System and have Kickstart Configurator installed on your system.

Kickstart Configurator is not installed by default, so you might need to install it with yum or your graphical package manager.

To start Kickstart Configurator, select Applications (the main menu on the panel) => System Tools => Kickstart, or type the command

As you are creating a kickstart file, you can select File => Preview at any time to review your current selections.

To start with an existing kickstart file, select File => Open and select the existing file.

Basic Configuration

Choose the language to use during the installation and as the default language to be used after installation from the Default Language menu.

Select the system keyboard type from the Keyboard menu.

From the Time Zone menu, choose the time zone to use for the system. To configure the system to use UTC, select Use UTC clock.

Enter the desired root password for the system in the Root Password text entry box. Type the same password in the Confirm Password text box. The second field is to make sure you do not mistype the password and then realize you do not know what it is after you have completed the installation. To save the password as an encrypted password in the file, select Encrypt root password. If the encryption option is selected, when the file is saved, the plain text password that you typed is encrypted and written to the kickstart file. Do not type an already encrypted password and select to encrypt it. Because a kickstart file is a plain text file that can be easily read, it is recommended that an encrypted password be used.

Select the Specify installation key checkbox to provide an installation key.

Choosing Target Architecture specifies which specific hardware architecture distribution is used during installation.

Choosing Reboot system after installation reboots your system automatically after the installation is finished.

Kickstart installations are performed in graphical mode by default. To override this default and use text mode instead, select the Perform installation in text mode option.

You can perform a kickstart installation in interactive mode. This means that the installation program uses all the options pre-configured in the kickstart file, but it allows you to preview the options in each screen before continuing to the next screen. To continue to the next screen, click the Next button after you have approved the settings or change them before continuing the installation. To select this type of installation, select the Perform installation in interactive mode option.

The Installation Method screen allows you to choose whether to perform a new installation or an upgrade. If you choose upgrade, the Partition Information and Package Selection options are disabled. They are not supported for kickstart upgrades. Choose the type of kickstart installation or upgrade from the following options:

GRUB is the default boot loader for Red Hat Enterprise Linux on x86 / x86_64 architectures. If you do not want to install a boot loader, select Do not install a boot loader. If you choose not to install a boot loader, make sure you create a boot diskette or have another way to boot your system, such as a third-party boot loader. You must choose where to install the boot loader (the Master Boot Record or the first sector of the /boot partition). Install the boot loader on the MBR if you plan to use it as your boot loader. To pass any special parameters to the kernel to be used when the system boots, enter them in the Kernel parameters text field. For example, if you have an IDE CD-ROM Writer, you can tell the kernel to use the SCSI emulation driver that must be loaded before using cdrecord by configuring hdd=ide-scsi as a kernel parameter (where hdd is the CD-ROM device). You can password protect the GRUB boot loader by configuring a GRUB password. Select Use GRUB password, and enter a password in the Password field. Type the same password in the Confirm Password text field. To save the password as an encrypted password in the file, select Encrypt GRUB password. If the encryption option is selected, when the file is saved, the plain text password that you typed is encrypted and written to the kickstart file. If the password you typed was already encrypted, unselect the encryption option. If Upgrade an existing installation is selected on the Installation Method page, select Upgrade existing boot loader to upgrade the existing boot loader configuration, while preserving the old entries.

Top Visited
Past week
Past month

Old News ;-)

[Aug 08, 2017] Unattended Installation of Red Hat Enterprise Linux 7 Operating System on Dell PowerEdge Servers Using iDRAC With Lifecycle Controller

The OS Deployment feature available in Lifecycle Controller enables you to deploy standard and custom operating systems on the managed system. You can also configure RAID before installing the operating system if it is not already configured. You can deploy the operating system using any of the following methods:

The unattended installation feature requires an OS configuration or answer file. During unattended installation, the answer file is provided to the OS loader. This activity requires minimal or no user intervention. Currently, the unattended installation feature is supported only for Microsoft Windows and Red Hat Enterprise Linux 7 operating systems from Lifecycle Controller.

Note: This paper only covers unattended installation of Red Hat Enterprise Linux 7 operating system from Lifecycle Controller. For more information about unattended installation of Microsoft Windows operating systems, see the “Unattended Installation of Windows Operating Systems

Automated Installations of Multiple RHEL-CentOS 7 Distributions using PXE Server and Kickstart Files

After the kernel and ramdisk loads and detects the Kickstart file, the installation process automatically starts without any intervention from user side needed. If you want to watch the installation process connect with a VNC client from a different computer using the address that the installer provides you and enjoy the view.

[Feb 05, 2017] Kickstart Tutorial – Practical Examples for RHEL 7 | CentOS 7 by Grzegorz Juszczak

January 7, 2017 |
Linux installation can be performed totally unattended using Kickstart file, which contains configuration, required setup and post installation tasks to fully automate installation process without being prompted for any input details. Kickstart file can be placed in the remote repository or can be included in ISO image in order to be read by Anaconda installer during system installation.

In this tutorial we present some practical solutions that can be placed in kickstart file to automate CentOS 7 / Red Hat 7 installation tasks.

[Mar 01, 2014]  Can't Kickstart with USB Thumb Drive

See also Error Downloading Kickstart File Usb
Sept 6, 2007 | CentOS Bug Tracker

I'm passing "linux ks=hd:sdb1:/ks.cfg," but I get a message saying:

"Unable to download kickstart file, Please modify parameters below or press cancel to proceed 
	as an interactive installation."

I use the exact same boot options with CentOS 4 without any problems. It seems like the usb driver isn't loading properly. There was one time where I just hit okay at the anaconda dialog and it somehow found the usb drive. But, ever other time, the usb drive is simply not recognized.

With CentOS 4, the drive was always recognized as sdb1 during the boot process.

A: I can confirm this issue.

I managed to find a dirty solution for this bug, however.
When the error message appears, remove & re-insert the usb key and hit "OK". This will cause the drive to be recognized and the installation will continue.

Anyway, please fix this, because this sure takes a bite out of unattended installations.

Thank you,

mlum (reporter)
2008-08-15 01:50

I attempted to do a fully-automated install with a U3 USB key, with the following configured under /boot/grub/grub.conf, and /kickstart/ks.cfg on the key:

kernel /boot/vmlinuz ks=hd:sda1/kickstart/ks.cfg

A the point where the install is going to look-up the kickstart file, I see the following output to the anaconda log:

16:40:23 INFO: getting kickstart file from harddrive
16:40:23 INFO: Loading ks from device sda1 on path kickstart/ks.cfg
16:40:23 INFO: getFileFromBlockDevice(sda1, kickstart/ks.cfg)
16:40:24 ERROR: failed to mount /dev/sda1: No such device or address
16:40:30 INFO: getting kickstart file from harddrive
16:40:30 INFO: Loading ks from device sda1 on path kickstart/ks.cfg
16:40:30 INFO: getFileFromBlockDevice(sda1, kickstart/ks.cfg)
16:40:30 INFO: Searching for file on path /tmp/mnt/kickstart/ks.cfg
16:40:30 INFO: file copied to /tmp/ks.cfg
16:40:30 INFO: setting up kickstart
16:40:30 INFO: kickstartFromHD

The point where ******** are indicated, is where I was prompted to correct the path to ks.cfg. I only pressed the <enter> key, and the remainder of the log is from the successful reading of the kickstart file.

I did not have to remove the USB kick to re-register the dialog closure, but to only hit the OK button after the initial pop-up dialog.

I am using 2.6.18-53.el5xen, CentOS release 5 (Final).

MarcusMoeller (reporter)
2008-08-27 09:11

Kickstart and usb may always be a problem as you are cannot be sure about the assigned device node (depending on other attached hardware components).

Have you tried to boot up Anaconda (with the USB device attached), switched to a virtual console and did a cat /proc/partitions to figure out the node of the USB device?

Best Regards

[May 21, 2011] TipsAndTricks-KickStart - CentOS Wiki

For full documentations, please see

Tuning the %packages section

When using %packages to define the set of packages that should be installed there are a number of more or less documented options that can be set:

Dependencies between packages will be automatically resolved. This option has been deprecated in Centos 5, dependencies are resolved automatically every time now.

Skips the installation of files that are marked as documentation (all files that are listed when you do rpm -qld <packagename>)

Skips installation of @Base. This won't work unless you know what you're doing as it might leave out packages required by post installation scripts
Ignore missing packages and groups instead of asking what to do. This option has been deprecated in Centos 5, dependencies are resolved automatically every time now.

Example of minimal package selection for CentOS 4:

%packages --resolvedeps --excludedocs --nobase

please note that essential stuff will be missing. There will be no rpm, no yum, no vim, no dhcp-client and no keyboard layouts. Kudzu is required, because the installer fails if it is missing.

Example of minimal package selection for CentOS 5:

%packages --excludedocs --nobase

Again, this will leave you with a *very* basic system that will be missing almost every feature you might expect.

The --resolvedeps used with CentOS 4 is not required for CentOS 5 as the newer installer always resolves dependencies.


If you start out with a unpartitioned disk, or a virtual machine on a unpartitioned image, use the --initlabel parameter to clearpart to make sure that the disklabel is initialized, or Anaconda will ask you to confirm creation of a disklabel interactively. For instance, to clean all partitions on xvda, and initialize the disklabel if it does not exist yet, you could use:

clearpart --all --initlabel --drives=xvda

Running anaconda in real text-mode

You probably already know that you can make anaconda run with a ncurses interface instead of the X11 interface by adding the line "text" to your kickstart file. But there's another option: install in real shell-like textmode. Replace the "text"-line with a "cmdline"-line in your kickstart file and anaconda will do the whole installation in textmode. Especially when you use %packages --nobase or run complex %post scripts this will probably save hours of debugging, because you can actually see the output of all scripts that run during the installation.

Enable/disable firstboot

You all know firstboot, the druid that helps you to set up the system after install. It can be enabled and disabled by adding either "firstboot --enable" or "firstboot --disable" to the command section of your kickstart file.

What the different terminals display

The installation dialog when using text or cmdline
A shell prompt
The install log displaying messages from install program
The system log displaying messages from kernel, etc.
All other messages
The installation dialog when using the graphical installer

Logging %pre and %post

When using a %pre or %post script you can simply log the output to a file by using --log=/path/to/file

%post --log=/root/my-post-log
echo 'Hello, World!'

Another way of logging and displaying the results on the screen would be the following:

exec < /dev/tty3 > /dev/tty3
chvt 3
echo "################################"
echo "# Running Post Configuration   #"
echo "################################"
echo 'Hello, World!'
) 2>&1 | /usr/bin/tee /var/log/post_install.log
chvt 1

Trusted interfaces for firewall configuration

You can use the --trust option to the firewall option multiple times to trust multiple interfaces:

# Enable firewall, open port for ssh and make eth1 and eth2 trusted
firewall --enable --ssh --trust=eth1 --trust=eth2

Use a specific network interface for kickstart

When your system has more than one network interface anaconda asks you which one you'd like to use for the kickstart process. This decision can be made at boot time by adding the ksdevice paramter and setting it accordingly. To run kickstart via eth0 simply add ksdevice=eth0 to the kernel command line.

A second method is using ksdevice=link. In this case anaconda will use the first interface it finds that has a active link.

A third method works if you are doing PXE based installations. Then you add IPAPPEND 2 to the PXE configuration file and use ksdevice=bootif. In this case anaconda will use the interface that did the PXE boot (this does not necessarily needs to be the first one with a active link).

Within the kickstart config itself you need to define the network interfaces using the network statement. If you are using method 2 or 3 then you don't know which device actually will be used. If you don't specify a device for the network statement anaconda will configure the device used for the kickstart process and set it up according to your network statement.

Forcing kickstart to ask for network configuration

Starting at CentOS 5, there a undocumented option that enable a prompt asking for network configuration during the installation. At the network statement, put the query keyword at the --bootproto= networking configuration, as we see below:

network --device=eth0 --bootproto=query

And a dialog box will appear asking for IP addressing, as well the hostname configuration.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles



Kickstart Options

autopart  (optional)
Automatically create partitions — 1 GB or more root (/) partition, a swap partition, and an appropriate boot partition for the architecture. One or more of the default partition sizes can be redefined with the part  directive.
ignoredisk  (optional)
Causes the installer to ignore the specified disks. This is useful if you use autopartition and want to be sure that some disks are ignored. For example, without ignoredisk, attempting to deploy on a SAN-cluster the kickstart would fail, as the installer detects passive paths to the SAN that return no partition table. The --only-use  option specifies that only the disks listed will be used during installion.

The ignoredisk  option is also useful if you have multiple paths to your disks.

The syntax is:
ignoredisk --drives=drive1,drive2,...
where driveN is one of sda, sdb,..., hda,... etc.
autostep  (optional)
Similar to interactive  except it goes to the next screen for you. It is used mostly for debugging.
auth  or authconfig  (required)
Sets up the authentication options for the system. It is similar to the authconfig  command, which can be run after the install. By default, passwords are normally encrypted and are not shadowed.
bootloader  (required)
Specifies how the boot loader should be installed. This option is required for both installations and upgrades.
clearpart  (optional)
Removes partitions from the system, prior to creation of new partitions. By default, no partitions are removed.


If the clearpart  command is used, then the --onpart  command cannot be used on a logical partition.
cmdline  (optional)
Perform the installation in a completely non-interactive command line mode. Any prompts for interaction halts the install. This mode is useful on IBM System z systems with the x3270 console.
device  (optional)
On most PCI systems, the installation program autoprobes for Ethernet and SCSI cards properly. On older systems and some PCI systems, however, kickstart needs a hint to find the proper devices. The device  command, which tells the installation program to install extra modules, is in this format:
device <type> <moduleName> --opts=<options>
driverdisk  (optional)
Driver diskettes can be used during kickstart installations. You must copy the driver diskettes's contents to the root directory of a partition on the system's hard drive. Then you must use the driverdisk  command to tell the installation program where to look for the driver disk.
driverdisk <partition> [--type=<fstype>]
Alternatively, a network location can be specified for the driver diskette:
driverdisk --source=ftp://path/to/dd.img
driverdisk --source=http://path/to/dd.img
driverdisk --source=nfs:host:/path/to/img
firewall  (optional)
This option corresponds to the Firewall Configuration screen in the installation program:
firewall --enabled|--disabled [--trust=] <device> [--port=]
firstboot  (optional)
Determine whether the Setup Agent starts the first time the system is booted. If enabled, the firstboot  package must be installed. If not specified, this option is disabled by default.
halt  (optional)
Halt the system after the installation has successfully completed. This is similar to a manual installation, where anaconda displays a message and waits for the user to press a key before rebooting. During a kickstart installation, if no completion method is specified, this option is used as the default.

The halt  option is roughly equivalent to the shutdown -h  command.

For other completion methods, refer to the poweroff, reboot, and shutdown  kickstart options.
graphical  (optional)
Perform the kickstart installation in graphical mode. This is the default.
install  (optional)
Tells the system to install a fresh system rather than upgrade an existing system. This is the default mode. For installation, you must specify the type of installation from cdrom, harddrive, nfs, or url  (for FTP or HTTP installations). The install  command and the installation method command must be on separate lines.
interactive  (optional)
Uses the information provided in the kickstart file during the installation, but allow for inspection and modification of the values given. You are presented with each screen of the installation program with the values from the kickstart file. Either accept the values by clicking Next or change the values and click Next to continue. Refer to the autostep  command.
iscsi  (optional)
iscsi --ipaddr= [options].

Specifies additional iSCSI storage to be attached during installation. If you use the iscsi parameter, you must also assign a name to the iSCSI node, using the iscsiname parameter. The iscsiname parameter must appear before the iscsi parameter in the kickstart file.

We recommend that wherever possible you configure iSCSI storage in the system BIOS or firmware (iBFT for Intel systems) rather than use the iscsi parameter. Anaconda automatically detects and uses disks configured in BIOS or firmware and no special configuration is necessary in the kickstart file.

If you must use the iscsi parameter, ensure that networking is activated at the beginning of the installation, and that the iscsi parameter appears in the kickstart file before you refer to iSCSI disks with parameters such as clearpart or ignoredisk.

iscsiname  (optional)
Assigns a name to an iSCSI node specified by the iscsi parameter. If you use the iscsi parameter in your kickstart file, this parameter is mandatory, and you must specify iscsiname in the kickstart file before you specify iscsi.
key  (optional)
Specify an installation key, which is needed to aid in package selection and identify your system for support purposes.
keyboard  (required)
Sets system keyboard type. Here is the list of available keyboards on i386, Itanium, and Alpha machines:
be-latin1, bg, br-abnt2, cf, cz-lat2, cz-us-qwertz, de, de-latin1, 
de-latin1-nodeadkeys, dk, dk-latin1, dvorak, es, et, fi, fi-latin1, 
fr, fr-latin0, fr-latin1, fr-pc, fr_CH, fr_CH-latin1, gr, hu, hu101, 
is-latin1, it, it-ibm, it2, jp106, la-latin1, mk-utf, no, no-latin1, 
pl, pt-latin1, ro_win, ru, ru-cp1251, ru-ms, ru1, ru2,  ru_win, 
se-latin1, sg, sg-latin1, sk-qwerty, slovene, speakup,  speakup-lt, 
sv-latin1, sg, sg-latin1, sk-querty, slovene, trq, ua,  uk, us, us-acentos
The file /usr/lib/python2.2/site-packages/rhpl/  also contains this list and is part of the rhpl  package.
lang  (required)
Sets the language to use during installation and the default language to use on the installed system. For example, to set the language to English, the kickstart file should contain the following line:
lang en_US
The file /usr/share/system-config-language/locale-list  provides a list of the valid language codes in the first column of each line and is part of the system-config-language  package.

Certain languages (mainly Chinese, Japanese, Korean, and Indic languages) are not supported during text mode installation. If one of these languages is specified using the lang command, installation will continue in English though the running system will have the specified language by default.

langsupport  (deprecated)
The langsupport keyword is deprecated and its use will cause an error message to be printed to the screen and installation to halt. Instead of using the langsupport keyword, you should now list the support package groups for all languages you want supported in the %packages  section of your kickstart file. For instance, adding support for French means you should add the following to %packages:
logvol  (optional)
Create a logical volume for Logical Volume Management (LVM) with the syntax:
logvol <mntpoint> --vgname=<name> --size=<size> --name=<name> <options>
The options are as follows: Create the partition first, create the logical volume group, and then create the logical volume. For example:
part pv.01 --size 3000 
volgroup myvg pv.01
logvol / --vgname=myvg --size=2000 --name=rootvol
logging  (optional)
This command controls the error logging of anaconda during installation. It has no effect on the installed system.
mediacheck  (optional)
If given, this will force anaconda to run mediacheck on the installation media. This command requires that installs be attended, so it is disabled by default.
monitor  (optional)
If the monitor command is not given, anaconda will use X to automatically detect your monitor settings. Please try this before manually configuring your monitor.
mouse  (deprecated)
The mouse keyword is deprecated.
network  (optional)
Configures network information for the system. If the kickstart installation does not require networking (in other words, it is not installed over NFS, HTTP, or FTP), networking is not configured for the system. If the installation does require networking and network information is not provided in the kickstart file, the installation program assumes that the installation should be done over eth0 via a dynamic IP address (BOOTP/DHCP), and configures the final, installed system to determine its IP address dynamically. The network  option configures networking information for kickstart installations via a network as well as for the installed system.
multipath  (optional)
Specifies a multipath device in the format:
multipath --name=mpathX --device=device_name --rule=policy
For example:
multipath --name=mpath0 --device=/dev/sdc --rule=failover
The available options are:
part  or partition  (required for installs, ignored for upgrades)
Creates a partition on the system.

If more than one Red Hat Enterprise Linux installation exists on the system on different partitions, the installation program prompts the user and asks which installation to upgrade.


All partitions created are formatted as part of the installation process unless --noformat  and --onpart  are used.

For a detailed example of part  in action, refer to Section 31.4.1, "Advanced Partitioning Example".


If partitioning fails for any reason, diagnostic messages appear on virtual console 3.
poweroff  (optional)
Shut down and power off the system after the installation has successfully completed. Normally during a manual installation, anaconda displays a message and waits for the user to press a key before rebooting. During a kickstart installation, if no completion method is specified, the halt  option is used as default.

The poweroff  option is roughly equivalent to the shutdown -p  command.


The poweroff  option is highly dependent on the system hardware in use. Specifically, certain hardware components such as the BIOS, APM (advanced power management), and ACPI (advanced configuration and power interface) must be able to interact with the system kernel. Contact your manufacturer for more information on you system's APM/ACPI abilities.

For other completion methods, refer to the halt, reboot, and shutdown  kickstart options.

raid  (optional)
Assembles a software RAID device. This command is of the form:
raid <mntpoint> --level=<level> --device=<mddevice> <partitions*>
The following example shows how to create a RAID level 1 partition for /, and a RAID level 5 for /usr, assuming there are three SCSI disks on the system. It also creates three swap partitions, one on each drive.
part raid.01 --size=60 --ondisk=sda
part raid.02 --size=60 --ondisk=sdb 
part raid.03 --size=60 --ondisk=sdc
part swap --size=128 --ondisk=sda  
part swap --size=128 --ondisk=sdb  
part swap --size=128 --ondisk=sdc
part raid.11 --size=1 --grow --ondisk=sda  
part raid.12 --size=1 --grow --ondisk=sdb  
part raid.13 --size=1 --grow --ondisk=sdc
raid / --level=1 --device=md0 raid.01 raid.02 raid.03  
raid /usr --level=5 --device=md1 raid.11 raid.12 raid.13
For a detailed example of raid  in action, refer to Section 31.4.1, "Advanced Partitioning Example".
reboot  (optional)
Reboot after the installation is successfully completed (no arguments). Normally, kickstart displays a message and waits for the user to press a key before rebooting.

The reboot  option is roughly equivalent to the shutdown -r  command.

Specify reboot  to automate installation fully when installing in cmdline mode on System z.

For other completion methods, refer to the halt, poweroff, and shutdown  kickstart options.

The halt  option is the default completion method if no other methods are explicitly specified in the kickstart file.


Use of the reboot  option may result in an endless installation loop, depending on the installation media and method.
repo  (optional)
Configures additional yum repositories that may be used as sources for package installation. Multiple repo lines may be specified.
repo --name=<repoid> [--baseurl=<url>| --mirrorlist=<url>]
rootpw  (required)
Sets the system's root password to the <password> argument.
rootpw [--iscrypted] <password>
selinux  (optional)
Sets the state of SELinux on the installed system. SELinux defaults to enforcing in anaconda.
selinux [--disabled|--enforcing|--permissive]


If the selinux  option is not present in the kickstart file, SELinux is enabled and set to --enforcing  by default.

services  (optional)
Modifies the default set of services that will run under the default runlevel. The services listed in the disabled list will be disabled before the services listed in the enabled list are enabled.

Do not include spaces in the list of services

If you include spaces in the comma-separated list, kickstart will enable or disable only the services up to the first space. For example:

services --disabled auditd, cups,smartd,nfslock 

will disable only the auditd service. To disable all four services, this entry should include no spaces between services:

services --disabled auditd,cups,smartd,nfslock 

shutdown  (optional)
Shut down the system after the installation has successfully completed. During a kickstart installation, if no completion method is specified, the halt  option is used as default.

The shutdown  option is roughly equivalent to the shutdown  command.

For other completion methods, refer to the halt, poweroff, and reboot  kickstart options.
skipx  (optional)
If present, X is not configured on the installed system.
text  (optional)
Perform the kickstart installation in text mode. Kickstart installations are performed in graphical mode by default.
timezone  (required)
Sets the system time zone to <timezone> which may be any of the time zones listed by timeconfig.
timezone [--utc] <timezone>
upgrade  (optional)
Tells the system to upgrade an existing system rather than install a fresh system. You must specify one of cdrom, harddrive, nfs, or url  (for FTP and HTTP) as the location of the installation tree. Refer to install  for details.
user  (optional)
Creates a new user on the system.
user --name=<username> [--groups=<list>] [--homedir=<homedir>] [--password=<password>] [--iscrypted] [--shell=<shell>] [--uid=<uid>]
vnc  (optional)
Allows the graphical installation to be viewed remotely via VNC. This method is usually preferred over text mode, as there are some size and language limitations in text installs. With no options, this command will start a VNC server on the machine with no password and will print out the command that needs to be run to connect a remote machine.
vnc [--host=<hostname>] [--port=<port>] [--password=<password>]
volgroup  (optional)
Use to create a Logical Volume Management (LVM) group with the syntax:
volgroup <name> <partition> <options>
The options are as follows: Create the partition first, create the logical volume group, and then create the logical volume. For example:
part pv.01 --size 3000 
volgroup myvg pv.01 
logvol / --vgname=myvg --size=2000 --name=rootvol
For a detailed example of volgroup  in action, refer to Section 31.4.1, "Advanced Partitioning Example".
xconfig  (optional)
Configures the X Window System. If this option is not given, the user must configure X manually during the installation, if X was installed; this option should not be used if X is not installed on the final system.
%include  (optional)
Use the %include /path/to/file  command to include the contents of another file in the kickstart file as though the contents were at the location of the %include  command in the kickstart file.

Advanced Partitioning Example

The following is a single, integrated example showing the clearpart, raid, part, volgroup, and logvol  kickstart options in action:
clearpart --drives=hda,hdc --initlabel  
# Raid 1 IDE config 
part raid.11    --size 1000     --asprimary     --ondrive=hda 
part raid.12    --size 1000     --asprimary     --ondrive=hda 
part raid.13    --size 2000     --asprimary     --ondrive=hda 
part raid.14    --size 8000                     --ondrive=hda 
part raid.15    --size 1 --grow                 --ondrive=hda             
part raid.21    --size 1000     --asprimary     --ondrive=hdc 
part raid.22    --size 1000     --asprimary     --ondrive=hdc 
part raid.23    --size 2000     --asprimary     --ondrive=hdc 
part raid.24    --size 8000                     --ondrive=hdc 
part raid.25    --size 1 --grow                 --ondrive=hdc  

# You can add --spares=x  
raid /          --fstype ext3 --device md0 --level=RAID1 raid.11 raid.21 
raid /safe      --fstype ext3 --device md1 --level=RAID1 raid.12 raid.22 
raid swap       --fstype swap --device md2 --level=RAID1 raid.13 raid.23 
raid /usr       --fstype ext3 --device md3 --level=RAID1 raid.14 raid.24 
raid pv.01      --fstype ext3 --device md4 --level=RAID1 raid.15 raid.25  

# LVM configuration so that we can resize /var and /usr/local later 
volgroup sysvg pv.01     
logvol /var             --vgname=sysvg  --size=8000     --name=var 
logvol /var/freespace   --vgname=sysvg  --size=8000     --name=freespacetouse 
logvol /usr/local       --vgname=sysvg  --size=1 --grow --name=usrlocal
This advanced example implements LVM over RAID, as well as the ability to resize various directories for future growth.

You can use a kickstart file to install every available package by specifying @Everything  or simply *  in the %packages  section. Red Hat does not support this type of installation.

Moreover, using a kickstart file in this way will introduce package and file conflicts onto the installed system. Packages known to cause such problems are assigned to the @Conflicts  group. If you specify @Everything  in a kickstart file, be sure to exclude @Conflicts  or the installation will fail:
Note that Red Hat does not support the use of @Everything  in a kickstart file, even if you exclude @Conflicts.

Use the %packages  command to begin a kickstart file section that lists the packages you would like to install (this is for installations only, as package selection during upgrades is not supported).

Packages can be specified by group or by individual package name, including with globs using the asterisk. The installation program defines several groups that contain related packages. Refer to the variant/repodata/comps-*.xml  file on the first Red Hat Enterprise Linux CD-ROM for a list of groups. Each group has an id, user visibility value, name, description, and package list. In the package list, the packages marked as mandatory are always installed if the group is selected, the packages marked default are selected by default if the group is selected, and the packages marked optional must be specifically selected even if the group is selected to be installed.

Available groups vary slightly between different variants of Red Hat Enterprise Linux 5, but include:

In most cases, it is only necessary to list the desired groups and not individual packages. Note that the Core  and Base  groups are always selected by default, so it is not necessary to specify them in the %packages  section.

Here is an example %packages  selection:

@ X Window System 
@ GNOME Desktop Environment 
@ Graphical Internet 
@ Sound and Video dhcp
As you can see, groups are specified, one to a line, starting with an @  symbol, a space, and then the full group name as given in the comps.xml  file. Groups can also be specified using the id for the group, such as gnome-desktop. Specify individual packages with no additional characters (the dhcp  line in the example above is an individual package).

You can also specify which packages not to install from the default package list:

The following options are available for the %packages  option:
Do not install the @Base group. Use this option if you are trying to create a very small system.
The --resolvedeps option has been deprecated. Dependencies are resolved automatically every time now.
The --ignoredeps option has been deprecated. Dependencies are resolved automatically every time now.
Ignore the missing packages and groups instead of halting the installation to ask if the installation should be aborted or continued. For example:
%packages --ignoremissing
interpreter /usr/bin/python 
Allows you to specify a different scripting language, such as Python. Replace /usr/bin/python with the scripting language of your choice.


Here is an example %pre  section:
for file in /proc/ide/h* do   
	mymedia=`cat $file/media`   
	if [ $mymedia == "disk" ] ; then       
		hds="$hds `basename $file`"   
set $hds 
numhd=`echo $#`  
drive1=`echo $hds | cut -d' ' -f1` 
drive2=`echo $hds | cut -d' ' -f2`  
#Write out partition scheme based on whether there are 1 or 2 hard drives  
if [ $numhd == "2" ] ; then   
	#2 drives   
	echo "#partitioning scheme generated in %pre for 2 drives" > /tmp/part-include   
	echo "clearpart --all" >> /tmp/part-include   
	echo "part /boot --fstype ext3 --size 75 --ondisk hda" >> /tmp/part-include   
	echo "part / --fstype ext3 --size 1 --grow --ondisk hda" >> /tmp/part-include   
	echo "part swap --recommended --ondisk $drive1" >> /tmp/part-include   
	echo "part /home --fstype ext3 --size 1 --grow --ondisk hdb" >> /tmp/part-include 
	#1 drive   
	echo "#partitioning scheme generated in %pre for 1 drive" > /tmp/part-include   
	echo "clearpart --all" >> /tmp/part-include   
	echo "part /boot --fstype ext3 --size 75" >> /tmp/part-include   
	echo "part swap --recommended" >> /tmp/part-include   
	echo "part / --fstype ext3 --size 2048" >> /tmp/part-include   
	echo "part /home --fstype ext3 --size 2048 --grow" >> /tmp/part-include 
This script determines the number of hard drives in the system and writes a text file with a different partitioning scheme depending on whether it has one or two drives. Instead of having a set of partitioning commands in the kickstart file, include the line:
%include /tmp/part-include
The partitioning commands selected in the script are used.


Post-installation Script

You have the option of adding commands to run on the system once the installation is complete. This section must be at the end of the kickstart file and must start with the %post  command. This section is useful for functions such as installing additional software and configuring an additional nameserver.



Register the system to a Red Hat Network Satellite, using a subshell to log the result in Red Hat Enterprise Linux 5.4 and earlier:
( # Note that in this example we run the entire %post section as a subshell for logging.
wget -O- | /bin/bash
/usr/sbin/rhnreg_ks --activationkey=<activationkey>
# End the subshell and capture any output to a post-install log file.
) 1>/root/post_install.log 2>&1
Register the system to a Red Hat Network Satellite, using the --log  option to log the result in Red Hat Enterprise Linux 5.5 and later:
%post --log=/root/ks-post.log
wget -O- | /bin/bash
/usr/sbin/rhnreg_ks --activationkey=<activationkey>
Run a script named runme  from an NFS share:
mkdir /mnt/temp 
mount -o nolock /mnt/temp open -s -w -- 
umount /mnt/temp


NFS file locking is not supported while in kickstart mode, therefore -o nolock  is required when mounting an NFS mount.

Making the Kickstart File Available

A kickstart file must be placed in one of the following locations: Normally a kickstart file is copied to the boot diskette, or made available on the network. The network-based approach is most commonly used, as most kickstart installations tend to be performed on networked computers.

Let us take a more in-depth look at where the kickstart file may be placed.

31.8.1. Creating Kickstart Boot Media

Diskette-based booting is no longer supported in Red Hat Enterprise Linux. Installations must use CD-ROM or flash memory products for booting. However, the kickstart file may still reside on a diskette's top-level directory, and must be named ks.cfg.

To perform a CD-ROM-based kickstart installation, the kickstart file must be named ks.cfg  and must be located in the boot CD-ROM's top-level directory. Since a CD-ROM is read-only, the file must be added to the directory used to create the image that is written to the CD-ROM. Refer to Section 2.4.1, "Alternative Boot Methods" for instructions on creating boot media; however, before making the file.iso  image file, copy the ks.cfg  kickstart file to the isolinux/  directory.

To perform a pen-based flash memory kickstart installation, the kickstart file must be named ks.cfg  and must be located in the flash memory's top-level directory. Create the boot image first, and then copy the ks.cfg  file.


Creation of USB flash memory pen drives for booting is possible, but is heavily dependent on system hardware BIOS settings. Refer to your hardware manufacturer to see if your system supports booting to alternate devices.

Making the Kickstart File Available on the Network

Network installations using kickstart are quite common, because system administrators can easily automate the installation on many networked computers quickly and painlessly. In general, the approach most commonly used is for the administrator to have both a BOOTP/DHCP server and an NFS server on the local network. The BOOTP/DHCP server is used to give the client system its networking information, while the actual files used during the installation are served by the NFS server. Often, these two servers run on the same physical machine, but they are not required to.

To perform a network-based kickstart installation, you must have a BOOTP/DHCP server on your network, and it must include configuration information for the machine on which you are attempting to install Red Hat Enterprise Linux. The BOOTP/DHCP server provides the client with its networking information as well as the location of the kickstart file.

If a kickstart file is specified by the BOOTP/DHCP server, the client system attempts an NFS mount of the file's path, and copies the specified file to the client, using it as the kickstart file. The exact settings required vary depending on the BOOTP/DHCP server you use.

Here is an example of a line from the dhcpd.conf  file for the DHCP server:

filename "/usr/new-machine/kickstart/"; next-server;
Note that you should replace the value after filename  with the name of the kickstart file (or the directory in which the kickstart file resides) and the value after next-server  with the NFS server name.

If the file name returned by the BOOTP/DHCP server ends with a slash ("/"), then it is interpreted as a path only. In this case, the client system mounts that path using NFS, and searches for a particular file. The file name the client searches for is:

The <ip-addr>  section of the file name should be replaced with the client's IP address in dotted decimal notation. For example, the file name for a computer with an IP address of would be

Note that if you do not specify a server name, then the client system attempts to use the server that answered the BOOTP/DHCP request as its NFS server. If you do not specify a path or file name, the client system tries to mount /kickstart  from the BOOTP/DHCP server and tries to find the kickstart file using the same <ip-addr>-kickstart  file name as described above.

Making the Installation Tree Available

The kickstart installation must access an installation tree. An installation tree is a copy of the binary Red Hat Enterprise Linux CD-ROMs with the same directory structure.

If you are performing a CD-based installation, insert the Red Hat Enterprise Linux CD-ROM #1 into the computer before starting the kickstart installation.

If you are performing a hard drive installation, make sure the ISO images of the binary Red Hat Enterprise Linux CD-ROMs are on a hard drive in the computer.

If you are performing a network-based (NFS, FTP, or HTTP) installation, you must make the installation tree available over the network. Refer to Section 2.5, "Preparing for a Network Installation" for details.

Starting a Kickstart Installation

To begin a kickstart installation, you must boot the system from boot media you have made or the Red Hat Enterprise Linux CD-ROM #1, and enter a special boot command at the boot prompt. The installation program looks for a kickstart file if the ks  command line argument is passed to the kernel.
CD-ROM #1 and Diskette
The linux ks=floppy command also works if the ks.cfg  file is located on a vfat or ext2 file system on a diskette and you boot from the Red Hat Enterprise Linux CD-ROM #1.

An alternate boot command is to boot off the Red Hat Enterprise Linux CD-ROM #1 and have the kickstart file on a vfat or ext2 file system on a diskette. To do so, enter the following command at the boot:  prompt:

linux ks=hd:fd0:/ks.cfg
With Driver Disk
If you need to use a driver disk with kickstart, specify the dd option as well. For example, to boot off a boot diskette and use a driver disk, enter the following command at the boot:  prompt:
linux ks=floppy dd
If the kickstart file is on a boot CD-ROM as described in Section 31.8.1, "Creating Kickstart Boot Media", insert the CD-ROM into the system, boot the system, and enter the following command at the boot:  prompt (where ks.cfg  is the name of the kickstart file):
linux ks=cdrom:/ks.cfg
Other options to start a kickstart installation are as follows:
Do not automatically use the CD-ROM as the install source if we detect a Red Hat Enterprise Linux CD in your CD-ROM drive.
Make kickstart non-interactive.
Start up pdb immediately.
Use a driver disk.
Sends a custom DHCP vendor class identifier. ISC's dhcpcd can inspect this value using "option vendor-class-identifier".
Comma separated list of nameservers to use for a network installation.
Same as 'dd'.
Turns on special features:
Gateway to use for a network installation.
Force graphical install. Required to have ftp/http use GUI.
Prompt user for ISA devices configuration.
IP to use for a network installation, use 'dhcp' for DHCP.
Keyboard layout to use. Valid values are those which can be used for the 'keyboard' kickstart command.
The installation program looks for the kickstart file on the NFS server <server>, as file <path>. The installation program uses DHCP to configure the Ethernet card. For example, if your NFS server is and the kickstart file is in the NFS share /mydir/ks.cfg, the correct boot command would be
The installation program looks for the kickstart file on the HTTP server <server>, as file <path>. The installation program uses DHCP to configure the Ethernet card. For example, if your HTTP server is and the kickstart file is in the HTTP directory /mydir/ks.cfg, the correct boot command would be ks=
The installation program looks for the file ks.cfg  on a vfat or ext2 file system on the diskette in /dev/fd0.
The installation program looks for the kickstart file on the diskette in /dev/fd0, as file <path>.
The installation program mounts the file system on <device> (which must be vfat or ext2), and look for the kickstart configuration file as <file> in that file system (for example, ks=hd:sda3:/mydir/ks.cfg).
The installation program tries to read the file <file> from the file system; no mounts are done. This is normally used if the kickstart file is already on the initrd  image.
The installation program looks for the kickstart file on CD-ROM, as file <path>.
If ks  is used alone, the installation program configures the Ethernet card to use DHCP. The kickstart file is read from the "bootServer" from the DHCP response as if it is an NFS server sharing the kickstart file. By default, the bootServer is the same as the DHCP server. The name of the kickstart file is one of the following:
The installation program uses this network device to connect to the network. For example, consider a system connected to an NFS server through the eth1 device. To perform a kickstart installation on this system using a kickstart file from the NFS server, you would use the command ks=nfs:<server>:/<path> ksdevice=eth1  at the boot:  prompt.
Adds HTTP headers to ks=http:// request that can be helpful for provisioning systems. Includes MAC address of all nics in CGI environment variables of the form: "X-RHN-Provisioning-MAC-0: eth0 01:23:45:67:89:ab".
Language to use for the installation. This should be a language which is valid to be used with the 'lang' kickstart command.
Set the minimum level required for messages to be logged. Values for <level> are debug, info, warning, error, and critical. The default value is info.
Force GUI installer to run at 640x480.
Activates loader code to give user option of testing integrity of install source (if an ISO-based method).
Do a CDROM based installation.
Use <path> for an FTP installation.
Use <path> on <dev> for a hard drive installation.
Use <path> for an HTTP installation.
Use <path> for an NFS installation.
Netmask to use for a network installation.
If GUI fails exit.
Do not load the VGA16 framebuffer required for doing text-mode installation in some languages.
Do not load support for firewire devices.
Disable IPv6 networking during installation.

This option is not available during PXE installations

During installations from a PXE server, IPv6 networking might become active before anaconda processes the Kickstart file. If so, this option will have no effect during installation.
Don't automatically mount any installed Linux partitions in rescue mode.
Do not auto-probe network devices.
Do not attempt to load support for parallel ports.
Don't pass keyboard/mouse info to stage 2 installer, good for testing keyboard and mouse config screens in stage2 installer during network installs.
Ignore PCMCIA controller in system.
Do not attempt to detect hw, prompts user instead.
Do not put a shell on tty2 during install.
Do not auto-probe storage devices (SCSI, IDE, RAID).
Do not load USB support (helps if install hangs early sometimes).
Do not load usbstorage module in loader. May help with device ordering on SCSI systems.
Run rescue environment.
Run installer in mode specified, '1024x768' for example.
Turns on serial console support.
Skips DDC probe of monitor, may help if it's hanging system.
Once installation is up and running, send log messages to the syslog process on <host>, and optionally, on port <port>. Requires the remote syslog process to accept connections (the -r option).
Force text mode install.
Prompt for floppy containing updates (bug fixes).
Image containing updates over FTP.
Image containing updates over HTTP.
Don't require an /etc/redhat-release that matches the expected syntax to upgrade.
Enable vnc-based installation. You will need to connect to the machine using a vnc client application.
Once installation is up and running, connect to the vnc client named <host>, and optionally use port <port>.

Requires 'vnc' option to be specified as well.

Enable a password for the vnc connection. This will prevent someone from inadvertently connecting to the vnc-based installation.

Requires 'vnc' option to be specified as well.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles


Top articles


Secure VNC Installation of Red Hat Enterprise Linux 6

Red Hat Enterprise Linux Anaconda customization guide

Unattended Installation of Red Hat Enterprise Linux 7 ... - Dell Unattended Installation of Red Hat Enterprise Linux 7 Operating System on Dell PowerEdge Servers Using iDRAC With Lifecycle Controller

Unattended Kickstart (Linux):

Creating a Kickstart File:

Kickstart Options:

Starting a Kickstart Installation:

5. Kickstart Configurator (Basic Configuration):

6. Kickstart Configurator (Installation Method):

7. Kickstart Configurator (Boot Loader Options):

8. Kickstart Configurator (Partition Information):

9. Kickstart Configurator (Network Configuration):

10. Kickstart Configurator (Authentication):

11. Kickstart Configurator (Firewall Configuration):



Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2018 by Dr. Nikolai Bezroukov. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: February 28, 2018