Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Creating a boot ISO that is using a remote kickstart file to install Red Hat

Version 2.0 (revised for RHEL7) Dec 4, 2020

by Dr. Nikolai Bezroukov

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

This is a part of unpublished lectures of Professor Nikolai Bezroukov for the course "Linux administration."

Introduction

As on December 2020 RHEL6 no longer supported, so we need to adapt to RHEL 7.  It you plan to use kickstart, please keep in mind that for some hardware (like HP blades ) RHEL 7.5 is a better option for  install then RHEL 7.7 - RHEL 7.9. You probably will experience less troubles with it and less cases of "Pane frozen." RHEL 7.3 is also an option. You can upgrade to the most recent version after the installation.

With UEFI boot, Red Hat 7, and HP ILO 4 things became way too complex.  The traditional BIOS can only boot from drives of 2.1 TB or less. If you only have drives larger than that your only option is UEFI.  But it is unclear why you need to boot from such huge drives, so for "normal servers" that have SSD boot disk(s) traditional boot is still a preferable option. I would say stick to traditional BIOS, unless you want additional problems in this already excessively complex environment.  SSD over 2TB are still expensive so this situatin my last for several years.  I guess till the end of life (EOL) of RHEL7 (2024).

There is no free lunch. While a more capable booting system, UEFI introduces additional complexity including, but not limited to,  a special 200MB UEFI partition which should be formatted as FAT. That's throws a monkey wrench into some operations related to kickstart, specifically to the modification of ISO disk to include reference to remote kickstart file in the boot menu. This is not fatal, but still if can avoid those troubles, you should.  Also in case of UEFI boot manager installed in the boot partition, but most server hardware is able to deal with this non-standard situation and boot correctly even if boot loader is located incorrectly.

RHEL 7 is another story of adding complexity to already very complex system. For booting, most of this complexity is related to use of systemd instead of initd and related changes of how you work with networking. "What if we just don't do any of that bullshit?" is indeed a great question to ask in this case. May be you need to simplify a system not to make it more complex.

Combination of several complex, poorly understood (due to excessive complexity and the fact that installation represents only a tiny chunk of sysadmin workload)  subsystems lead to the  situation when everything became kind of brittle as in "one step left or one step right and guards shout without warning". Kind of electronic gulag for system administrators ;-). In other words, when you are using Kickstart for servers with UEFI boot,  you are walking of eggshells.  That actually means that for servers that still have disks less then 2TB good old MBR might still be a better option ;-).  What is interesting that with identical blades and identical kickstart files RHEL 6.9 Anaconda it gave me several different error messages during the installation.  Also it does not like hard drive that was not initialized and asks for confirmation. That can be suppressed via option --initlabel in clearpart statement of you ks.cfg. .

Kickstart used to work pretty well probably up to the last release of RHEL 6 (6.10.) In RHEL 7 this software was rewritten to accommodate systemd and it shows.  Expect a lot of pain and frustration. See Installation troubles with RHEL 7 Anaconda : "frozen pane", broken Plymouth subsystem and friends

The key idea

The key idea for using kickstart for unattended installation of multiple severs is the creation of a  modified boot image of RHEL which included modified isolinux.cfg. Which in turn specify the location of the kickstart file, which not necessary should be imbedded in ISO.

You can specify the location of kickstart file on the network with  all the necessary necessary network information. This is more convinet the puttin it within the ISO, as you can modify kickstart for different blades or servers (at least static IP and hostname). As installing OS on multiple servers is what professional sysadmn do, it should be simple, reliable,  and well documented. But it is neither. If in RHEL 6 is mildly difficult and far form walk in the park, but in RHEL 7 this is a real horror show

What I propose in this page is to use network based kickstart file. Which you can modify for each installed server. Which is more convenient than putting kickstart file (ks.cfg) directly within the root of ISO. In the latter case the network parameters should be for the last server, and after installation you need manually change hostname and IP. You can do it  via post-install scripts, but why bother to struggle with this part in addition to previous pain, if ssh is available after the setup.

What I propose in this page is to configure custom made minimal boot ISO to use network based kickstart file. With the network based kickstart file you can modify it for each installed server. Which is more convenient than putting ks directly within ISO. In the latter case the network parameters should be for the last server, and after installation you need manually change hostname and IP.

