OEM Installer
Status
Created: 2005-04-23 by MattZimmerman
Priority: HighPriority
People: ColinWatsonLead, TollefFogHeenSecond
Contributors: MattZimmerman
Interested: AndrewFitzsimon, JeffBailey, HileTuohela
Status: ApprovedSpecification, BreezyGoal, DistroSpecification
Branch:
Malone Bug:
Packages:
Depends:
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 
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?)
ColinWatson: Yes, this is trivial; since we're using debconf as the backend, it basically just works that way anyway. At the moment I'm deliberately resetting the seen flag to make sure that questions are always re-asked, but the previous selections will still be the defaults.
windex: I own a small consulting company and I'm looking at diffrent distributions for business desktop linux, having OEM-style automatic installation would be very important to me to be able to deploy ubuntu in any quantity at client sites. Being completely green to ubuntu, but well versed with debian, I think I can help with getting this rolling, I've got about 6 years of linux-based C development behind me, mostly for internal projects. I'm not sure who to talk to, or if help is even needed in this capacity. Please email me if I can be of assistance!
thelonecabbage: I think that a huge advantage to an OEM distro would be the ability for the user to request remote tech support from his retailer (or authorized service agent). Vino does a great job of desktop sharing but is worthless if a fire wall is left in place, does really weak authentication, no encryption, and leaves it up for the clueless user to notify the tech of his/her IP address. Adding an stunnel type package where the user dials out to a predefined URL/Certificate and using client & server side certs, would make it much easier for OEM's to assist their clients, at a lower cost. In addition to installing a few software packages it would also require the ability for the OEM to install his personal certificate and assign a unique key to the user. (possibly a network fetch, to a local server, during install) Essentially an SSL secured root kit.
- DecIRC : With OEM distro, it should be easy to preconfigure some hardware too (on a laptop for instance, in the use of ndiswrapper is needed, it could be useful if the seller can preconfigure it. Same way if the seller want to add support for mp3, dvd, divx, in countries where it is not outlaw to do it...
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.
2005-07-20 ColinWatson: pygtk interface (using a neat little debconf filter) mostly done, although not very pretty yet. Keyboard configuration still needs to be done in this interface.
2005-07-26 ColinWatson: oem-config-dm written; it's now a one-liner to do (a) OEM test mode and (b) the line for /etc/inittab to launch oem-config with an X server.
2005-08-09 ColinWatson: Fixed various bugs in locale and keyboard configuration.