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.

very brief look at the history

• 1999 – First commit (pjones, dcantrel, clumens)
• 2007 – Red Hat Enterprise Linux 5 (Fedora 7)
• 2007 – Anaconda team in CZ (msivak, jgranado)
• 2009 – mkinitrd abandoned in favour of dracut (hansg)
• 2010 – Red Hat Enterprise Linux 6 (Fedora 14)
• 2010 – Storage subsystem rewrite (dlehman)
• 2011 – First complete get-together ever (Tempe, US)
• 2011 – Lorax (mgracik)
• 2011 – code updated to use systemd, squashfs (wwoods, bcl)
• 2012 – NewUI, NoLoader

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...

Metacity and Network Manager integration

• Metacity replaced our simple internal WM
• and allowed us to use multiple overlapping windows (like NM settings)

• NetworkManager then replaced our own networking code in stage2
• and also the backend code for network in stage1
• installation over WiFi now probably possible

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:

• logging over network
• Aleš's logpicker script to gather all log files from shell

  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).

• template based
• yum used to resolve dependencies
• blacklists to remove unneeded files
• ldd to resolve binary dependencies for initrd files
• blacklist works when some package splits files

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:

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:

• Shell access in loader – Ctrl-Alt-F2, major help for debugging
• Console setup and reboot are now controlled by systemd
• starting daemons – NM, dbus and others are now properly monitored

"NewUI" - ideas

• Usability
• No "advanced" buttons
• Hub screen with leaves
• Nonessential info during package install
• 3rd party screens

"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

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:
http://linuxgrrl.com/Anaconda/Live Prototypes/index.html

"NewUI"

"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:

• GUI modularity – support for vendor provided dialogs and shareability with firstboot
• fully scriptable – kickstart should support everything we do in GUI and there should be a possibility to hook scripts to more install stages (%prechroot, %upgrade, ..)
• standalone GUI mode – GUI should be usable as a kickstart generator