So you can combine both methods and this is a recommended options in RHEL 7 as Anaconda is very brittle and capricious, and your network kickstart might not work.

BTW If I just did it manually I probably could save at least half of this time, doing several installations in parallel  ;-).   Let's say one hour per blade, which gives 12 hours plust overhead. Let's assume 16 hours, or two days.  So in my case this is a loss not a gain.  Of course HP hardware presents its own can of worms, but I digress.

In any case the best way to access kickstart file is to put it on NFS filesystem, or HTTP server.

Debugging your kickstart file

As the first approximation always use your prototype kickstart file obtained from the server. Kickstart file generated by anaconda for your first two ot three servers (the one that you installed manually) can be compared. Errors and omissions can be fixes by comparing  those versions and "unified version" created. In RHEL 7 partitions are not commented out so the file is ready to go. 

Highlights of the process of adding kickstart file to the ISO

Preliminary steps

  1. Install the required packages to create ISO9660 images, as follows:
    yum install -y genisoimage
  2. Mount the boot image 
    mount -o loop /path/to/rhel-server-boot-image.iso /mnt
  3. Copy the required files  preserving attributes. For example 
    cp -avf /mnt /tmp
mv /tmp/mnt/ tmp/rhel

    You can also do it using Midnight commander, which is my prefered method.

STEP 1: First you need to modify  the first section of boot menu in the isolinux.cfg file, Search for the first "label"  You will see something like 

label ^Kickstart Installation of RHEL7.7

The content above this statement  is not critical to the task and does not need any modification.

Modify append line in the first section of boot menu in the in /tmp/rhel/isolinux/isolinux.cfg file.

Modify append statement  file.

You need to append proper kickstart parameters. As a minimum

There are two cases here:

STEP 2: You need to verify that the KS file and ISO it references on your NFS or HTTP sever has right permissiond and are assessable.

Possible further minimization of boot image

If you work via VPN and do not have Advanced license on HP server (you can get trial license for 30 days from HP for free; that's usually enough for initial installation of OS)  further minimization of image can be important for you.  But do not go to far .  Two measures are easy and relatively painless.

If Packages folder is present you can remove  /Packages folder.  This is the biggest folder and that alone will shrink the boot image in half. It will speed transfer of this image from the server to PC is you do image manipulations remotely But it does not affect speed of the boot as ISO image is accessed as a filesystem and only individual files are sent over the link. Non used files are never send.

While this kind or redundant action, you can change boot menu to just two items: network base kickstart installation and "kickstart-within-ISO" installation, deleting the rest.  This is in most part redundant as you will use only one option, in  any case, but there is such possibility if you like to experiment :-) The content above the first  label linux statement is not critical to the task in hand.

The resulting "tail" of  "standard"  isolinux.cfg file might look as following" 

label linux
  menu label ^Install Red Hat Enterprise Linux 6.8
  kernel vmlinuz
  append initrd=initrd.img ks=10.10.10.19/kickstart.ks ksdevice=eth0 ip=dhcp
label local
  menu label Boot from ^local drive
  localboot 0xffff

menu end

Creation of modified ISO file

Now we need to create the ISO. There are three typical situations here

  1. You use traditional BIOS and want to install RHEL 7
  2. You use traditional BIOS and want to install RHEL 6 (in many case were you can it makes sense to continue to use RHEL 6)
  3. You have UEFI BIOS and want to install RHEL7

You use traditional BIOS want to install  RHEL7

  1. Confirm the LABEL of the DVD iso. The following command give you the LABEL information. For example:
    # blkid /tmp/rhel-server-7.7-x86_64-dvd.iso
  2. Now, save create the ISO as follows.

    WARNINGS:

    Here is an example that you can modified to suit your envvirtonment: 

    # cd /tmp/rhel7/
# mkisofs -o /tmp/rhel77ks.iso -b isolinux/isolinux.bin -J -R -l -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e images/efiboot.img -no-emul-boot -graft-points -V "RHEL-7.7 Server.x86_64"
NOTES:

You use traditional BIOS and RHEL6

 In this case you  just need to rebuild ISO using mkisofs

cd /location_of_file_tree_created_from_boot_cd # for example /svr/www/Boot
mkisofs -o ../myboot.iso -b isolinux/isolinux.bin -c isolinux/boot.cat --no-emul-boot --boot-load-size 4 --boot-info-table -J -R -V disks .

