Some options (e.g. <code>[[Anaconda Boot Options#autostep|autostep]]</code>, <code>[[Anaconda Boot Options#nogpt|nogpt]]</code>) are handled by the main anaconda program and don't need to be changed.}}

Some options (e.g. <code>[[Anaconda Boot Options#autostep|autostep]]</code>, <code>[[Anaconda Boot Options#nogpt|nogpt]]</code>) are handled by the main anaconda program and don't need to be changed.}}

stage2, a.k.a. install.img: the full installer environment (for graphical or text installs), complete with Python interpreter and shells and stuff.

In olden days, loader did what its name says - it loaded the stage2 (full graphical) anaconda environment and did a couple other tasks required to reach that objective. Those other tasks include things like:

Prompting for language and keyboard (if loader goes interactive for one of the other tasks)

Bringing up the network (if required by one of the other tasks)

Fetching kickstart files, product.img, and updates.img (if requested)

Loading driver disks (if required)

Running media check

Most of the time, all of these things are skipped or happen automatically. If you use a boot.iso, you will most likely never see anything besides a blue background and the "Loading anaconda..." message. This means it's a whole lot of code that is just special cases and receives less testing all the time. Further, it's a special environment: It's newt, it's C, it's old, and it's another layer of stuff getting execed between startup and anaconda.

We need to decide how many of these tasks anaconda still needs to do. For those that are still important, they need to move either into the initramfs (if it's something that needs to happen before anaconda can start) or into the main anaconda program - or some other tool that anaconda can run when we're in the full graphical environment. Everything else should go away.

This may mean we keep some sort of loader-like program, but it could be Python based and non-interactive.