Gentoo Linux Installer
Currently, Gentoo has no guided installer. A number of users has expressed
interest in such an application to ease the current installation process.
Many users new to Gentoo or Linux in general, find the installation process
intimidating and even with a strong assurance of support and excellent
documentation, they are reluctant to try. Some users have stated this to be the
singular reason they have not moved to or tried Gentoo yet.
The current process will still be available to those who choose to use it.
The Gentoo Linux Installer project aims to build a normative installation
platform for both desktop and server systems. Generally, the goals of the
installer are consistency across architectures, usability for all users, and
flexibility. The section on features will give a better overview of the
specifics, but suffice it to say it will be for all users, of all experience
levels, for all environments.
The following is a list of features that will be present in the installer.
While not an exhaustive list, it should give you a better idea of what
will be possible. Not all of these features are of use to all users, but
the idea is to provide consistency for all users so keep the mantra of "if
not for me, for someone else" fresh in mind.
Multiple front ends
The installer will have interchangeable user interfaces of which some will be X
GUIs. Since some platforms are more commonly installed with devices that do not
support X windows (Sun serial console installs, etc.) a plain text front end
will be developed. Users will be free to develop a user interface (of any
nature) as they see fit but, due to maintenance, only one text based and one
GUI may be officially supported at first.
Reusable back end framework
The actual workhorse of the installer will be a set of APIs that will be called
from the desired client. In keeping a clean and complete separation of
functionality and user interface, a generic platform will be established for any
tools that wish to control the installation of a Gentoo system. This also
promotes strong consistency across all platforms and environments.
The installer will support automated deployment using pre-configured
installation profiles. This will allow easy installation in larger environments
with similar hardware or in situations where you wish to store a backup of your
machine's initial installation parameters for disaster recovery. The
installation profile will contain all data required to "replay" an installation
(i.e. cflags, use flags, partitioning schemes, post-install packages, etc.).
Dry run profile generation
Users will be able to create installation profiles by going through the
installer without actually performing the steps. All data generated by user
actions will be serialized to an install profile (represented as an XML
document) which can later be used for automated deployment.
Full support for all Gentoo architectures
As a requirement, all architectures supported by Gentoo will be supported by the
installer project. These include, but are not limited to, x86, ppc, sparc,
alpha, amd64, mips, hppa, and itanium. (The one notable exception is embedded
devices. This is due to a highly specialized environment that the installer may
not be able to accommadate.)
Specialized profiles such as SELinux will be supported along side the
traditional (processor based) architectures. These specialized profiles will
support the additional features and requirements of their respective
Open policies and standards use
Whenever possible, the installer will use open formats and standards as to play
nice with other tools that users development. This includes file formats (XML),
network protocols, and other such items. Special care will be taken to not
exclude the use of alternate tools and utilities.
Integration with future configuration projects
Wherever possible, the installer will integrate with Gentoo specific system
configuration tools and utilities to facilitate post-install setup and
configuration of machines. Support for non-Gentoo specific tools such as
cfengine may also be included.
Design and Structure
The structure of the installer must be generic enough to support the features
above while not abstracting ourselves so far away from the system that simple
tasks become difficult or maintainability becomes cumbersome.
A few design requirements were stated:
- Multiple UIs must be supported (abstracted view support)
- A complete separation of model, view, and control logic be kept
- All features must be supported regardless of front end or architecture
- Automated deployment always be possible
To this end, the installer platform (as the entire system is referenced) is
broken up into three major parts.
Front end (Client)
The client is the user's interface to the system. It contains all user interface
logic and support. Also, minor state information about temporary configuration
of the client, itself, including command line arguments, environment settings,
invocation method (interactive / non-interactive), logging locations, binary
package server URIs, and more. Some of these settings will "stick" to the
install, but most will not.
The user will be able to use their desired front end to generate installation
profiles to be used for later deployment, and in this respect can also be
thought of as a profile generation utility.
The client may also integrate with system configuration tools at a later date.
Generally, the client is "dumb" and is unaware of implementation logic of the
actual installation process, although some architecture specific logic will be
Back end (API or framework)
The meat and potatoes of the installer is a set of object oriented APIs that
abstract the actual commands run to install the system. The framework is
somewhat abstracted in that the behavior is dependent on what architecture
template is being used at the time. The number of discreet steps performed
largely depends on the requirements and implementation of the architecture
template (an XML file that is similar in nature to Portage's /etc/make.profile
Since the framework is segregated from the client, it may be used for customized
installation products developed by users. The major classes are as follows:
A controller class that dictates, based on the architecture template (an XML
file), what steps to perform and in what order. This is the core of all
A installation profile class that maintains all installation information
such as partitioning schemes, cflags, use flags, and other such data. This
class can serialize itself to XML which can then be placed on an automated
deployment server for later use.
Other minor classes may be used for intermediary support, but these two solidify
what is to be considered public to developers of clients.
The third component is probably only of interest to those using the automated
deployment features of the installer. The deployment server is actually only a
combination of services and files.
Installation profiles may be stored on a machine and served up using an rsync
server. The client (or, specifically, the back end) will fetch all available
profiles when given the URI of the rsync server. This is the one part of the
The deployment server may also run tftp and dhcp services to facilitate
netbooting for large scale installations. This usually requires netboot support
on the client machine, but custom live cds with such support may be made
available by Gentoo.
In short, the deployment server isn't a specific daemon or service, but a
combination of freely available and standard services. The idea is to take
advantage of services that may be already running on a user's network.
The actual process of which steps to perform in which order and how is primarily
determined by the architecture templates. For the most part, the architecture
template will replicate the steps shown in the Gentoo Installation Handbook.
The special architecture templates such as the previously mentioned SELinux can
use this same mechinism to alter the standard process. The arch templates will
override the default behavior from a generic template. This way, each arch does
not have to specify thing such as syncing the portage tree, emerging system, or
other such steps that all archs have to do.
The developers working on the Gentoo Linux Installer congregate in two main
places. The IRC channel #gentoo-installer (on Freenode) is the main discussion
forum where many issues are hashed out in realtime. This is usually the
preferred place for in depth discussion. For more general dicussion we have a
mailing list devoted to the installer. You can subscribe by sending an email to
Authors and Contributors
All information in this document has been hashed out over multiple conversations
from a number of places.
In #gentoo-installer, blackace, dams, esammer, iggy, karltk, klieber, Method,
pauldv, port001, Ramereth, Rupart, spyerdous, npmmcullum, and tseng. Others have
also passed through and helped, but these people are currently idling during the
drafting of this doc.
The desktop-research mailing list was where this project was initially pulled
together as an official Gentoo project wth the current team. Thanks to those
people as well.
The #gentoo-server channel has been helpful in hashing out many automated
deployment issues and recommendations. Thanks to them.
This document is a cumulative reference and is the work of everyone in the
The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply.