Skip to main content

Starting a Kickstart Installation


Firstboot does not run after a system is installed from a Kickstart file unless a desktop and the X Window System were included in the installation and graphical login was enabled. Either specify a user with the user option in the Kickstart file before installing additional systems from it (refer toSection 32.4, “Kickstart Options” for details) or log into the installed system with a virtual console as root and add users with the adduser command.
To begin a kickstart installation, you must boot the system from boot media you have made or the Red Hat Enterprise Linux DVD, 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.

DVD and local storage
The linux ks= command also works if the ks.cfg file is located on a vfat or ext2 file system on local storage and you boot from the Red HatEnterprise Linux DVD.

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=hd:partition:/path/ks.cfg dd
Boot CD-ROM
If the kickstart file is on a boot CD-ROM as described in Section 32.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:

askmethod
Do not automatically use the DVD as the install source if we detect a Red Hat Enterprise Linux DVD in your DVD drive.
autostep
Make kickstart non-interactive.
debug
Start up pdb immediately.
dd
Use a driver disk.
dhcpclass=<class>
Sends a custom DHCP vendor class identifier. ISC's dhcpcd can inspect this value using "option vendor-class-identifier".
dns=<dns>
Comma separated list of nameservers to use for a network installation.
driverdisk
Same as 'dd'.
expert
Turns on special features:
  • allows partitioning of removable media
  • prompts for a driver disk
gateway=<gw>
Gateway to use for a network installation.
graphical
Force graphical install. Required to have ftp/http use GUI.
isa
Prompt user for ISA devices configuration.
ip=<ip>
IP to use for a network installation, use 'dhcp' for DHCP.
keymap=<keymap>
Keyboard layout to use. Valid values are those which can be used for the 'keyboard' kickstart command.
ks=nfs:<server>:/<path>
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 server.example.com and the kickstart file is in the NFS share /mydir/ks.cfg, the correct boot command would be ks=nfs:server.example.com:/mydir/ks.cfg.
ks=http://<server>/<path>
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 server.example.com and the kickstart file is in the HTTP directory /mydir/ks.cfg, the correct boot command would be ks=http://server.example.com/mydir/ks.cfg.
ks=hd:<device>:/<file>
The installation program mounts the file system on <device> (which must be vfat or ext2), and looks for the kickstart configuration file as <file>in that file system (for example, ks=hd:sda3:/mydir/ks.cfg).
ks=bd:<biosdev>:/<path>
The installation program mounts the file system on the specified partition on the specified BIOS device <biosdev>, and looks for the kickstart configuration file specified in <path> (for example, ks=bd:80p3:/mydir/ks.cfg). Note this does not work for BIOS RAID sets.
ks=file:/<file>
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.
ks=cdrom:/<path>
The installation program looks for the kickstart file on CD-ROM, as file <path>.
ks
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:
  • If DHCP is specified and the boot file begins with a /, the boot file provided by DHCP is looked for on the NFS server.
  • If DHCP is specified and the boot file begins with something other than a /, the boot file provided by DHCP is looked for in the /kickstartdirectory on the NFS server.
  • If DHCP did not specify a boot file, then the installation program tries to read the file /kickstart/1.2.3.4-kickstart, where 1.2.3.4 is the numeric IP address of the machine being installed.
ksdevice=<device>
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 commandks=nfs:<server>:/<path> ksdevice=eth1 at the boot: prompt.
kssendmac
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".
lang=<lang>
Language to use for the installation. This should be a language which is valid to be used with the 'lang' kickstart command.
loglevel=<level>
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.
mediacheck
Activates loader code to give user option of testing integrity of install source (if an ISO-based method).
netmask=<nm>
Netmask to use for a network installation.
nofallback
If GUI fails exit.
nofb
Do not load the VGA16 framebuffer required for doing text-mode installation in some languages.
nofirewire
Do not load support for firewire devices.
noipv6
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.
nomount
Don't automatically mount any installed Linux partitions in rescue mode.
nonet
Do not auto-probe network devices.
noparport
Do not attempt to load support for parallel ports.
nopass
Don't pass keyboard/mouse info to stage 2 installer, good for testing keyboard and mouse config screens in stage2 installer during network installs.
nopcmcia
Ignore PCMCIA controller in system.
noprobe
Do not attempt to detect hw, prompts user instead.
noshell
Do not put a shell on tty2 during install.
nousb
Do not load USB support (helps if install hangs early sometimes).
nousbstorage
Do not load usbstorage module in loader. May help with device ordering on SCSI systems.
repo=cdrom
Do a DVD based installation.
repo=ftp://<path>
Use <path> for an FTP installation.
repo=hd:<dev>:<path>
Use <path> on <dev> for a hard drive installation.
repo=http://<path>
Use <path> for an HTTP installation.
repo=nfs:<path>
Use <path> for an NFS installation.
rescue
Run rescue environment.
resolution=<mode>
Run installer in mode specified, '1024x768' for example.
serial
Turns on serial console support.
skipddc
Skips DDC probe of monitor, may help if it's hanging system.
syslog=<host>[:<port>]
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).
text
Force text mode install.

