Ubuntu Wiki

WORK IN PROGRESS

This document was written to help developers not familiar with the Ubuntu installer to make changes to it in a manner that will allow said changes to be maintained in the core installer branch.

After you've decided on what changes you would like to make to the installer, the first thing you're going to have to do is make a decision: do you want to make your changes by just modifying the python code in Ubiquity, or do you want to make changes the proper way? The former method can be easier, and for small changes that will never make it back into the main branch of Ubiquity, is possibly ideal. However, you are probably best served by making changes the proper way, that is, making a d-i component for your functionality. This allows for the possibility of your changes one day being included in Ubuntu, and by making a d-i component, allows for your changes to be included in Debian's installer, should they desire it.

This document will not cover making changes using the quick hack method. Instead it will focus on creating a d-i component and matching Ubiquity component, building, and debugging both.

To better understand how all of the various components that make up the Ubuntu installers fit together, we will add functionality to Ubiquity's advanced options dialog that provides the user with an option to install OpenSSH, which will allow the user to remotely administrate the machine after install.

Before we begin, however, some explanation of Ubiquity's origin and design is necessary. Before we get into that, however, you should make sure you understand how debian-installer works, specifically how it is made up of various components and how those components are really just a series of debconf questions.

A great introduction to debian-installer is Frans Pop's Debian Installer Internals (http://people.debian.org/~fjp/talks/debconf6/paper/) paper and accompanying Debconf demonstration video. Please read over the paper before continuing.

So now that you are familiar with debian-installer, how did Ubiquity come into being?

Ubiquity was created to provide a more user-friendly and quicker installation method for Ubuntu. Rather than have a very simple and very ugly menu system as the basis for the installer, the Ubuntu developers chose to use richer user interface elements, such as a timezone map as the basis for each individual component. While there had been work done to add a GTK front-end to debian-installer, this lacked the ability to have such richer UI elements.

Now, Ubuntu chose to keep the old installation method of using debian-installer as an "alternate installer", and it made no sense to maintain two completely independent installation mechanisms, so the design goal of incorporating as much of the old installer's internals as possible into Ubiquity, while distancing itself in its interface, was formulated. It accomplishes this goal by taking the debian-installer components for each bit of the installer, such as tzconfig and user-setup, and wrapping them in a bit of python code that bridges the choices made in their graphical elements (a timezone map and a set of input boxes) to the matching questions in the debian-installer components. So when you run Ubiquity, you're really running the individual d-i components under it, which are being fed the input you're entering into Ubiquity through d-i's preseeding mechanism.

[ picture of the debian-installer block, d-i component blocks with ubiquity component blocks on top of that, page names blocks on top of that, and "ubiquity" on top of that. ]

Preseeding, if you're not familiar with the term, is a way to create a simple text file with responses to debconf questions asked by the installer that you know the answer to ahead of time. Large deployments will often use it to automate installations. In Ubiquity, we use it to feed data into debian-installer. We accomplish this through

[ picture of selected timezone -> debconf: tzconfig/timezone = US/Eastern -> tzconfig ]

While this definitely helps dogfood preseeding and will eventually allow for a fully automated Ubiquity installation, it can make hacking on the Ubiquity code quite the daunting task. The idea of making cdebconf plugins instead, has therefor been tossed around, but that will not be completed anytime soon, if ever, and is irrelevant to this document.

Another goal of Ubiquity, as mentioned above, was to make installations faster by copying the files that make up an Ubuntu installation off the LiveCD and into the new root partition, rather than by bringing up a base system, copying over the necessary packages, and installing them one-by-one, which is the method used in debian-installer and can often be quite slow. This bit of design information shouldn't affect how you develop your changes to Ubiquity, but it should serve to help understand how Ubiquity works.

Now, with all of that said, it should be clear that we need to split our ssh server functionality into two parts. We will first create a debian-installer component to add this functionality to the alternate installer CD. Once we have made those changes and tested them, we will proceed to wrap that debian-installer component in a Ubiquity component.

Development should be done using the development release of Ubuntu. This will ensure that the code you're working with is not outdated and will greatly ease the difficulty in merging your changes into the main branch. If you are not comfortable running the development release on your machine, you can set up a chroot or virtual machine environment containing the latest development version. The instructions for doing so, however, is outside the scope of this document.

Once you have accomplished that, you'll need a copy of debian-installer. Type the following into a console:  apt-get source debian-installer 

Familiarize yourself with the build environment. The list of various build options can be found by typing make in the build/ directory.

Now, from reading the Debian Installer Internals paper, you should know that d-i components are actually special Debian packages called udebs. So lets make a udeb that has two scripts, one which asks the user if they want to install openssh-server, and another that acts upon the value of that question.

...