ImageBasedUpgrades
Introduction
With Ubuntu getting ported to more and more mobile devices, the standard update mechanism through apt and dpkg is starting to show some limitations.
As a result, Ubuntu is now looking at supporting an additional way of updating devices that are based on read-only images. For those devices, we're looking at doing image based updates, basically generating new images on the server side with the usual tools (debootstrap, apt, dpkg), then generate deltas between those images and have the client pull the delta and apply it without ever actually dealing with packages.
We don't intend this to become the only way to update Ubuntu machines, and the use of apt/dpkg will remain supported with most devices having some kind of switch to opt out of image based updates and re-enable apt.
In the initial implementation machines using image based updates won't be able to install extra packages from the archive as we're still discussing ways to support overlaying extra packages on top of the base system. However image based systems will be able to opt-out of image updates and switch to apt-based updates thereby allowing installing extra packages.
Blueprint: https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-image-based-updates
Launchpad project: https://launchpad.net/ubuntu-system-image
Here's a nice series of blog posts by community member Sturmflut, which provides lots of great details on how image based updates work behind the scenes.
Goals
- Get a common "Ubuntu base system" across as many devices as possible
- Update that base system through the image based system guaranteeing all devices are identical
- Do all the actual package installs server-side, reducing CPU/MEM load and update time on the devices
- Get a very clear split between system, apps and userdata, allowing for very simple data wipe
Features
The basic set of feature that we want to support on all devices using image based upgrades are:
- Read-only base Ubuntu system with separate read-write data storage
- Secure delivery of updates made of any number of files (allowing for split device-specific/device-independent bits)
- Ability to wipe all user data in one shot (factory reset)
- Flexible update policy working for daily builds just as well as monthly or even yearly updates
- Flexible update format, allowing for either delta based updates or full image (reformat + unpack)
- Same update mechanism for any kind of devices with the only bit actually changing being the upgrader code
- Per-device type procedure for factory initial flash (usually full device image)
Components
The server
The server stores all the updates and indexes used by the client to resolve the update path for a device. Details can be found in the server wiki page linked below.
The client
The client grabs the indexes from the server, does validation on those and then finds the best update path for the device, downloads the files and pass them to the upgrader. Details can be found in the client wiki page linked below.
The upgrader
The upgrader receives a list of updates from the client, validates them and applies them to the system. Details can be found in the upgrader wiki page linked below.
The downloader
The downloader is a daemon that exposes a DBus API that can be used to manage downloads (pause/resume/cancel) in an efficient manner. It provides features as internet throttling and Wifi only downloads.
Target
The current target for image based updates are Ubuntu Touch devices (phone and tablets) however the same design can easily be applied to any other device with only minimal changes to the upgrader component.
The server, client and upgrader wiki pages try to be target-agnostic and so generally refer to "system partition", "user data" and "upgrader partition". Where those actually sit will vary on devices and so is detailed in device/platform specific wiki pages linked below.
Details
As this is a rather complex topic, the various pieces have been split into individual pages:
Additionally some extensions are still under active discussion:
Test Plan
We have a test plan such as it is, which is used for silo landing tests, and as a basis for end-to-end QA testing. If you would like to contribute to the system image updates stack, please also take a look at the merge checklist.
We are also working on defining a testing server.
ImageBasedUpgrades (last edited 2015-05-07 13:27:29 by mail)