Kickstart installation of EL Linux systems

Configuring Kickstart

Linux OS installation of RHEL Linux and EL clones (AlmaLinux, RockyLinux, and more), as well as Fedora, can be made using the automated Kickstart method. There is a general description from the Fedora page:

• Many system administrators would prefer to use an automated installation method to install Fedora or RHEL on their machines. To answer this need, Red Hat created the Kickstart installation method. Using Kickstart, a system administrator can create a single file containing the answers to all the questions that would normally be asked during a typical installation.

• A Kickstart_file can be kept on a server system and read by individual computers during the installation. This installation method can support the use of a single Kickstart_file to install Fedora or RHEL on multiple machines, making it ideal for network and system administrators.

Automated Kickstart installation

Automated installation with PXE and Anaconda is possible using either UEFI or legacy BIOS booting. You can either:

• Configure the node’s boot order with PXE network booting as the first boot device, or

• When powering up the client computer, PXE network booting can be selected using the console, typically by pressing the F12 or F10 Function_key as shown in the console.

When you have installed the above pxeconfig_toolkit and used pxeconfig to setup the client boot process, then it is sufficient to power cycle and/or start up the client computer.

The UEFI network boot process ensures that:

• Kickstart OS installation will be performed automatically.

• The installation process can be viewed in the node’s console (physically or in the BMC web browser window).

• The Kickstart method described above therefore provides a totally automatic and hands-free Linux OS installation of nodes, suitable for a large Linux cluster and other scenarios.

Creating a Kickstart_file

In the following sections we discuss relevant sections of the Kickstart_file.

In the grub.cfg file you can use the inst.ks parameter to specify the location (on the network, for example) of the Kickstart_file that you want to use. As an example, the following menu item may be added to the grub.cfg file to download a Kickstart_file named ks-almalinux-8.10-minimal-x86_64.cfg from the NFS (version 3) server at IP address 10.10.10.3:

menuentry 'AlmaLinux 8.10 minimal Kickstart' --class centos --class gnu-linux --class gnu --class os --unrestricted {
  linuxefi (tftp)/AlmaLinux-8.10-x86_64/vmlinuz ip=dhcp inst.ks=nfs:nfsvers=3:10.10.10.3:/u/kickstart/ks-almalinux-8.10-minimal-x86_64.cfg
  initrdefi (tftp)/AlmaLinux-8.10-x86_64/initrd.img
}

Setting up an NFS server is not discussed here, however. Additional example files can be found in https://github.com/OleHolmNielsen/ansible/tree/master/roles/pxeconfigd/files

A Legacy PXE BIOS boot file /tftpboot/pxelinux.cfg/default example using the same Kickstart_file is:

label AlmaLinux8.10 minimal-x86_64
      menu label Clean AlmaLinux-8.10-x86_64, minimal install
      kernel AlmaLinux-8.10-x86_64/vmlinuz
      append load_ramdisk=1 initrd=AlmaLinux-8.10-x86_64/initrd.img network inst.ks=nfs:nfsvers=3:<server-IP>:/u/kickstart/ks-almalinux-8.10-minimal-x86_64.cfg vga=792

Bootloader command

The Kickstart_file bootloader_command (required) specifies how the bootloader should be installed.

You should always use a password to protect your bootloader. An unprotected bootloader can allow a potential attacker to modify the system’s boot options and gain unauthorized access to the system:

• --password If using GRUB2 as the bootloader, this sets the bootloader password to the one specified. This should be used to restrict access to the GRUB2 shell, where arbitrary Linux_kernel options can be passed. If a password is specified, GRUB2 will also ask for a user name, and that user name is always root.

• --iscrypted Normally, when you specify a bootloader password using the --password= option, it will be stored in the Kickstart_file in plain text, but you may use this option to specify an encrypted password. To generate an encrypted password use the command:

  grub2-mkpasswd-pbkdf2
  

  Enter the password you want to use, and copy the command’s output (the hash starting with grub.pbkdf2) into the Kickstart_file. An example bootloader Kickstart entry with an encrypted password will look similar to the following:

  bootloader --iscrypted --password=grub.pbkdf2.sha512.10000.5520C6C9832F3AC3D149AC0B24BE69E2D4FB0DBEEDBD29CA1D30A044DE2645C4C7A291E585D4DC43F8A4D82479F8B95CA4BA4381F8550510B75E8E0BB2938990.C688B6F0EF935701FF9BD1A8EC7FE5BD2333799C98F28420C5CC8F1A2A233DE22C83705BB614EA17F3FDFDF4AC2161CEA3384E56EB38A2E39102F5334C47405E
  

Some systems require a special partition for installing the bootloader. The type and size of this partition depends on whether the disk you are installing the bootloader to uses the Master Boot Record (MBR) or a GUID Partition Table (GPT) schema. For more information, see the bootloader page.

Automatic boot disk device selection

The client computer may have multiple disk devices, and each device may have different bus interfaces to the system such as NVME or SATA.

When the Kickstart installation starts up, the file given by inst.ks must select, format and partition the system boot disk. However, you do not want to install the Linux OS on a large disk device which might be used only for data storage! Another problem is that NVME and SATA devices have different device names in the Linux_kernel, for example:

• SATA: /dev/sda

• NVME: /dev/nvme0n1

and the correct device name must be given to Kickstart.

A nice and flexible solution to this issue is given in the thread https://access.redhat.com/discussions/3144131. You configure a Kickstart_file %include line where you would traditionally partition the disk:

