Update process for Ubuntu phones, tablets

Registered by Steve Langasek on 2013-03-01

For phones and tablets, it doesn't necessarily make sense to use apt to update the OS; a full-OS update may make more sense, for reasons including:
 - less bandwidth, CPU time used to swap in an image all at once vs. downloading packages one by one
 - more reliable rollback mechanism if current+prev OS images can be present side-by-side and switched between atomically

Following the initial install, users should be able to do an update to a new Ubuntu image without having to either apply updates individually with apt, or re-flash the device while tethered to a PC. Define how this should be implemented.

Blueprint information

Status:
Not started
Approver:
Steve Langasek
Priority:
High
Drafter:
Stéphane Graber
Direction:
Approved
Assignee:
Stéphane Graber
Definition:
Approved
Series goal:
Accepted for raring
Implementation:
Unknown
Milestone target:
milestone icon ubuntu-13.04-month-6

Related branches

Sprints

Whiteboard

* Let's just focus on system updates, ignore apps for now

* Factory reset
  * is system ROM ro or rw?
  * we will not have disk budget to keep a factory image around
  * even on desktop, we don't have this ability
  * for UX, we need a simple button push
  * overlays are COW
    * how about a filesystem that actually supports snapshotting (i.e. nilfs2)
      * it might be problematic to lock ourselves in features of this or that filesystem (but btrfs also came to mind)

Lack of inotify support is creating issues in overlay systems (bug 882147)

Android model?
update.zip is uploaded to cache partition; then reboots into recovery mode, verifies key, then checks base version is in allowed list, then updates by unzipping on top of system partition
-> does it do any cleanup of the previous files? otherwise you'd have stale files? is there a manifest of the old files? and complete checksums?

which base versions are supported? provide full update, then updates from this base version at least

builtin core apps?
actually unpacked on first boot on Android

ChromeOS model with Courgette? security model is different, filesystem is validated through a hierarchy of signatures

Current situation:
- running "apt-get update" on a phone takes lot of time/cpu

Can we transport in a single file updates to a filesystem driven by APT+dpkg?

Requirements:
- having 1 file that carriers can ship over air
- need reset factory setting
- need factory image OTA or deployed locally from a file
- need update images OTA or deployed locally from a file

if we have a base image RO that the user can't modify we can push updates for that, but
- what are the issues it creates
- how to let users install packages from the archive

How do we make the RO-base-image + package work

Options:
- only support apps in a new format (e.g deprecates apt packages)
- extend our packaging tools to support multiple data sources

There is going to be a separate discussions about third party apps

Issues with dpkg we want to go this way:
- dpkg "status" database: could be teach dpkg to look at 2 files? what happens if the base one changes baseos.status plus an "eveyrthing else".status, mirroring the partitioning layout?
  - not having to rewrite the main status database would significantly improve performance
- path filtering (look into existing --path-exclude/--path-include options)

We need to have a system that still allows installing softwares from the current archive for the convergence, at least until those packages are available in the new world
in principle an unionfs should work: we have a base OS + additional packages an user installed, the base OS should never be modified so the union is limited

Potential union/overlay fs solutions:
* aufs{1,2}
* unionfs
* overlayfs
* Union mounts (http://lwn.net/Articles/482779/)
* See also experiences at http://debathena.mit.edu/trac/ticket/463
* Device-mapper snapshots?
* Discussion at http://www.linux-kongress.org/2009/slides/state_union_mount_jan_blunck.pdf

Prototype to download and install an update file on a R/O filesystem; could implement with custom initrd mode or upstart jobs, then reboot R/O

Michael Frey, Loic Minier want to be in touch with Stephane on implementation

Initial plan: https://wiki.ubuntu.com/ImageBasedUpgrades/Mobile

A new blueprint for the 13.04 cycle is available at:
https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-image-based-updates

(?)

Work Items

Work items for ubuntu-13.04-month-5:
[stgraber] work on a detailed plan (keep lool, achiang, rsalveti, ChickenCutlass and the rest of Foundations in the loop): DONE
[stgraber] Kick off discussion on how to deal with user installed packages: DONE
[stgraber] Prototype server-side implementation scripts: DONE

Work items for ubuntu-13.04-month-6:
[stgraber] Prototype updater code: POSTPONED
[stgraber] Look into how our rootfs is currently managed and whether we need changes to ubuntu_chroot to allow using the images: POSTPONED
[stgraber] Prototype ClockWorkMod integration: POSTPONED
[stgraber] Initial integration on a nexus7 device: POSTPONED

Work items:
[stgraber] Look into dpkg's support of multiple status files (or multiple /var/lib/dpkg directories actually): POSTPONED
[vorlon] investigate unionfs options with the constrained requirements for a system like this: POSTPONED
[stgraber] Request security team review of HTTPS usage and general architecture (perhaps mandate cyphers or whitelist of CAs or private CA): POSTPONED
[stgraber] Add list of sensible optional parameters that can be added to the update request (either user-agent or as query parameters): POSTPONED