Red Hat logo

- the past, the present and the future

Martin Sivák <>

with additional materials provided by: Mairín Duffy

The team

We are split between US (6) and the Czech Republic (3). Each of us has an expertise on different parts of the installer and some 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 tree of packages to be installed as Anaconda's direct and inherited requirements. There is a lot of places which might broke and cripple the installer...

Anaconda dependency tree

The past
- but a pretty recent one :)

Metacity and Network Manager integration

rsyslog integration

Anaconda's syslog implementation was very naive 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 explode packages. But to run it nees multiple libraries and environment of it's 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 (fairytale character who speaks for the trees).

initrd + squashfs

Stage2 image for anaconda had over 400 MB uncompressed. This space was taken out of 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 ramdiscs:

uncompressed st2


systemd integration

When systemd was introduced into main Fedora we decided to move our init tasks under it's control. This step simplified our setup routines and allowed us to have some features:

"NewUI" - ideas

Hub sketch

The present

"No Loader"

There has been a C part of anaconda for very long time. It's task was to prepare the environment for the stage2 part (install.img, squashfs.img..), download it and execute.

It's tasks moved now to dracut module written in bash. Which at this time shrinked the code to about 10% of it's C loader size.

We plan on some interactivity, but we decided that newt will be abandoned in favour of some kind of Q&A mode. 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 got a new prefix inst.

"NewUI" - design

Flow design image

According to my logs, design started around mid 2011, when Mairí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: Prototypes/index.html

The future


All Hub and Spoke screens

"New" anaconda

There is no such thing as new anaconda. It supports so many features, that we are able to rewrite only parts 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:

- how to contact the Anaconda team

IRC: #anaconda @ Freenode