UbuntuExpress

Differences between revisions 12 and 52 (spanning 40 versions)
⇤ ← Revision 12 as of 2005-04-24 08:31:10 →
Size: 5416
Editor: intern146
Comment:
← Revision 52 as of 2008-03-04 14:43:55 → ⇥
Size: 6368
Editor: 193
Comment:
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
= Title =  * 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: BrainDump, BreezyGoal, UduBof, DistroSpecification[[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 after some of them want to install that they are using. 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 so much.
 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:
 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 34: Line 23:
 * Reuse existing installer components for configuration
 * Ask all questions at the very beginning of the process
 * Display one big progress bar for the rest of the process
 * There could be 2 way people like to use:
  1. Install after the user test the distro
   * In this case is it really useful to ask some questions before to test or just before to install (after test)?
   * The user could like to change some information for the instalation after test well the CD.
  1.#2 Install without test the distro (kind of clone with post configuring)
   * Some user could like to make a fast installation almost with no question and without try before the distro.
   * It's possible not to launch the live session but to start the copy and postconfiguring. We just need to skip the step where the distro is started, ask the rest of the information from the d-i, and copy and so on.
   * With this option we have no any more the limitations of the only-desktop system or for server installations		 == Requirements ==
Line 46: Line 25:
 * 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 ==
Line 49: Line 34:
=== Implementation proposal (JuanjeOjeda) === === Proposed Implementation ===
Line 51: Line 36:
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) There are six major components to implement (either from scratch or based on existing code):
Line 53: Line 38:
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 suggested 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.		  * [: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 57: Line 45:
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. === Installer Refactoring ===
Line 59: Line 47:
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.		 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 63: Line 49:
This one would be similar in the version from teh live session as the other one. The following udebs may be used:
Line 65: Line 51:
 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)		  * `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 70: Line 56:
In the live session's version both stages would be with graphic, but in the other one could be anyone. 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.
Line 76: Line 78:
 * casper  * `base-config`
 * `casper`
 * `grub-installer`
 * `kbd-chooser`
 * `localechooser`
 * `partman*`
 * `yaboot-installer`
Line 81: Line 89:
 * Should be able to use Gnome, KDE, Dialog, text user interface
 * Should be possible to customize it (Branding stuff)		  * Should be able to use GNOME or KDE UI elements
Line 85: 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 106: 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 107: 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/]
----
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

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/]

CategorySpec

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