Ubuntu Wiki

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/simplified-livecd

• Created: 2005-10-31 by ColinWatson

• Contributors: ColinWatson, MattZimmerman, FabianFranz, JuanjeOjeda

• Packages affected: casper, initramfs-tools

Summary

Simplify and improve the live CD's bootstrap mechanism.

Rationale

As of Ubuntu 5.10, the Ubuntu live CD bootstraps itself using the installer machinery. While this was convenient for purposes of maintainability, it has disadvantages in performance, interactivity, complexity and aesthetics. It should be replaced with a simple initramfs which handles the following tasks non-interactively:

• Progress display using usplash
• Hardware detection (using standard, shared Ubuntu mechanisms)
• Location and mounting of the live media
• Initialization of the live filesystem
• Transfer of control to the live filesystem

Use cases

• Most users of the live CD want it to boot quickly and painlessly, without a sharp visual distinction between various stages of the bootstrap process.
• Pierre is French, and still wants to be able to select French as his language, have a reasonable keymap selected for him, etc.

Scope

This specification covers a redesign of the live CD bootstrap process. It does not attempt to address additional features that might be implemented in the live CD, although the redesign should take care to retain customisability and not to restrict reasonable extensions.

Design

We will replace the d-i frontend with a simple initramfs with a usplash progress bar. This may be built using the d-i build system (which knows how to build initramfs now, and can build it out of udebs) or using mkinitramfs (which can build the initramfs out of arbitrary hooks, and already knows how to chain to a new root filesystem). This should carry out the following operations:

Boot loader

SuSE applies the "gfxboot" patch to isolinux to allow graphical language selection.

What should we do for powerpc, since nothing similar exists for yaboot? We could just rely on the user supplying kernel parameters (very suboptimal), or attempt to simplify later reconfiguration of the language/country/keymap once the desktop starts up. Remember that the user must be able to do this without understanding the language in which the desktop is displayed.

ScottJamesRemnant: This seems to still be an Outstanding Issue. One of the use cases it that Pierre should be able to select his language, but this doesn't actually specify how we will fulfill that.

Hardware detection

Mostly udev coldplugging, as with the rest of the system. We need to ensure that suitable modules are present in the initramfs.

lp, mousedev, and psmouse are still loaded manually using /etc/modules in breezy. Which of these are still necessary? On powerpc, many devices on the mac-io bus are also handled using /etc/modules; we should ensure that the mac-io hotplug patches are merged to allow this to be removed.

Locating CD-ROM

The cdrom-detect installer component walks through /dev/cdroms/ (a devfs-style path, relying on udev's compat-full.rules). We can either use it directly (requiring a debconf database, to some extent) or reimplement it without debconf. It appears that a reimplementation would be much smaller than the original, since cdrom-detect performs various other pieces of installer integration as well as just mounting /cdrom.

We should ensure that there is a suitable hook at around this point for future hard drive detection; some other live CD systems allow the live filesystem to be cached on the hard disk.

Again, the build system needs to include suitable modules.

ScottJamesRemnant: is locating the cd-rom simply to mount the root filesystem, or is this used for some other purpose? Could this be done using the udev "by-label" and/or "by-uuid" /dev names?

System configuration

We perform a number of system configuration tasks in the existing live CD, some of which ask questions, some of which do not. (Ideally, we would ask no questions after boot.)

• Language selection On architectures where it is possible, we should allow the user to select the language (and possibly country?) from the boot loader; see above.
• Keyboard layout We should select a reasonable default and allow the user to change it later once the desktop is available. Knoppix and d-i (via console-data) both have algorithms to guess a default layout from the language and country. If there are multiple options, a future version of the Ubuntu live CD could make all of them available in GNOME's keyboard switcher applet.
• Add default user Just invoke adduser or similar. Alternatively, copy the passwd entries in from a template file.
• X, gdm, swap, fstab, etc. casper does this; we can reuse the code.
• Unwinding changes

  casper should make it easy for UbuntuExpress to unwind its changes, for example by moving init scripts out of the way rather than deleting them, and by installing unwind scripts which just need to be invoked.

• Saving logs d-i saves its logs to /var/log/installer/; initramfs-tools should have a similar generic facility.

Live filesystem initialization

We should switch over to the unionfs code in casper's main branch, and investigate moving from cloop to squashfs (both discussed in LiveCDFeatures). Aside from that, we can continue using the current live filesystem initialization code.

Transfer of control to live filesystem from initramfs

To transfer control to the live filesystem, we should overmount the live filesystem on /, then exec run-init. If we use initramfs-tools to build the bootstrap initramfs, then we get this for free from /usr/share/initramfs-tools/init.

Since we will be using usplash to provide a progress bar while bootstrapping, we need to arrange that usplash continues to display a progress bar after transferring control to the live filesystem without jumping back to 0%. UsplashInitramfs discusses this issue.

Implementation

Code

Data preservation and migration

Example of implementation

There is a example of implementation of this. In the [http://www.guadalinex.es Guadalinex]/[http://metadistros.software-libre.org/ Metadistros] new Live system. It is used a modified version of the package initramfs-tools with adding a new BOOT mode: live (see at the /etc/mknitramfs/initramfs.conf the BOOT var) for that. This make to the mkinitramfs to use some hooks which add the scripts and modules necessaries to create the live system.

The system use squashfs and unionfs and is pretty well integrated with the current initramfs-tools pacakage of Ubuntu. Aslo I try to reuse some code from the casper, but didn't work for me very well in some the cases. Maybe somebody could check this out.

The system is new but quite stable. And it's very easy to change things like use cloop or squashfs, the name of the distro image file and so on.

The code is avaible at the [http://ws314.juntadeandalucia.es/guadalinex2005/generation_system/live/initramfs-tools/ Guadalinex project's svn].

System configuration:

• We didn't put any language selector or so, because we think it's better option to use the [https://launchpad.net/distros/ubuntu/+spec/gdm-keyboard-layout GDM].

• The user is specified at the initramfs config file (/etc/mknitramfs/initramfs.conf) and added in the boot process.

• And we use the current initramfs' log file (/tmp/initramfs.debug), but we save into the live system for debug.

Locating the distro image file: We search in each block device, just in case the file is not in a ide or scsi CDROM, but in a USB device, harddisk or whatever. Whith the initramfs system is easy and fast.

JuanjeOjeda

Outstanding issues

• How much code would be realistically shared with the udebs?
  • localechooser, kbd-chooser hooks
  • don't need progress bars anymore due to usplash
  • don't need any user input, as we won't ask any questions anymore
  • don't need netcfg due to network-manager
• would like to avoid complexity wherever possible, but also share code in order to benefit from well-tested components

BoF agenda and discussion