NOTE: . (dot) at the end of the command is obligatory. Otherwise you will get "missing pathspec" error

Also works 

mkisofs -o ../myboot.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -J -r .

The resulting ISO image should be bootable and should pick up the necessary ks.cfg file.

NOTE: mkisofs command in the form above is suitable only for legacy boot (MBR based) --  it does not create UEFI boot partition

 

You have UEFI BIOS.

In case you server uses UEFI boot it is easier to said then done, because UEFI partition is FAT-based.

mkisofs -o /tmp/efiboot.iso -b isolinux/isolinux.bin -c isolinux/boot.cat --no-emul-boot --boot-load-size 4 \
--boot-info-table -eltorito-alt-boot -e images/efiboot.img \
-graft_points EFI/BOOT=/mnt/EFI/BOOT images/efiboot.img=/mnt/images/efiboot.img \
-no-emul-boot -J -R -V disks .

(assuming you boot image is mounted on /mnt )

After that you need to run

isohybrid --uefi efiboot.iso

 Quoting from How can we create a customized Golden Image or RHEL ISO with kickstart file:

Rebuild the DVD iso image
    # cd /rhel
    # mkisofs -o /tmp/new.iso -b isolinux/isolinux.bin -c isolinux/boot.cat  --no-emul-boot --boot-load-size 4 --boot-info-table -J -R -V disks .

NOTE: In RHEL7, please make sure that you specify the volume id with -V option, and it's same as Volume_ID in step 6.

8. Boot the machine from this ISO

Kickstart has detailed documentation in the Installation Guide

Important Note:

EFI/BOOT={0}/EFI/BOOT images/efiboot.img={0}/images/efiboot.img

isohybrid --uefi boot.iso

but this truncated ISO image might still be bootable if your server has legacy boot option.

More information on the options used with the mkisofs command can be found in the man pages for mkisofs(1).

Google is also you friend but it does not provide useful references in this case.  Opening Red hat ticket is another option and if you are perssisten anough they might even help, not just bounce you to some semi-useless documents that they found by searching their database for relevant keywords.

Installation troubles with RHEL 7 Anaconda : "frozen pane", broken Plymouth subsystem and friends

One of the major attraction of previous versions of Red Hat was the performance of Red Hat installer, called Anaconda. The latter was an interesting software product in a sense that it gave enough control for sysadmin to select components, provided for unattended installation (via kickstart) and was pretty tolerant to various hardware. You was able to install it on a large variety systems.  Practically any Dell desktop, laptop of server was OK. All HP were OK too. In other words in RHEL6 Anaconda with Kickstart was a very useful tool for installation of the OS on multiple system. And/or unattended installation in general. It was rather simple to use. Even sysadmins of medium qualification could use it for installation from HTTP or NFS on many systems.

 Kickstart supported various combinations of the KS file and the ISO file. They can be retrieved from  HTTP (you need to mount them so that the tree is visible via Web server), NFS 3(just iso file, or the tree) and USB drives. The KS file can be imbedded in ISO file, or be standalone.  In the latter case, you need to point its location in the kernel boot command line as an option.

With version 7 that changed. In RHEL7 both Anaconda, and, especially, kickstart mode became very brittle. Sometimes it work. But in most cases it does not. Which means that this not even beta software, it is alpha. And meaningful diagnostic is absent, which is also typical for alpha software. Instead you get mainly systemd spam. When an error happened, at best you are greeted with "frozen pane" message, but in most case the system is just hang with no messages.  Sometimes console is available and you can explore what is happening, but often it is not. This is not how high quality production systems should be programmed. This is a perfect example of amateurish, incompetent programming.

What I have found that in  complex cases, were version 6 Anaconda used to work,  version 7 Anaconda simply hangs. Diagnostic is so bad I would not recommend to use it unless you have week or two to experiment and at least a dozen of server to install OS on.   I spend a week learning intricacies of anaconda implementation in RHEL 7 until I finally found combination of boot parameters in RHEL7 that used to work in RHEL6.  So, it took me over 40 hours and probably a hundred reboots to get the functionality that I was accustomed for in RHEL 6.  BTW each reboot on  HP blade takes from 5 to 20 min (depending on RAM size, can be even more if you have over 128GB of memory; those sadists put a message on the boot screen "Starting drivers. Please wait, this may take a few moments." Such a few moments ;-) , and that fact alone and kills all the rationality behind the systemd.  And it is unclear why systemd is necessary during installation at all.