Important

If you select text mode for a kickstart installation, make sure that you specify choices for the partitioning, bootloader, and package selection options. These steps are automated in text mode, and anaconda cannot prompt you for missing information. If you do not provide choices for these options, anaconda will stop the installation process.
updates
Prompt for storage device containing updates (bug fixes).
updates=ftp://<path>
Image containing updates over FTP.
updates=http://<path>
Image containing updates over HTTP.
upgradeany
Don't require an /etc/redhat-release that matches the expected syntax to upgrade.
vnc
Enable vnc-based installation. You will need to connect to the machine using a vnc client application.
vncconnect=<host>[:<port>]
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.
vncpassword=<password>
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.

Popular posts from this blog

Fixing Tanzu Kubernetes Pod to External Services Connectivity Issues with NSX-T

Fixing Tanzu Kubernetes Pod to External Services Connectivity Issues with NSX-T Last month I got a call from a customer who was pulling their hair out over a networking issue. They had just deployed VMware Tanzu Kubernetes Grid on their vSphere with Tanzu environment, everything looked good in the dashboards, all pods were running, but their applications inside the pods could not reach external databases running on traditional VMs in the same datacenter. The frustrating part was that some pods could reach external services perfectly fine, while others would just timeout. There was no clear pattern. Let me tell you how we figured this out and fixed it. The Initial Problem Here is what the customer setup looked like: vSphere 8.0 with Tanzu enabled NSX-T 4.1.2 for networking Three Tanzu Kubernetes clusters running different microservices applications External PostgreSQL database running on traditional VMs (non-Kubernetes) External API services running on another se...

Troubleshooting vSAN Storage Policy Migration Failures in VMware Cloud Foundation 9.0

Recently I had a customer who migrated their VMware infrastructure from vSphere 7.0 to VMware Cloud Foundation 9.0. After the migration, they wanted to update their vSAN storage policies to take advantage of the new vSAN ESA (Express Storage Architecture) features. However, when they tried to change the storage policy for their production VMs, the operation kept failing with a cryptic error message. The error they were getting was: "Cannot complete operation due to insufficient resources to satisfy current storage policy." This was strange because they had plenty of disk space available. The vSAN cluster was only at 45% capacity, and all the hosts were healthy. Let me walk through how we troubleshooted and fixed this issue. Understanding the Problem First, let's understand what was happening in their environment: They had a 6-node vSAN cluster running VCF 9.0 vSAN was configured with the new ESA architecture They were trying to migrate VMs fro...

Unlocking VMware Cloud Foundation 9.0: A Strategic Blueprint for Enterprise Transformation

The evolution of VMware under Broadcom represents not disruption, but clarification—a focused vision toward unified private cloud excellence. As organizations navigate this transformation, the opportunity has never been greater to build truly modern, efficient, and powerful infrastructure with VMware Cloud Foundation. After architecting VMware solutions across diverse enterprise environments, I've observed a pattern: organizations that embrace VMware Cloud Foundation (VCF) strategically—rather than viewing the transition as a burden—emerge with significantly more capable, cost-effective, and future-ready infrastructure. This post shares a practical framework for successfully modernizing your VMware environment, maximizing your investment, and positioning your organization for the AI-driven, cloud-native future. Understanding the VMware Cloud Foundation Vision Let's start with clarity about what Broadcom and VMware are building: VMware Cloud Foundati...