If 1 satisfies then what is the flow while installing the OS? Do the kernel still gets loaded to launch the installer script or OS installer is a minimal script that can be called by the bootloader ?
Almost always it's a full OS with a normal app running on it. For example, the graphical installers of both Debian and Fedora were GTK apps running on X11 (Xorg). In both cases there's regular Linux underneath, often with a console login at Alt+F2.
(Similarly, the Windows installer is a setup.exe that runs on WinPE, a Windows variant tailored for this kind of usage. If you hit Shift+F10 it'll launch cmd.exe.)
Having the installer use a full OS makes many things easier, as it can use the same concepts and facilities as the OS that it is installing. For example, the installer needs to be able to format and later read/write the filesystem that your Linux / partition will use – and since the installer is a regular Linux app, it can just use the regular mkfs and mount, that Linux already has.
So the flow for Linux installers specifically is very much like booting a real Linux system:
- Firmware loads and runs the bootloader from your installation CD or USB stick.
- Bootloader loads a Linux kernel and initramfs from the USB stick (and might be preconfigured to pass some installer-specific kernel parameters).
- The initramfs mounts the real root filesystem, which is slightly complex as most Linux "live" systems don't put all the OS files straight on the USB stick, but carry them packaged into a 'squashfs' archive:
- The initramfs mounts the FAT32 filesystem of the USB stick itself...
- Then it loop-mounts the SquashFS archive of the real Linux root filesystem from there...
- Then it mounts an 'overlayfs' or 'unionfs' virtual filesystem that allows the read-only SquashFS base to become writable, with all changes stored in RAM instead...
- ...and that overlayfs is what becomes the "/" for the actual Linux OS where the installer runs.
- The initramfs launches the regular 'init' process, which starts some typical services as well as some installer-specific ones.
- Finally, instead of starting a login screen, init directly starts the "installer" app (either a text-mode app on tty1, or an X11 app with Xorg).
As you can see, aside from the overlayfs-based root, it boots like Linux normally would. In general, Linux installers are just a special case of the "live" system, and most distributions publish the tools they use to build them, i.e. both the ISO builder and the actual UI are open-source. For example, you could analyze the archiso tool that Arch Linux uses to create bootable Linux ISOs.
(Arch is a relevant case here, because through the last few years, it did not have an installer as such – it would boot you straight into a Linux shell, where you'd partition the disk and install a set of initial packages, and that's your Linux system installed. So you get a very hands-on look at what Anaconda or d-i would be doing under the hood.)
RHEL docs says it used the anaconda installer but it is written in python and how they work even before the kernel or interpreter gets loaded.
They don't. No part of Anaconda needs to run before the kernel or interpreter gets loaded.
(Remember that as mentioned above the installer actually has its own Linux kernel and its own /usr/bin/python, it doesn't need to wait until the "real" kernel gets installed.)
If the kickstart file is used then exactly when the file gets parsed and the contents are executed during fresh OS installation ?
Generally, it's just read by the installer app. There's no specific "when", each installer does its own thing.