In RHEL 7 they  changed almost all critical boot kernel boot parameters that affect kickstart and it does not look like this is an improvement. For example if you think that new ip parameter also works as ksdevice (because it allows to specify the interface, for example inst.ks-ens2:dhcp) you are up to big disappointment and a lot of lost hours.

There are also subtle changes in the kickstart DSL (domain specific language). For example, in RHEL 6 their following two directives were enough to wipe out partitions on install harddrive (in this case /dev/sda)

ignoredisk --only-use=sda
clearpart --all --initlabel

This combination of directives does not work in RHEL7. You need to specify the disk explicitly in clearpart directive

ignoredisk --only-use=sda
clearpart --all --initlabel --drives=sda

Which semantically is incorrect as we already specified that the only disk we will touch is sda in the directive "ignoredisk --only-use=sda"

As usual, Red Hat support  is not that helpful, although I was surprised that they offered me an interactive session to troubleshoot the issue (although the first response was a typical "database search" type of answers).

and there are a lot  on mine in this new Anaconda that the person who got used to RHEL 6 inveitable steps on. For example, if you are working over VPN and use inst.repo=nfs:<location_of_your_iso>  to redirect fetching of ISO to the local source now you need to specify both inst.ks-ens2:dhcp (or equivalent for static IP address) and ksdevice. Otherwise you need to this only in GUI. with multiple interfaces this directive does not work alone of the command line, unless the needed interface is the first one. Which is strange.

In any case, the reality is that if the new Anaconda does not like something, you either get a crash or "frozen pane" message.  And then you need to bump your head against the wall and try to guess what exactly it does not like...

The reality is that if the new Anaconda  it does not like something, you either get a crash or  "frozen pane" message.

For example, on HP blade ProLiant BL460c Gen9 blades (which are not that old, HP was still selling them in 2017 and probably 2018),   I observed the following: versions up to RHEL 7.5 launched anaconda in GUI mode OK.  But versions starting from RHEL7.7 and up to 7.9 simply freeze when Anaconda starts. And this is pretty popular, mainstream enterprise hardware. The message "Pane is dead"  is the result of some bug in switching from GUI console to text console, when X11 can't start (but, again, it was starting OK in older versions).  But the question is why

But X11 did started OK on previous versions of RHEL 7 installed on the same hardware, so the X11 driver was available.  BTW, what I have found is that if you specify VESA   driver ( inst.xdriver=vesa ) as a boot option, Anaconda switches to the text mode OK, but still refuse to work in GUI mode. It is unclear why. GUI mode is now the recommended mode 8.3. Installing in Text Mode Red Hat Enterprise Linux 7 - Red Hat Customer Portal

If your system has a graphical display, but graphical installation fails, try booting with the inst.xdriver=vesa option - see Chapter 23, Boot Options.

Google for "Anaconda  pane is dead" and you will see that this type of errors started with RHEL 7 beta (874906 – anaconda pane is dead when hitting some issue):

Xiaowei Li 2012-11-09 03:16:28 UTC

Description of problem:

anaconda hung and panel is dead when hitting some issue.

In the previous anaconda, we can use install OS manually and go to the shell to debug if hitting any issues on the anaconda GUI.

But in the current anaconda of RHEL7, we cannot go to the shell to check anything. This is very bad user experience.

Chris Lumens, 2012-11-09 15:10:36 UTC

You can still switch to a shell. anaconda now runs in tmux, which is a screen-like program and you can tell this by the green bar on the bottom. To switch to the shell, you just hit ctrl-b <N>, where N is the number of the window you want to switch to.

And this error in some form is still present in RHEL 8. See also:

It even got into documentation  Chapter 60. Kernel Red Hat Enterprise Linux 7 - Red Hat Customer Portal

 The problem is characterized by errors starting X11, followed by a Pane is dead message in the Anaconda screen. The workaround is to append inst.text to the kernel command line and install in text mode.

And "Pane is dead"  and hanging on install is not the only problem. On Dell M620 blades in my case anaconda actually work (even with kickstart), but the resulting OS on boot went  indefinite (created by systemd ;-) loop.  The last message was "Starting wait for Plymouth boot screen to Quit" I experienced this problem with RHEL 7.7, See also

