OEMInstaller

Revision 10 as of 2005-04-25 05:20:06

Clear message

Title

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.)

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