Hello everyone,
I am looking for the procedure to follow in the case I would like to use an existing Linux system to install new ones. As far as I learned this is achieved using kickstart based on a /root/anaconda-ks.cfg file. I have to edit this file, and then what? I have my installation ISO, which is located on the external (Windows) server. Therefore the questions I’m looking the answers for: 1. Should I somehow amend the ISO file, and if yes, then how? 2. Is starting the installation procedure would somehow differ from a regular one (meaning I will have to boot my target computer from the ISO, like I did before and it will then simply install the system in the unattended mode, like I would like to do - or the procedure should change)?
Thank you in advance,
Mike Faynberg
Rocky docs also has info on how to do custom ISO with kickstart
You can speed ahead a little too, with scripting it into an ISO.
Youll need another linux machine to craft it, but this helped us a ton, by pretty much making a “Gold Master” we can install in quantity.
If you have iLO, iDRAC, RedfishAPI, or IPMI, you can do the whole thing with a single command after building, and even reboot. We have a ton of nodes, and you can rebuild on in 20 minutes from scratch with no human interaction, once started.
Hi Ballebone, it all sounds great but I m quite new in it - could you please elaborate?
My ISO is what I downloaded from the Rocky Linux website. I have no idea whether it is STIGGED or not - and do not understand why would it be mandatory. And like I mentioned this ISO is slocated on the external Windows server.
Then I have the anaconda file from an existing machine, which is running in the office. And, finally, this file has been adited (like added a couple more packages to install, and new IP addresses).
Then what the procedure would look like? Assume I have another running Linux machine… What is the sequence of actions to undertake? Sorry again, but I have never used the kickstart (and even Linux I started working with quite recently).
Best regards,
Mike
H jlehtone, and thank you for the information. I looked into the this documentation. My choice would be not to edit the ISO file itself, but to run the installation pointing out at the selected .cfg file. So according to the Chapter 14.1 I would have to edit the grub.cfg file - right? Therefore I will have to locate that one and point out to the “ks.cfg” file connection. Any more details?
Best regards,
Mike
Hi iwalker, thank you for thte information. I am hesitant however, to go that way (modifying the Rocky Linux ISO) because it adds one more step before installing each and every clone (the ks.cfg files should be different in at least IP addresses… therefore I will have to re-create the ISO before each installation. Otherwise, if the kx.cfg remains external to the ISO, this step would not be needed. Do you believe this logic makes sense?
Bes regards,
Mike
Fair enough, although in your original post you did mention:
hence I gave the information that matched point 1. You’ll however want to be most likely serving the kickstart files over TFTP instead to download them depending on what machine you wish to install. That said if manual IP and edits each time, perhaps just install a DHCP server and assign addresses automatically from that? At least you won’t need to edit the kickstart file each time.
iwalker, thank you.
Yes, I had mentioned that option because was not sure whether it would be the only viable way to do it under the circumstances. Now I am OK with manually editing the kickstart files (it is only the IP address to change) but yes, DHCP would be OK and will definitely simplify the process. I am still confused on the procedure however… I am installing systems on HP Proliant DL380 servers having the Rocky ISO on a local network Windows server, To do that I declare this ISO as a virtual DVD and let the target server to boot from it. Then the installation starts. Where and how the kickstart file gets involved? Let’s assume it is located at the same place where the ISO resides. Then what? I am sorry for the stupid questions but this is the first time ever I am touching this subject. Oh, and regarding the DHCP, could you please point out at an example of a kickstart file that defines the network configuration with DHCP?
Thank you once again,
Mike
The RHEL doc mentioned two “automatic” methods:
- One has essentially two USB sticks. One has the installer. Other has (volume) label
OEMDRVand fileks.cfg. When the installer boots, it will notice the other USB, see its label, and look for that file, then load and use it. Plug in both sticks and then boot the installer. Replace the file on stick for other machine. - The other uses “PXEboot”. On poweron the BIOS requests IP address from DHCP server with network card. The DHCP server is set to offer “next server” – address of TFTP server – as part of config. The BIOS then loads bootloader (GRUB or syslinux) from the TFTP server and bootloader loads kernel and initramfs from the TFTP server. One of the command-line options that bootloader gives to the kernel is the
inst.ks, whose parameter points to kickstart file – usually on some network file share (e.g HTTPS/FTP/NFS). Likewise, the kickstart file defines “repos” to be on network share(s). The TFTP server can offer each machine different bootloader menu and hence point to different kickstart file.
When one boots the installed stick, there is a chance to edit the bootloader entry to add/change inst.ks. This is less “automatic”. (The RHEL doc had chapter 13 about that.)
You have at least one of those. Did you let that install activate the network, and with default options? If yes, there is example on how to configure a network connection/interface to use DHCP. (That is the default way.)
You can also leave the kickstart file incomplete. All the choices that are not set there, or which the installer cannot accept, it will interactive ask for resolution. You then get those choices from the /root/anaconda-ks.cfg of the new system.
That sounds like “remote management”. Is it called “iLO2” on HP? That is probably not PXEboot.
You “plug in” the installer DVD/USB stick virtually to the machine.
You can probably “plug in” second “virtual USB” (with label OEMDRV), or plug physical USB to machine and then boot the installer. My guess is that that should act like the first “automatic” method above.
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/automatically_installing_rhel/kickstart-commands-and-options-reference_rhel-installer#network_kickstart-commands-for-network-configuration describes network options (for el9).
On machine that I have installed interactively, the choices were:
network --bootproto=dhcp --device=enp0s31f6 --noipv6 --activate
The noipv6 is what I did explicitly, because local LAN still lacks IPv6.
The activate … there might have been a checkbox for it.
The bootproto=dhcp should be the default.
The device name the installer did pick up from the system. On identical servers it should be the same.
Therefore,
network --bootproto=dhcp --device=enp0s31f6 --activate
should do the trick, if the name of interface is ‘enp0s31f6’.
Since you already set IP address, you must have ‘network’ statement(s) and
would merely update the bootproto and remove “manual config”.
Hi jlehtone, thanks for the info. Yes, I am using the iLO5 access to my servers. It allows me to define 1(!) CD/DVD (my Rocky installer). It also has “Virtual folder” and “Floppy” options in addition to the “CD/DVD”, but at this time I do not know if using one of those would serve as a proper automatically detectable location for the ks.cfg file… I cannot believe though the kickstart option would be unavailable on the HP servers, and still hope there is a way to kickstart the installation. If you know anything about such configurations, please let me know - I will greatly appreciate it!
Best regards,
Mike
I’ve seen iLO once, on HP/Compaq server, almost two decades ago. Cannot say more about it.
If it can set the “volume label” for those “Virtual folder” or “Floppy” options, then perhaps they could work.
If you could plug physical USB (with label and file) on the machines, then that should work.
Going “manual”, when the install image boots, it should first show GRUB menu with three entries:
- Start install
- Verify image and start install (default)
- Troubleshoot
With already verified image one would always switch to #1 as that is faster.
One has also option to edit entries before continuing. That is where one could
append the inst.ks=something onto the options line.
What is the something?
It could be URL to kickstart file, if the file is on HTTP/FTP server.
It could also point to file on those “Virtual folder” or “Floppy”. The question is how the GRUB sees those “drives”, i.e. what name and syntax is required. I have not done that either.
You can surely choose PXEboot (aka network boot) via the iLO5. That requires DHCP and TFTP servers.
What I do is (if PXEboot is not an option) plain “interactive” install. Minimal install. Even when I do have kickstart, it is mainly to drop in ssh key for root, and I still choose some bits interactively and do minimal install – I have very heterogenous hardware.
How do I select/set necessary packages and uniform config?
With configuration management system. Rocky has Ansible (package ansible-core).
I have created Ansible playbooks and inventory that define what machines should have.
I run those plays after the install.
Red Hat describes use of system roles (package rhel-system-roles) for configuring some parts of RHEL (works for Rocky too) with Ansible.
Gentlemen, I am back to the problem after spending long time on another urgent projects. As of today my (next) question is like this: I have read the RHEL Installation guide, p 31.4 that describes the kickstart options. Some of those options are required, some - optional. However, when I looked into my current anaconda-ks.cfg file, taken from a manually installed system, it lacks many of those options, declared required. Does it mean I was wrong assuming that I can use the existing file directly for the kickstart (just replacing the system name and, if applicable, static IP address)?
Thank you!
Two logical possibilities:
- The installer does not write (some) options, for which it did use default choice. On reuse it will use the same default choices
- The installer did not write all choices and has to interactively ask them on reuse
A “trivial” thing is to use that kickstart file for install and see what happens.
That is what I’ve done: repeat {tweak config, do install, check result} until satisfactory.
jlehtone, thank you!
I managed to use your advice creating the OEMDRV flash stick with ks.cfg on it. I edited it to what I believe would be a good start, and the installer picked the file up. This is THE progress!
However I am facing a nuisance: the disk I am trying to install the OS is being reused, i.e. was already formatted, partitioned, and contains some old installation. Theoretically, having the folloowing commands in the ks.cfg:
ignoredisk --only-use=sda
clearpart --all --initlabel
zerombr
autopart
should have ignored that - but it does not, and as soon as I kick start the install, the installer complains there is not enough room to start. Yes, it allows to reclaim the space by deleting all or some existing partitions, but it adds a manual step to the installation, which I would like to avoid by any means.
What am I doing wrong?
Best regards,
Mike
Sorry, my bad! I missed the fact that in the post-installation cfg file I used as a template the command looked like
clearpart --none
As soon as I fixed it, the installation started 
In any case your help was essential!
Best regards,
Mike
If I may ask another (however related) question: in the last section of a ks.cfg file, namely %post section, I can add a list of system configuration commands, and in some cases I will need using configuration file(s) pre-created on another system as templates. Therefore, the question: given I have the ks.cfg on a USB flash drive and the Linux ISO on virtual CDROM, where would you recommend placing those files to be copied to the newly installed system, and how to refer to them from the ks.cfg?
Thank you!
Mike