How do deactivate plymouth boot screen- - Ask Ubuntu

Easiest quick fix is to edit the grub line as you boot. Hold down the shift key so you see the menu. Hit the e key to edit Edit the 'linux' line, remove the 'quiet' and 'splash'

To disable it in the long run

Edit /etc/default/grub

Change the line – GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash” to

GRUB_CMDLINE_LINUX_DEFAULT=""

And then update grub

sudo update-grub

Note of UEFI issues with USB sticks

Here is an exchange from Microsoft TechNet forum that explains the problem: Creating a bootable USB stick - differences between UEFI-BIOS and GPT-MBR

EckiS August 02, 2016
When it were true that a different USB stick was needed for different Bios, then the Windows Installation media could never boot on all Bios versions. But it can.

Maybe you formatted the USB stick with NTFS? On the page you linked:

If your server platform supports Unified Extensible Firmware Interface (UEFI), you should format the USB flash drive as FAT32 rather than as NTFS. To format the partition as FAT32, type format fs=fat32 quick, and then click ENTER.

....

XXX

Thanks, Ecki,

that's exactly my point of view.

In the forum a user claimed that that'd be true for DVDs but not for USB sticks. Now I want to make sure. And I want to make clear for every user out there that there is no peculiarity to UEFI except for a requirement of "\efi\boot\bootx64.efi" existing on the boot media.

... ...

XXX

From what I read (and from what I tested): UEFI can not boot from NTFS:

https://en.wikipedia.org/wiki/EFI_system_partition#Overview

https://github.com/pbatard/rufus/issues/589

https://blogs.technet.microsoft.com/askcore/2013/03/20/creating-bootable-usb-drive-for-uefi-computers/