# The file /tmp/part-include is created below in the %pre section
%include /tmp/part-include
%packages
%end

Then you define a pre-install section with %pre, here adding a number of improvements:

# Start of the %pre section with logging into /root/ks-pre.log
%pre --log=/root/ks-pre.log
# pick the first drive that is not removable and is over MINSIZE
DIR="/sys/block"
# minimum and maximum size of hard drive needed specified in GIGABYTES
MINSIZE=100
MAXSIZE=1999
# The loop first checks NVME then SATA/SAS drives:
for d in $DIR/nvme* $DIR/sd*
do
  DEV=`basename "$d"`
  if [ -d $DIR/$DEV ]; then
    # Note: the removable file may have an incorrect value:
    if [[ "`cat $DIR/$DEV/removable`" = "0" ]]
    then
      # /sys/block/*/size is in 512 byte chunks
      GB=$((`cat $DIR/$DEV/size`/2**21))
      echo "Disk device $DEV has size $GB GB"
      if [ $GB -gt $MINSIZE -a $GB -lt $MAXSIZE -a -z "$ROOTDRIVE" ]
      then
        ROOTDRIVE=$DEV
        echo "Select ROOTDRIVE=$ROOTDRIVE"
      fi
    fi
  fi
done

if [ -z "$ROOTDRIVE" ]
then
      echo "ERROR: ROOTDRIVE is undefined"
else
      echo "ROOTDRIVE=$ROOTDRIVE"
      cat << EOF > /tmp/part-include
zerombr
clearpart --drives=$ROOTDRIVE --all --initlabel
ignoredisk --only-use=$ROOTDRIVE
reqpart --add-boot
part swap --size 32768 --asprimary
part pv.01 --fstype xfs --size=1 --grow --asprimary
volgroup VolGroup00 pv.01
logvol / --fstype xfs --name=lv_root --vgname=VolGroup00 --size=32768
EOF
fi
%end

WARNING: We have some old Intel Xeon Nehalem servers with SATA disks where /sys/block/sda/removable contains an incorrect value of 1!

Disk partitions

With UEFI systems it is required to configure a special /boot/efi partition in your Kickstart_file, see also:

• https://access.redhat.com/solutions/1369253

• https://fedoraproject.org/wiki/Anaconda/Kickstart#bootloader

It is most convenient to configure boot partitions using reqpart:

• Automatically create partitions required by your hardware platform. These include a /boot/efi for x86_64 and Aarch64 systems with UEFI firmware, biosboot for x86_64 systems with BIOS firmware and GPT, and PRePBoot for IBM Power Systems.

An example Kickstart_file section specifying disk partitions and using reqpart may be:

reqpart --add-boot
part swap --size 50000 --asprimary
part pv.01 --fstype xfs --size=1 --grow --asprimary
volgroup VolGroup00 pv.01
logvol / --fstype xfs --name=lv_root --vgname=VolGroup00 --size=32768

Capture the %pre logfile

The Kickstart_file %pre command can create a logfile:

# Start of the %pre section with logging into /root/ks-pre.log
%pre --log=/root/ks-pre.log

However, this file exists only in the memory file system during installation, and the logfile will be lost after the system has rebooted.

There are methods to get a copy of the %pre logfile:

• https://unix.stackexchange.com/questions/78388/logging-pre-during-kickstart-logfile-doesnt-exist-after-boot

Installation screen resolution

If you have an old server or PC where the VGA graphics adapter only supports screen resolutions up to 1024x768 or 1280x1024, then the Linux_kernel EL8 may select a higher, unsupported screen resolution which gives a flickering monitor with no image! See these pages:

• https://www.systutorials.com/configuration-of-linux-kernel-video-mode/

• https://cromwell-intl.com/open-source/grub-vga-modes.html

• https://pierre.baudu.in/other/grub.vga.modes.html

You can add a vga= directive to the Linux_kernel line in the GRUB file, something like the following:

linuxefi /vmlinuz-X.Y.Z vga=792

(X.Y.Z is your version) and you can use numbers other than 792 which would give a resolution of 1024×768 with 65,536 possible colors. This is a partial list of the GRUB VGA Modes:

Colour depth  640x480 1024x768
8 (256)       769     773
15 (32K)      784     790
16 (65K)      785     791
24 (16M)      786     792

Linux kernel with 16-bit boot protocol

From https://www.systutorials.com/configuration-of-linux-kernel-video-mode/ we see:

• Switching VESA modes of Linux_kernel at boot time can be done by using the “vga=…“ Linux_kernel parameter. This parameter accept the decimal value of Linux video mode numbers instead of VESA video mode numbers.

The video mode number of the Linux_kernel is the VESA mode number plus 0×200:

Linux_kernel_mode_number = VESA_mode_number + 0x200

So the table for the Kernel mode numbers are:

    | 640x480  800x600  1024x768 1280x1024
----+-------------------------------------
256 |  0x301    0x303    0x305    0x307
32k |  0x310    0x313    0x316    0x319
64k |  0x311    0x314    0x317    0x31A
16M |  0x312    0x315    0x318    0x31B

The decimal value of the Linux_kernel video mode number can be passed to the kernel in the form “vga=YYY“, where YYY is the decimal value.

The parameter vga=ask is often mentioned, but is not supported by GRUB2.

Last, calculate the decimal value of the Linux video mode number. This simple python command can be used to convert a hex-number 0xYYY:

python -c "print 0xYYY"