Launchpad Entry: offline-installer
Created: 2008-11-21
Contributors: Emmet Hikory, Michael Casadevall, Oliver Grawert
Packages affected:
Summary
Some systems cannot effectively boot off remote devices (e.g. USB, optical drive), and may only have facilities for a single block device to be installed. For these systems, there would be advantage to being able to run an offline tool to install a system to a secondary disk on a running system or to an image file. In some cases, the running system may not match the target architecture, and so an optimal solution would be able to construct an installed system in an architecture-neutral way, perhaps based on a live image.
Release Note
Ubuntu now provides a facility to construct runtime images for embedded systems and other environments in which the install is performed on separate hardware than will run the installed image.
Rationale
Some hardware is unable to boot off USB or CDROM or really anything else. One needs to prepare an installed image, and then run it on the target hardware. Currently, installation of Ubuntu on such devices involves complex machinations involving constructing a target image, mounting that, and using it as a debootstrap target. Further, this only works on roughly compatible architectures (e.g. amd64 can create amd64, i386, and lpia targets).
Use Cases
- Alice has a NAS device on which she wishes to install Ubuntu. It can only boot from ROM or from an inserted hard drive. Alice uses the offline installer to install Ubuntu Server armel on the hard drive from her i386 system, inserts the drive into the NAS device, and it boots cleanly.
- Bob has an MID device on which he wishes to install Ubuntu MID. It can only boot from internal NAND, which can be loaded over a serial cable. Bob uses the offline installer to install Ubuntu MID lpia into a loopback image, and then sends that image over the serial cable to his MID, and it boots cleanly.
- Chris works at a computer reseller, providing computers with Ubuntu preinstalled. Chris runs the offline installer on his primary computer against a SATA drive attached via USB cable, and inserts it into each built machine before sale.
Assumptions
- Given the content of a filesystem.squashfs from a live image, the remainder of an installation can be done in an architecture-neutral fashion.
- Users with configurations that require this tool will have known means to get the results working on the target hardware.
Design
Process currently used by ubiquity
- unionfs is copied to target
- configuration adjusted based on debconf settings
- unwanted packages removed
Proposed Process to be used by this tool
- Run oem-config for debconf preseeding
- Run partman to parition the disk
- Copy the unionfs live image into the target
- Remove unwanted packages like casper from the install
- Install any other desired packages on the fly
Images types
- Input: Live Image (vfat/iso9660)
- Output: Some image suitable for installation
Implementation
During UDS, it was brought up that we should look at how emDebian handles package additions and removals. The upshot is that they aren't handled at all, and relay on the target hardware able to reinstall dpkg packages once the base system is fully set up: http://wiki.debian.org/EmDebian/CrossDebootstrap
- qemu supports most Ubuntu architectures, and allows one to execute maintainer scripts in a target environment, albeit slowlt. When performing debootstrap --second-stage or installing additional custom components, the offline installer tool will use a noninteractive qemu to prepare the target image.
UI Changes
The following mock UIs were created for what this tool would be like:
Main window
----------------------------------------------------------- | ------------------------------- | ||Image Selector | | |-------------------------------- | |---------------------------------------------------------| |-------- -------------------------------- | ||Output Format| |Advanced Partitioning | | |-------- -------------------------------- | |---------------------------------------------------------| |-------------------------------- | ||Select Kernel and Initramfs | | |-------------------------------- | |---------------------------------------------------------| || Load Config | Save Config | | DoIT! | -----------------------------------------------------------
Image selection and target FS type
----------------------------------------------------------- | Image | Size | Type | Mountpoint | |---------------------------------------------------------| | ... | .... | ext3 | / | | | | | | |---------------------------------------------------------| | | Add | Remove | Binary Blob | Cancel | Ok | -----------------------------------------------------------
Possible Options
- Which Image
- What output format
- Add binary blob
- Select Kernel
- Add packages
- Select Initramfs
Code Changes
As this is a new tool, it will have to be written from scratch.
Migration
No migration is required: this is a new procedure for new installs, and user data is not expected to be preserved.
Test/Demo Plan
It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release.
This need not be added or completed until the specification is nearing beta.
Unresolved issues
BoF agenda and discussion
Original Gobby Doc
The goal of this spec is to put together the rough design for an offline installer
Many devices can only boot of a single storage device, you are not able to run an installer from external device to install to an internal device since only one device exists and is bootable, a tool to dump a completely configured filesystem on such a storage devcie is needed
Using a live image already gets you a fully installed system but with the addition of ubiquity
For the arm architecture it was decided to build kernel less images, this would enable us to actually have the cleaned up image in place for just dumping it to a disk
Questions
- what if we need a different target filesystem to the one used on the image
- you might need to have to dump a binary blob to the beginning of the image
- to make it boottable
Process currently used by ubiquity
- copy unionfs contents of the running live system
- adjust configuration based on debconf settings on the target system
- remove unwanted packages
Proposed process to be used by the tool
- run oem-config for debconf preseeding
- run partman partitioning
- copy unionfs contents of a loopmounted livefs into the target
- unresolved issues:
- remove unwanted packages (how to be done in a cross arch chroot)
- install additional packages
Image types
- Input: Live Image (vfat/iso9660)
- Output: Some Image (selectable format)
Gui consideration
Main window
----------------------------------------------------------- | ------------------------------- | ||Image Selector | | |-------------------------------- | |---------------------------------------------------------| |-------- -------------------------------- | ||Output Format| |Advanced Partitioning | | |-------- -------------------------------- | |---------------------------------------------------------| |-------------------------------- | ||Select Kernel and Initramfs | | |-------------------------------- | |---------------------------------------------------------| || Load Config | Save Config | | DoIT! | -----------------------------------------------------------
Image selection and target FS type
----------------------------------------------------------- | Image | Size | Type | Mountpoint | |---------------------------------------------------------| | ... | .... | ext3 | / | | | | | | |---------------------------------------------------------| | | Add | Remove | Binary Blob | Cancel | Ok | -----------------------------------------------------------
Possible Options
- Which Image
- What output format
- Add binary blob
- Select Kernel
- Add packages
- Select Initramfs