OEMInstaller

Differences between revisions 27 and 28
Revision 27 as of 2005-06-09 18:59:34
Size: 5094
Editor: host81-153-126-219
Comment: status (started locale configuration)
Revision 28 as of 2005-07-18 17:04:01
Size: 5550
Editor: fire1
Comment:
Deletions are marked like this. Additions are marked like this.
Line 90: Line 90:
 * citizenDAK: Handle partially-completed "firstboot" or errors? For example, if some chunk of the firstboot is completed--user settings entered--then for some reason the machine's interrupted or rebooted... It'd be a hassle to force the user to re-enter everything. Can they pick up where they left off, or at least have the firstboot UI "remember" previous choices as the default selections. (Is this what "return to firstboot afterwards" means?)

OEM Installer

Status

Introduction

Provide an installation method which is suitable for OEMs.

Rationale

OEM providers want to install fully-functional systems in-house while deferring some aspects of configuration so that end users complete the configuration on initial boot. They also want to be able to customise the installed system, e.g. for branding.

(Windows and Mac OS offer similar OEM functionality.)

Scope and Use Cases

  • Initial installation: normal (or possibly automatic) install using temporary values for language, country, etc. and no initial user.
  • Customise installation to rebrand, add custom drivers and other software, etc.; this is totally at the discretion of the OEM.
  • Test that system actually works properly: graphics, sound, network, etc.
  • Create system image and mass-duplicate onto N hard disks.
  • Ship to users.
  • On first boot, end users are asked for some set of the following, at the OEM's discretion:
    • language
    • country
    • keyboard layout
    • timezone
    • full name, user name, and password
    • possibly Internet access if it can't be determined automatically?
    • other OEM-provided hooks (e.g. licence agreements for custom software)
  • May also be useful for large deployments in a single organisation that require some per-user configuration after rollout by the IT department.
    • Example: roaming laptop users want a local user that doesn't rely on NIS/LDAP/etc.

Implementation Plan

Add an OEM package (name TBD) which implements the following:

  • An OEM test mode which starts X as root and runs hwdb-client (or something similar).
  • A firstboot program which runs a set of hooks. When these hooks are finished, it should remove itself from /etc/inittab and continue the normal boot process.
  • A command to prepare the image for shipping to the user, inserting a line into /etc/inittab which runs the firstboot program. It might be possible at this stage to select the list of hooks to be run.

Hooks are provided to maximise code reuse and to allow OEMs to add extra questions and code, such as the licence agreement example above. Where possible, we will modify installer packages to provide firstboot hooks which reuse the udeb postinst so that the same files on the installed system are touched as would have been touched during a normal installation. There will be some cases where additional changes need to be made (e.g. gdm locale configuration).

At first, firstboot may run in text mode as an implementation convenience, but it will need to be implemented in such a way that a graphical mode is possible in the future (perhaps for Breezy): this will almost certainly involve using debconf for all the hooks we provide. A graphical firstboot needs to start X as root with a simple session script that starts a window manager and the core of firstboot itself: fortunately, this happens to be similar to what is required to implement OEM test mode.

It may be necessary to reboot at the end of firstboot in order to pick up new configuration (notably the timezone). The authors of this specification hope that this can be avoided.

Data Preservation and Migration

N/A.

Packages Affected

Various installer packages. New OEM package. Various packages which copy configuration from the installer rather than referencing it at run-time.

User Interface Requirements

debconf GNOME frontend. May need to improve that for HIG etc. (If necessary, we can implement support for debconf plugins so we can write custom UI code.) See also PygtkDebconf.

Outstanding Issues

Should there be a way to return to firstboot afterwards?

If so, should we provide firstboot for all installations?

Not remotely implemented yet Smile :-)

UDU BOF Agenda

UDU Pre-Work

Comments and Suggestions

  • HileTuohela: Make it easy for OEMs to add custom packages to the CDs, maybe adding 'oem-package-generate' wrapper script or similar to generate the tree (like /dists/oem/breezy/<oemname>) and add it to automatically to the available packages lists

  • citizenDAK: Handle partially-completed "firstboot" or errors? For example, if some chunk of the firstboot is completed--user settings entered--then for some reason the machine's interrupted or rebooted... It'd be a hassle to force the user to re-enter everything. Can they pick up where they left off, or at least have the firstboot UI "remember" previous choices as the default selections. (Is this what "return to firstboot afterwards" means?)

Current Status

2005-05-19 ColinWatson: Bare firstboot framework prototype in place. Does nothing useful yet.

2005-06-09 ColinWatson: Ugly pure-debconf implementations of initial user configuration, timezone configuration, and keyboard configuration done. Support for including and excluding menu items. Force questions to act as if they're being reconfigured. Made a start on locale configuration.

UbuntuDownUnder/BOFs/OEMInstaller (last edited 2008-08-06 16:23:27 by localhost)