UbuntuExpress

Revision 37 as of 2005-06-05 17:49:40

Clear message

Ubuntu Express

Status

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

The Ubuntu live CD inspires many people to install Ubuntu. At the moment, those people who downloaded the live CD then have to download another one in order to complete the installation. We should streamline this process. A live CD installer would be faster than the traditional installer within its limited use case, and would allow us to remain competitive with other popular live CD systems.

Scope and Use Cases

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

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
  • The result should be as close as possible to that of a normal installation

Implementation Plan

Proposed Implementation

There are five major components to implement (either from scratch or based on existing code):

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

Installer Refactoring

We will reuse some installer components in the live environment, either by extracting udebs into a temporary directory or by unpacking the udebs using dpkg, and then by running some parts of them directly. We may need to take into account minor differences between debconf and cdebconf. Unpacking udebs into the ramdisk will require installing their dependencies too.

The following udebs may be used:

  • grub-installer

  • yaboot-installer

  • partman*

Dependencies of these which are only available as udebs:

  • archdetect

  • di-utils-mapdevfs

  • os-prober

We will factor out the portions of grub-installer and yaboot-installer which deal with configuring and installing the bootloader rather than user interaction, and call those. All the partman* packages will be merged into a single source package (pending conversation with upstream) and made to generate a single normal binary package as well as the 20 or so udebs.

Some of the logic for locale, keymap, and timezone selection may need to be factored out of localechooser, kbd-chooser, and base-config respectively, to avoid duplicating complex code with many special cases.

The detect-keys plugin may need to be factored out of cdebconf and kbd-chooser, depending on the outcome of LiveCDPrompts.

Base System Configuration Questions

Depending on the outcome of LiveCDPrompts, we may need to ask some number of the following questions when configuring the base system:

  • language
  • country (inferred from timezone?)
  • timezone
  • keymap
  • user's real name, username, and password
  • hostname

Other Issues

Since we only intend to offer GRUB as the bootloader on i386/amd64 systems, we may need to disable some partitioning choices that currently cause the installer to fall back to LILO. Currently, installations with /boot on either an XFS filesystem or an LVM logical volume do not work reliably with GRUB under all circumstances.

We need to honor debconf preseeding to facilitate the creation of customized live CDs. This may involve adjusting the way that casper silences certain installer questions.

Data Preservation and Migration

Packages Affected

  • base-config

  • casper

  • grub-installer

  • kbd-chooser

  • localechooser

  • partman*

  • yaboot-installer

User Interface Requirements

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

Outstanding Issues

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

Directly copying the fs-image:

  • In the case of a single Ext3 partition, investigate whether copying the image directly off the LiveCD and then running ext2fsresize is significantly faster than a mkfs + cp.