Ubuntu Express

Status

• Created: Date(2005-04-23T02:50:00Z) by MattZimmermanBR

• Priority: HighPriorityBR

• People: MattZimmermanLead, ColinWatsonSecondBR

• Contributors: MattZimmermanBR

• Interested: JuanjeOjedaBR

• Status: BreezyGoal, UduBof, DistroSpecification, DraftSpecBR

• Packages: BR

• Depends: BR

• UduSessions: 1, 4, 8, etc BR

Introduction

Create an Ubuntu installation system which runs within the Ubuntu live CD environment and works by copying and customizing the live CD filesystem rather than installing packages.

Rationale

A lot of people try the Ubuntu live CD and like it so much they decide to install Ubuntu. It doesn't make sense to say "eject the CD, download another one, and then you'll be able to install Ubuntu".

This installation is also much faster than installing from packages. With proper configuration, it could theoretically be used as cloning infrastructure in large deployments (although this is a secondary concern).

At this moment there are many popular Debian derivatives with live CD versions which use this kind of installer. We should get into this game.

Scope and Use Cases

General

1. A user boots the live CD, falls in love with Ubuntu, and wants to use it forever after. They should be able to select an obvious icon on the desktop and launch the installer.
2. A user wishes to use the live CD with the intent of installing the system immediately. They should be able to select a CD boot option which immediately launches the installer.
3. A user wishes to install a system based on a customized live CD environment (either a saved overlay or a custom root filesystem)

Implementation Plan

Requirements

• The implementation should re-use existing installer components for configuration to the greatest extent possible, in order to share bugfixes and improvements
• All install-time questions should be asked at the very beginning of the process, and then the installer should proceed non-interactively
• The installer should display a single, clear progress bar for the remainder of the process

Proposed Implementation

There are five major components to consider:

• A user interface
  • A user interface component, written in Python, which will drive the installation process. It will ask questions of the user, and invoke backend routines to act on the user's choices.
• A partitioning tool
  • For automatic partitioning, we would like to share code with the existing installer component (partman). This will be best accomplished by providing it as an installable binary package (in addition to an installer component), so that it can be added to the live seed and used in a standard environment. partman uses debconf progress indicators, so some consideration is required in order to provide a consistent progress bar in the installation tool.

    For advanced/interactive partitioning, we will extend an existing partitioning tool. The selection and development of this tool are discussed in GraphicalPartitioningTool. The installer must unmount all hard disk filesystems and deactivate swap before acting on the partition table, or launching an external partition editor.

• A component to copy the filesystem into place
  • The copying component is largely trivial, though it has been proposed that it would be useful to allow the user to choose whether to copy the pristine filesystem, or the version which has been modified during the session. If the modified filesystem is copied, some of the modifications made to it by casper must be reversed. This needs more discussion.
• Base system configuration
  • The installer already contains code to configure the base system, which we can reuse; in particular, ["OEMInstaller"] specifies a new firstboot component which can reconfigure just some parts of an installed system. The requirements of this component are very similar, so they should share code.
• Boot loader installation
  • The installer has a substantial volume of code to handle boot loader installation (including a number of sanity checks) which we should reuse. This is currently part of udeb maintainer scripts.

We need a strategy for reusing installer components in the live environment. This may involve extracting udebs into a temporary directory and running those by hand, although the options have not yet been fully explored. We need to take into account differences between debconf and cdebconf (for example, debconf does not yet have progress bar support). Unpacking udebs into the ramdisk will require installing their dependencies too (os-prober, mapdevfs, and so on).

The following udebs may be used:

• grub-installer
• lilo-installer (?)
• yaboot-installer
• partman*

Dependencies of these (plus lots of filesystem stuff):

• archdetect
• di-utils-mapdevfs
• os-prober
• parted-udeb

Alternate Implementation proposal (JuanjeOjeda)

We can use the debconf's frontends to do that. I propose create a udeb package for the d-i which load a debconf template into its own database and install the installer program. (I think it's better to do in the cow or cache filesystem/directory)

The template would contain all the necessary dialogs for the installation (with the translations and so on). The installer would get all the information what need (and have) from the debconf database to suggest it to the user. And show the dialogs and that information with the frontend selected by default (Gnome, KDE, Dialog, etc). We can change this frontend from the application or script who launch the installer. After to get all the information we need from the user, we would configure the corresponding packages with that information.

The debconf's frontend system is pretty good and make good job abstracting the user interface from the real program. In fact, the perl module for the Gnome frontend use Gtk2 and fancies widgets like druid to make the graphic interface. But maybe is good idea improve it (more HIG and love). Even could be good idea to rewrite this module in python (with some improvements) and use it from the program.

Also we could add to casper package an option to launch the live session or copy the distribution to the hard drive. To do better this, I guess could be good idea separate the installer in 2 stages:

1. Ask the data

Ask all the information we need to make the installation.

This one would be similar in the version from the live session as the other one.

2. The proper installation
   • Select disk/partition and format
   • Copy the distro to the partition
   • Put the data from the first stage to the packages debconf information and reconfiguring them (with no ask, of course, because we already know the dates)

In the live session's version both stages would be with graphic, but in the other one could be anyone.

Data Preservation and Migration

Packages Affected

• casper

User Interface Requirements

• Should be simple
• Should be able to use Gnome or KDE UI elements

Outstanding Issues

• Simple
• Faster than the other installer
• Well integrated with Debian/Ubuntu (postconfig)
• The result must be the same (or really close) than the packages installation

UDU BOF Agenda

• How to refactor existing installer components to allow them to be used in the live environment
• Custom components needed
  • Graphical partitioner
• User interface
  • GNOMEish frontend (but allow for KDEish frontend as well)
• Limitations
  • Can't be used for upgrades
  • Can't easily be used for server installations (especially not via serial console)
  • Specialized for the common case desktop installation

UDU Pre-Work

• Check out knoppix-installer

Thoughts/Suggestions