Jamie Bennett Speaks

One of the goals for the Lucid cycle was to investigate why it took so long to boot an Ubuntu live cd session. Why is this important I hear you ask? Well the live cd is usually the first thing a potential new Ubuntu user sees. They get an Ubuntu Desktop (or other flavour) cd from their friend/colleague/random person, insert it into their machine, wait for a while and are then presented with a live session. All well and good but if your running on slower hardware, even a different architecture such as ARM, this initial slowness can be orders of magnitude more than a fast desktop/laptop. For example, the ARM images we shipped for Karmic took over 3 minutes to boot into a live desktop session.

How do you boot a live cd session?

The first thing to do was find out why it was slow. There are a few ways to do this but I chose to first use simple time-stamping methods and afterwards, the much prettier bootchart package.

A bit of background on how the live cd session is booted. There are two broad steps in the process of booting a live cd, the first is setting up the environment ready for the session, and the second, you guessed it, is actually booting into the session. Initial hunches were that the first step, setting up the session, was the major cause of slowness so investigations started there.

Casper

Setting up the session is the responsibility of a project called casper. Casper is a set of scripts that are run on boot to do such things as unpack the initial filesystem, add a dummy user, setup languages and keyboard layouts and so forth. Its mainly written in perl.

The time-stamping stage of investigates confirmed that casper was indeed slower than it should be. I’ll skip ahead to the bootchart part of the story as thats much more visually interesting.

Casper before

Above you can see the casper section of the live cd boot process. I’ve highlighted the bits that immediately stand out. The overall boot was 3 minutes and 15 seconds with casper responsible for around 2 minutes of that.

The highlighted bits seemed to have one thing in common, they all interacted with the debconf database. From the debconf programmers tutorial document:

“debconf is a backend database, with a frontend that talks to it and presents an interface to the user. There can be many different types of frontends, from plain text to a web frontend. The frontend also talks to a special config script in the control section of a debian package, and it can talk to postinst scripts and other scripts as well, all using a special protocol. These scripts tell the frontend what values they need from the database, and the frontend asks the user questions to get those values if they aren’t set.”

So communicating with the debconf database was slowing the boot. Initiating the call, sending the data and receiving a response, was taking up to 4 seconds at a time and when there are many of these calls, they all soon add up.

After many a head-scratching moment it was decided that the best way to solve this would be to initiate the communication once and keep it open so that when debconf was needed, the overhead in setting it up was removed. The implementation details are all in the code history but the results are much easier to show.

Casper after

With a couple of other tweaks besides the debconf one, the boot is now down to 1 minute 53 seconds and casper takes just under 50 seconds of that. There is more room for improvement, pre-generating a default locale (although which locale that would be is a tough choice), pre-generating fonts and looking into SSL, but for now, this is a big win.

The bootcharts above are for the ARM based iMX51 device made by Freescale which is only just beginning to proliferate onto the market. Intel/AMD based machines show an equivalent speed-up.

Conclusion

So there you have it. The next time you boot into a Lucid live cd session it shouldn’t take quite so long, and now you know why.