m (corrected typo interal --> interval)
m (really fixed it this time to internals)
|Line 94:||Line 94:|
[wiki:Self:AnacondaKickstart Kickstart] is a way of automating installations by providing anaconda with a file that contains all the data that the user would have to provide via the UI. This file is an interface between the parser in the pykickstart package and the anaconda
[wiki:Self:AnacondaKickstart Kickstart] is a way of automating installations by providing anaconda with a file that contains all the data that the user would have to provide via the UI. This file is an interface between the parser in the pykickstart package and the anaconda . It primarily provides a way of saving the settings in the places anaconda expects.
Revision as of 16:55, 17 April 2009
anaconda has a lot of source, and this can be a little intimidating at first. It can be difficult to figure out where to even start looking when you're trying to track a problem down. This guide is meant as a very high level overview of the various groups of source files and what sorts of things they cover. It's not incredibly detailed, and some source files don't want to fit into categories. Lots of pieces of functionality are spread out across multiple files.
These files handle the user interfaces. There are three interfaces supported by anaconda: graphical, text, and the command line mode. Each is implemented by its own python file that contains classes for drawing various types of windows and so forth.
The iw/ directory contains python files for the graphical interface screens. The textw/ directory contains python files for the text interface screens. The ui/ directory contains glade interface description files that are also needed for graphical mode. In general, we are trying to move towards more glade files whenever possible.
The dispatcher is a state machine that controls moving between steps in the installer. It knows which screen to go to when a Next or Back button is clicked, and knows which steps should be skipped depending on a variety of settings. Each mode of installation provides its own set of steps that should be skipped.
This file controls setting up VNC for when it is requested during installation. Afterwards, installs proceed in graphical mode.
These files provide the window manager that runs during graphical installations.
These files handle probing, configuring, starting, and stopping the advanced storage devices that are supported by anaconda. LVM and RAID are fairly widely used (LVM is the default partitioning), while the others are much less so.
These files define exception classes for problems that can occur during partitioning.
This file contains methods that are used for error checking, input validation, and displaying error messages. The graphical and text interfaces make use of it.
This group of files implements the partitioning logic. It converts the user's selections into requests, then into entries, and eventually makes partitions on disk. It also controls making filesystems, writing out the /etc/fstab file, labelling devices, and doing automatic partitioning (which is the default). Partitions are created on disk by using the pyparted package.
These files hold the configuration settings that are either entered through the interface or through kickstart. To some extent they affect the installation (for instance, the language and keyboard settings are used in anaconda). However, the main purpose is to write these out to the installed system at the end of installation.
These files control package installation. anaconda allows for multiple package installation backends, though the only real one in the tree uses yum. Each backend provides methods for selecting groups and packages, removing groups and packages, writing out configuration settings, and so forth. For fixing loops in package dependencies, we use the whiteout which explains how to correctly break loops.
Installation classes define settings that form a sort of installation profile. This includes steps to show and skip, product names, installation method, enabled repositories, configuration settings, and so forth. We primarily use it to create a difference between Fedora and RHEL installs. Other projects or ISVs could define their own installation classes for their own defaults.
[wiki:Self:AnacondaKickstart Kickstart] is a way of automating installations by providing anaconda with a file that contains all the data that the user would have to provide via the UI. This file is an interface between the parser in the pykickstart package and the anaconda internals. It primarily provides a way of saving the settings in the places anaconda expects.
These files implement installation from the live CD. They provide, a special installation method, a special package installation backend, and some files needed to launch the installer from the live CD's desktop.
These files provide methods specific to rescue mode and upgrades.
These files provide a variety of miscellaneous methods that are used throughout the installer. These functions include the logging framework, hardware probing, device node management, process control, handling exceptions, and other tasks. They also contain methods that just don't fit anywhere else.
The Main Program
This is the main anaconda program that gets called from the loader. It handles lots of environment setup, enables updates if they exist, reads any kickstart file, sets up VNC, and other tasks. When all this is done, it hands control over to the dispatcher which deals with the rest of the installation process.
These directories contain code that controls how the installation environment is made. This includes creating the initial ramdisk and the stage2 images, adding very basic versions of certain needed commands, splitting the installation tree into media-sized chunks, and other miscellaneous tasks.