UbuntuExpress

Differences between revisions 18 and 55 (spanning 37 versions)
⇤ ← Revision 18 as of 2005-04-26 10:02:42 →
Size: 7376
Editor: intern146
Comment: this is editedspec now. whats a
← Revision 55 as of 2008-08-06 16:32:33 → ⇥
Size: 6422
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
= Ubuntu Express =  * Launchpad entry: https://launchpad.net/distros/ubuntu/+spec/ubuntu-express
 * Created: <<Date(2005-04-23T02:50:00Z)>> by MattZimmerman
 * Contributors: MattZimmerman, ColinWatson
 * Packages:
Line 6: Line 9:
== Status == == Summary ==
Line 8: Line 11:
  * Created: [[Date(2005-04-23T02:50:00Z)]] by MattZimmerman[[BR]]
  * Priority: HighPriority[[BR]]
  * People: MattZimmermanLead, ColinWatsonSecond[[BR]]
  * Contributors: MattZimmerman[[BR]]
  * Interested: JuanjeOjeda[[BR]]
  * Status: BreezyGoal, UduBof, DistroSpecification, EditedSpec[[BR]]
  * 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.		 An Ubuntu installation system will be created that runs within the Ubuntu live CD environment, and works by copying and customizing the live CD filesystem rather than installing packages.
Line 24: Line 15:
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 this people: "take off the CD, download another one, and then you'll be able to install Ubuntu"

Also this installation is much faster than from packages, so it's going to be less annoying process to the users. It even could be used in massive installations as a clonation system (but with proper configuration).

At this moment there are many Debian derivatives with live CD version which use this kind of installer and their users like it a lot. We should get into this game.
 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.
Line 33: Line 19:
=== 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. S/he can install it in the hard disk or in a USB key, including the BootLoader in the harddisk or USB key.
 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).
Line 35: Line 23:
 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 ===		 == Requirements ==
Line 46: Line 28:
 * The result should be as close as possible to that of a normal installation

== Design ==

== Implementation Plan ==
Line 49: Line 36:
There are five major components to consider: There are six major components to implement (either from scratch or based on existing code):
Line 51: Line 38:
 * A user interface  * [[UbuntuExpress/GnomeUserInterface|A user interface]]
 * [[UbuntuExpress/PartitioningTool|A partitioning tool]]
 * [[UbuntuExpress/CopyFileSystem|A component to copy the filesystem into place]]
 * [[UbuntuExpress/LanguagePacks|Language pack installation]]
 * [[UbuntuExpress/BaseSystemConfiguration|Base system configuration]]
 * [[UbuntuExpress/BootLoader|Boot loader installation]]
Line 53: Line 45:
   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. === Installer Refactoring ===
Line 55: Line 47:
 * A partitioning tool 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.
Line 57: Line 49:
   For automatic partitioning, we would like to share code with the existing installer component (partman). For advanced/interactive partitioning, we will extend an existing partitioning tool. The selection and development of this tool are discussed in GraphicalPartitioningTool. The following udebs may be used:
Line 59: Line 51:
 * A component to copy the filesystem into place  * `grub-installer`
 * `yaboot-installer`
 * `partman*`
 * `live-installer` (produces same results like base-installer) - look at http://launchpad.net/products/live-installer and http://gnome-ev.de/index.php/GNOME_LiveCD/Documentation/LiveCDInstaller, but note that ubuntu-express has a separate implementation and a udeb may not be appropriate
Line 61: Line 56:
   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. Dependencies of these which are only available as udebs:
Line 63: Line 58:
 * Base system configuration  * `archdetect`
 * `di-utils-mapdevfs`
 * `os-prober`
Line 65: Line 62:
   The installer already contains code to configure the base system, which we can reuse; in particular, ["OEMInstallation"] 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. 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.
Line 67: Line 64:
 * Boot loader installation 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.
Line 69: Line 66:
   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. The detect-keys plugin may need to be factored out of `cdebconf` and `kbd-chooser`, depending on the outcome of LiveCDPrompts.
Line 71: Line 68:
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). === Other Issues ===
Line 73: Line 70:
=== Alternate Implementation proposal (JuanjeOjeda) === 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.
Line 75: Line 72:
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.

 1.#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.		 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.
Line 100: Line 78:
 * casper  * `base-config`
 * `casper`
 * `grub-installer`
 * `kbd-chooser`
 * `localechooser`
 * `partman*`
 * `yaboot-installer`
Line 105: Line 89:
 * Should be able to use Gnome or KDE UI elements  * Should be able to use GNOME or KDE UI elements
Line 108: Line 92:

 * 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
Line 129: Line 108:
   * (you should also check out the Installer of Kanotix, a breeding place of many things that are now in Knoppix, also the new knoppix-installer is derived from Kanotix -> [[http://kanotix.com/index.php?&newlang=eng]]
 * Check out the Mepis LiveCD installer
 * Write up of [[http://www.willmer.com/kb/2005/02/installing-ubuntu-hoary-from-livecd/|installing Ubuntu]] from the cloop manually
Line 130: Line 112:
= Thoughts/Suggestions = 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`.

=== Guadalinex implementation ===

 * [[http://interactors.coop/~trunks/installer/]]

== See also ==
 * [[install.exe]]
----
CategorySpec

Summary

An Ubuntu installation system will be created that 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. S/he can install it in the hard disk or in a USB key, including the BootLoader in the harddisk or USB key.

  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

Design

Implementation Plan

Proposed Implementation

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

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:

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.

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

  • Check out knoppix-installer

    • (you should also check out the Installer of Kanotix, a breeding place of many things that are now in Knoppix, also the new knoppix-installer is derived from Kanotix -> http://kanotix.com/index.php?&newlang=eng

  • Check out the Mepis LiveCD installer

  • Write up of installing Ubuntu from the cloop manually

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.

Guadalinex implementation

See also

CategorySpec

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