UbuntuExpress

Differences between revisions 31 and 32
⇤ ← Revision 31 as of 2005-04-28 23:31:16 →
Size: 7603
Editor: intern146
Comment: list formatting tweak
← Revision 32 as of 2005-04-28 23:33:12 → ⇥
Size: 7604
Editor: intern146
Comment: formatting
Deletions are marked like this. Additions are marked like this.
Line 57: Line 57:
 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 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.
Line 63: Line 63:
 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.  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.
Line 67: Line 67:
 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.  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.
Line 75: Line 75:
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). 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.
Line 79: Line 79:
 * grub-installer
 * yaboot-installer
 * partman*		  * `grub-installer`
 * `yaboot-installer`
 * `partman*`
Line 85: Line 85:
 * archdetect
 * di-utils-mapdevfs
 * os-prober		  * `archdetect`
 * `di-utils-mapdevfs`
 * `os-prober`
Line 116: Line 116:
 * base-config
 * casper
 * grub-installer
 * kbd-chooser
 * localechooser
 * partman*
 * yaboot-installer		  * `base-config`
 * `casper`
 * `grub-installer`
 * `kbd-chooser`
 * `localechooser`
 * `partman*`
 * `yaboot-installer`

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

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

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.

Installer Refactoring

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.

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 intend to 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 honour 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

  • Check out knoppix-installer

UbuntuExpress (last edited 2008-08-06 16:32:33 by localhost)