XXX
Last week I received a Microsoft OEM Windows 10 Recovery USB stick from HP. That stick is formatted in NTFS (hell knows why, as it doesn't work with UEFI).

Trying to copy its contents to my USB stick (which I formatted FAT32) failed, because HP added a file larger than 4GB.

Now this is really getting difficult. I guess I'll need to use Rufus now in order to create a USB Stick layout having two partitions: The Active one using FAT, containing just the NTFS drivers and the UEFI boot loader, and a second partition using NTFS containing the contents from the HP/Microsoft OEM Windows 10 Recovery USB stick.

Gee ... Did no one at Microsoft/HP think of testing their USB stick when buring data to it?

RUFUS

Rufus - Create bootable USB drives the easy way

Create bootable USB drives the easy way 

Rufus is a utility that helps format and create bootable USB flash drives, such as USB keys/pendrives, memory sticks, etc.

It can be especially useful for cases where:

Despite its small size, Rufus provides everything you need!

Oh, and Rufus is fast. For instance it's about twice as fast as UNetbootin, Universal USB Installer or Windows 7 USB download tool, on the creation of a Windows 7 USB installation drive from an ISO. It is also marginally faster on the creation of Linux bootable USB from ISOs. (1)
A non exhaustive list of Rufus supported ISOs is also provided at the bottom of this page.

Notes on ISO Support:

All versions of Rufus since v1.1.0 allow the creation of a bootable USB from an ISO image (.iso).

Creating an ISO image from a physical disc or from a set of files is very easy to do however, through the use of a CD burning application, such as the freely available CDBurnerXP or ImgBurn.

Notes on UEFI & GPT support:

Since version 1.3.2, Rufus support UEFI as well as GPT for installation media, meaning that it will allow you to install Windows 7, Windows 8 or Linux in full EFI mode.
However, Windows Vista or later is required for full UEFI/GPT support. Because of OS limitations, Windows XP restricts the creation of UEFI bootable drives to M

Top Visited
 Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[May 16, 2021] Kickstart driven CentOS 7 install from USB

May 16, 2021 | gist.github.com

Kickstart driven CentOS 7 install from USB

None of what is written below is particularly original, however, I was unable to find a method documented on the internet at the time of writing that successfully created a kickstart driven CentOS 7 USB installer.

My interest was in doing this manually as I require this USB (image) to be created from a script. Therefore, I did not look into using ISO to USB applications - in addition, these typically do not allow custom kickstart files to be used.

References

Much of the process described below was found on the CentOS Wiki page on Installing from USB key, and from the Softpanorama page on the same subject. I thoroughly recommend reading all of the latter as it highlights the shortcomings/dangers associated with the steps below.

USB key preparation Partition USB

This can probably be done as a disk image too, though I haven't tried this yet. Below I will use /dev/sdX for the USB device.

sudo fdisk /dev/sdX
n (create partition, accept defaults for type, number, and first sector)
+250M (defined size as 250MB)
t
c (change type to W95 FAT32 (LBA) - other FAT types may work, but I have not tried)
a (make bootable)
n (create partition, accept defaults for type, number, first sector, and size)
w (write changes to device)

sudo mkfs -t vfat -n "BOOT" /dev/sdX1
sudo mkfs -L "DATA" /dev/sdX2

sudo dd conv=notrunc bs=440 count=1 if=/usr/share/syslinux/mbr.bin of=/dev/sdX

sudo syslinux /dev/sdX1
Copy files to USB 
mkdir BOOT && sudo mount /dev/sdX1 BOOT
mkdir DATA && sudo mount /dev/sdX2 DATA
mkdir DVD && sudo mount /path/to/centos/dvd.iso DVD

sudo cp DVD/isolinux/* BOOT

sudo mv BOOT/isolinux.cfg BOOT/syslinux.cfg

The final file structure looked something like this:

BOOT/
├── boot.cat
├── boot.msg
├── initrd.img
├── ks.cfg
├── ldlinux.sys
├── memtest
├── splash.png
├── syslinux.cfg
├── upgrade.img
├── vesamenu.c32
└── vmlinuz
DATA/
└── CentOS-7.0-1406-x86_64-Minimal.iso
Edit the syslinux.cfg

So that it points to the ISO and the kickstart

Here is the install CentOS 7 entry from the Minimal ISO isolinux.cfg (which we renamed syslinux.cfg ):

label linux                                                                     
  menu label ^Install CentOS 7                                                  
  kernel vmlinuz                                                                
  append initrd=initrd.img inst.stage2=hd:LABEL=CentOS\x207\x20x86_64 quiet

The append line is changed to read the following:

append initrd=initrd.img inst.stage2=hd:sdb2:/ ks=hd:sdb1:/ks.cfg

I suspect LABEL could be used here, rather than the enumerated device, which would make it safer, but I haven't tried this yet. Assuming the system you are installing on only has a single HD the USB key will be enumerated as sdb more information about this can be found in the Softpanorama article.

When you boot from the USB and select Install CentOS 7, it now installs the system as described by your kickstart.

[Feb 17, 2021] genisoimage fails missing pathspec

redhat.com

Add a "." to the end of the command to specify the output directory as your current working directory (cwd)

Raw 
# genisoimage -U -r -v -T -J -joliet-long -V "RHEL-7.4 Server.x86_64" -volset "RHEL-7.4 Server.x86_64" -A "RHEL-7.4 Server.x86_64" -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -eltorito-alt-boot -e images/efiboot.img -no-emul-boot -o ../RHEL7.iso .

How can we create a customized Golden Image or RHEL ISO with kickstart file

Rebuild the DVD iso image

Raw

    # cd /rhel
    # mkisofs -o /tmp/new.iso -b isolinux/isolinux.bin -c isolinux/boot.cat --no-emul-boot --boot-load-size 4 --boot-info-table -J -R -V disks .

NOTE: In RHEL7, please make sure that you specify the volume id with -V option, and it's same as Volume_ID in step 6.

8. Boot the machine from this ISO

Kickstart has detailed documentation in the Installation Guide

Important Note:

  • The image which will be created using the steps above won't be UEFI enabled. So to have an UEFI enabled image, use the following extra options.
Raw
-eltorito-alt-boot -e images/efiboot.img -no-emul-boot
  • And the graft point as follows.
Raw
EFI/BOOT={0}/EFI/BOOT images/efiboot.img={0}/images/efiboot.img
  • Where {0} is replaced by the location where the existing DVD is mounted/extracted.
  • One should also run isohybrid on it so that it can be booted by both BIOS and UEFI:
Raw
isohybrid --uefi boot.iso

To use a Kickstart file to install a system:

  1. Boot the system from a bootable medium or from a network installation server that supports PXE client installation. If you need to modify the boot command, press Esc to access the command line. Note, however, that the boot configuration might not allow you to modify the boot command.

    For PXE clients, it is usual to specify the Kickstart parameters in the boot loader configuration. For example, the following example configures a Kickstart installation for a PXE client that boots using pxelinux:

    prompt 0
default ol6u6
timeout 0

label ol6u6
kernel vmlinuz-OL6u6
append initrd=initrd-OL6u6.img ksdevice=eth0 kssendmac ks=http://10.0.0.11/ksfiles/ol6u6_cfg.ks

    The ksdevice=eth0 parameter specifies the interface to be used for network installation. If a system has multiple network interfaces, this prevents the installation from prompting you to choose an interface. Alternatively, you could specify ksdevice=bootif and add an ipappend 2 entry after the append entry:

    prompt 0
default ol6u6
timeout 0

label ol6u6
kernel vmlinuz-OL6u6
append initrd=initrd-OL6u6.img ksdevice=bootif kssendmac ks=http://10.0.0.11/ksfiles/ol6u6_cfg.ks
ipappend 2

    This configuration also prevents you from being prompted to choose a network interface but it does not control which interface is selected.

    The next example configures a Kickstart installation for a PXE client that boots using GRUB:

    default=0
hiddenmenu
splashimage=(nd)/splash.xpm.gz
timeout=0
    title Oracle Linux 6 Update 6 Installation
    root (nd)
    kernel /vmlinuz-OL6u6 ksdevice=eth0 kssendmac ks=http://10.0.0.11/ksfiles/ol6u6_cfg.ks
    initrd /initrd-OL6u6.img
    NOTE:
    1. If you have not customized the boot configuration to use Kickstart, you can use the ks option to specify the location of the Kickstart file.
    2. The following boot command specifies that the Kickstart file is on the boot CD:
    boot: linux ks=cdrom:/ks.cfg
    1. If the Kickstart file is located on an NFS server, you might use a boot command such as the following:
    boot: linux ksdevice=eth0 ip=dhcp ks=nfs:10.0.0.11:/ksfiles/ks.cfg

    where ksdevice=eth0 specifies the network interface and ip=dhcp specifies that DHCP should be used to configure this interface.

    For more information, see Section 2.2, "Installation Boot Options".

Hands-Off Fedora Installs with Kickstart

O'Reilly Media

Creating the Kickstart Config File, ks.cfg

ks.cfg makes unattended installs possible. It holds canned responses to the questions posed during an interactive install. The examples assume you've saved this file under the web server's document root as kickstart/ks.cfg.

There are several ways to create ks.cfg. (I did warn you that Kickstart was flexible.) If you're plotting a clone farm, build one machine to your specs and use /root/anaconda-ks.cfg on that host as a starting point for the others.

Barring that, use the redhat-config-kickstart GUI (from the redhat-config-kickstart package). This tool doesn't support LVM for disk layout, but is a valuable learning tool nonetheless. You can hand-edit the generated ks.cfg to use LVM (described below).

You can also create or edit ks.cfg using any text editor, provided you know the directives. Here's a walk through the directives in the sample ks.cfg.

You probably already have the redhat-config-language, hwdata, and tzdata RPMs installed already. They are not required, but include files that simplify hand-editing ks.cfg.

Installation Type

The first entries are the installation type and source.

install
url --url http://kickstart-server/FC1-install

The type may be install or upgrade. The url directive specifies an HTTP installation and indicates the URL of the install media. (The directory Fedora, from the install media, must be a subdirectory of the URI part of the URL.) Other installation sources include cdrom for swapping CDs or DVDs, nfs for mounting the install media from an NFS share, and the self-explanatory ftp.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

Kickstart Installations -- CentOS Docs Site

Installing CentOS 7 using a kickstart file - CentOS 7 Linux Server Cookbook - Second Edition

Red Hat documents (account required)

kickstart - How to create a custom ISO image in CentOS - Server Fault

Customize a Golden Image or RHEL ISO with kickstart file- Rhel4-5-6--7 - ShebangLinux

Chapter 28. Kickstart Installations

Unattended Installation of Red Hat Enterprise Linux 7 ...

Etc

Society

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

Quotes

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 quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

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

History:

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 DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting 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-Month :  How 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-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) 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 to buy a cup of coffee for authors of this site

Disclaimer:

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 Softpanorama society. 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, 17, 2021