I am learning how Linux OS installation works, but searching the Internet for this doesn't provide any information for my questions.

Note: This question has been marked as off-topic on Server Fault so I am asking here.

Redhat documentation has pretty neat information but they are in pieces. I can't glue those pieces to get a complete answer.
From those pieces I am able to understand how the bootloader works, how they start up the ramdisk and kernel then systemd or initd.
Can't find any references regarding how the initial OS installation works.
This community has great professionals who are experts in this topic, so I can get solutions for my questions.

There are multiple questions here, please free to answer each question and add reference to it if possible

  1. During the boot process the MBR gets read and the bootloader initialized; during normal setup the kernel gets loaded by the bootloader then after some magic the login screen appears.
  2. If 1 holds then what is the flow while installing the OS? Does the kernel still get loaded to launch the installer script or is the OS installer a minimal script that can be called by the bootloader?
  3. If the kickstart file is used then exactly when does the file get parsed and the contents executed during a fresh OS installation?
  4. What are the files or scripts required for OS installation to work (for normal booting we need initrd, vmlinuz) then what for installers - I think we have the installation tree (ISO extracted and served by HTTPserver)?
  5. RHEL docs says it uses the anaconda installer but it is written in python and how does that work even before the kernel or interpreter gets loaded? I checked whether they compiled to a CPU specific format so it can be run directly on the CPU but can't find anything regarding it.
  • My suggestion might be to 'try' doing a gentoo install - essentially that's what the installer does, only manually.
    – Journeyman Geek
    Dec 1 '21 at 2:09
  • @JourneymanGeek will try for sure.But the time and resource not permits at this time. Dec 1 '21 at 2:36
  • There are several possible ways to install an OS, but one method is to simply boot the OS using an alternate medium, i.e. not the target storage device, and then start an install program. Do you understand how an x86 OS boots? Some of what you write seems to indicate confusion/misunderstanding.
    – sawdust
    Dec 1 '21 at 5:42
  • What makes you think Anaconda runs "before the kernel or interpreter gets loaded"?
    – user1686
    Dec 1 '21 at 5:47
  • @sawdust please note out what are misunderstand,I am new to this topic Dec 1 '21 at 6:13

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:

  1. Firmware loads and runs the bootloader from your installation CD or USB stick.
  2. Bootloader loads a Linux kernel and initramfs from the USB stick (and might be preconfigured to pass some installer-specific kernel parameters).
  3. 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.
  4. The initramfs launches the regular 'init' process, which starts some typical services as well as some installer-specific ones.
  5. 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.

  • It means that installer boots and has its own os,then installer process makes partition on harddisk,copies the bootloader,(ramdisk,vmlinuz for next boot from harddisk),repos etc to the harddisk.Once we reboot then os is booted from the harddisk right ? Dec 1 '21 at 6:28
  • 4
    It could be either. Some distros build ISOs out of the exact same packages that they use for "real" systems, including the complete kernel with all drivers. But other distros do use a special build, especially if they're trying to achieve the smallest ISO possible (e.g. "netboot" ISOs), in which case removing unnecessary drivers could save as much as 150 MB.
    – user1686
    Dec 1 '21 at 8:31
  • 1
    Yes, the GRUB configuration in bootable ISOs is custom-generated by the ISO build tools, not by the regular grub-mkconfig. (But note that more commonly ISOs use Syslinux as the bootloader, although GRUB is sometimes used too.)
    – user1686
    Dec 1 '21 at 8:39
  • 1
    just want to add that the root partition of the target install is not mounted at / during installation, it will be mounted elsewhere however some scripts may run in a chroot so those scripts see / as the target's root, not the live root - I think the grub scripts do this for example? I've certainly had to use a chroot to manually configure "full" disk encryption.
    – Rodney
    Dec 1 '21 at 13:00
  • 1
    @chellathurai Since the question title just says "OS installation," I thought I'd add that the Windows installer runs a special OS often called WinPE (Windows Production Environment) that runs software on top of it. So the general concepts apply even there.
    – trlkly
    Dec 1 '21 at 17:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.