Red Hat logo

Anaconda
- the past, the present and the future

David Cantrell <dcantrell@redhat.com>
Martin Sivák <msivak@redhat.com>

with additional materials provided by: Máirín Duffy <duffy@redhat.com>

The team

We are split between the United States (6) and the Czech Republic (3). Each team member has expertise on different parts of the installer and accompanying packages.

Anaconda team, photo taken at Tempe FUDCon 2011

very brief look at the history

history of source code

Anaconda from the RPM's point of view

The image bellow represents the dependency graph of packages to be installed as Anaconda's direct and inherited requirements. There are a lot of places where changes or bugs end up affecting the installer...

Anaconda dependency graph

The past
- but a pretty recent one

Metacity and NetworkManager integration



rsyslog integration

Anaconda's syslog implementation was very simple daemon used to read the queue and print it into file. Rsyslog integration introduced some very useful features:

  boot_prompt syslog=<remoteip>:<remoteport>

buildinstall replaced by Lorax

Anaconda itself is just a program to setup the destination environment and instruct yum to instruct rpm to extract packages. But to run it needs multiple libraries and an environment of its own.

So we used to have a buildinstall script (in bash) which gathered all listed packages + files (whitelist) and created the images needed for install initrd.img and stage2 part.

It ended being too complicated and unmaintainable... so voila.. Lorax (Dr. Seuss' character who speaks for the trees).

initrd + squashfs

Stage2 image for anaconda was over 400 MB uncompressed. This space came from available memory just to hold the installation environment.

By using encapsulated images in the squashfs format, we can save most of this space, because the format is uncompressed per file as needed. Especially when installing from DVD or NFS, the requirements are much lower, because the image doesn't even need to be downloaded to RAM.

Worst case (http) memory consumption by ramdisks:

RHEL6
rd
st2
uncompressed st2


F17
rd
squashfs.img

systemd integration

When systemd was introduced in Fedora we decided to move our init tasks to its control. This step simplified our setup routines and allowed us to have some more features:

"NewUI" - ideas

Hub sketch

The present

"No Loader"

For a very long time, the installer has had a large piece written in C. Its task was to prepare the environment for the stage2 part (install.img, squashfs.img..), download the image, unpack it, and launch the actual installer. We called this C program loader

The tasks performed by loader are now dracut module written in bash. Which at this time reduced the code to about 10% of its C loader size.

We plan on some interactivity, but we decided that the newt library will be abandoned in favor of some kind of Q&A mode, like a shell prompt. The goal we seek here is to improve support for serial consoles.

There are also changes in our command line arguments, most were renamed to play well with other boot arguments used in dracut. So at the moment, most have a new prefix: inst.

"NewUI" - design

Flow design image

Initial brainstorming for the new user interface happened at FUDCon in Tempe, AZ.

Design started around mid 2011, when Máirín Duffy gathered screens and flows from current anaconda installs and user cases and created the first mockups and flow diagrams of the proposed GUI.

There is also a live SVG based demo Mo created for us later:
http://linuxgrrl.com/Anaconda/Live Prototypes/index.html

The future

"NewUI"

All Hub and Spoke screens

"New" anaconda

There is no such thing as a new anaconda. It supports so many features, that we are only able to rewrite subsystems at a time. And even at this pace it usually takes one or two Fedora releases to stabilize the rewritten part.

We would like to focus on couple of key concepts in the future installer versions:

Questions?
- how to contact the Anaconda team

mailinglist: anaconda-devel-list@redhat.com
IRC: #anaconda @ Freenode