Discuss how to allow Ubuntu-based devices to receive full-image updates

Registered by Steve Langasek

Some devices that it's interesting to run Ubuntu on cannot do package-by-package updates for various reasons. Discuss what a solution looks like for implementing this with updating by way of swapping full OS images, various pitfalls associated with not running package maintainer scripts on upgrade, etc.

Blueprint information

Not started
Steve Langasek
Stéphane Graber
Oliver Grawert
Series goal:
Accepted for quantal
Not started
Milestone target:
milestone icon ubuntu-12.10-beta-1

Related branches



Pad: http://summit.ubuntu.com/uds-q/meeting/20820/foundations-q-image-based-updates/
Sessions notes:
Discuss how to allow Ubuntu-based devices to receive full-image updates
Use cases:
 - ARM boards
 - Over the air updates
 - LiveUSB disks with persistent sessions
 - OEM cases
 - Signed images for trusted bootloader/boot chain
 - Roll back to a previous working state
Full Image Updates
Issues with maintainer scripts
grub config hook to figure out which image to boot: "latest version that we've successfully tried", "new image that we've never tried", "tried this and it failed so now we ignore it"
/etc is traditionally writeable
  - Could bind-mount /etc to allow it to be writeable
  - Have to work out how to run maintainer scripts to reconcile admin changes to /etc with package updates
    - This is pretty tricky though, harms rollbackabiliity and makes the update process more fragile
  - Wil the target use cases want to change /etc/ at all?
    - Maybe, don't want to rule it out if possible
  - if the aim is to have signed rootfs then /etc should perhaps be included in that signature, meaning that it has to be read-only, making the point moot
- can use /home for some configs
- overlayfs could be used
  - tricky to update the underlay fs in this model
- have to have someone audit maintainer scripts to know if they will change /etc
- we don't know how many scripts there will actually be that will be problematic
Majority of use cases will be arm so they will not be using grub.
  - maybe use initramfs instead of bootload
    - need NVRAM place to store info to support that

Big use-case is Ubuntu TV
  - apparently they may want to use a proprietary bootloader
    - we can impose requirements on what they can do

kexec is not very reliable on ARM
Fedora's new /usr model that we are planning to enable this cycle may be an aid here
Do we have any non-OEM use cases?
  - could do it for Ubuntu-desktop
    - not sure we want to do it by default
  - may be desired by enterprises for more reliable upgrades

Alex: don't have to do everything at once, but improvements to make it easier for OEMs to do this would be very welcome
  - are there ways we could avoid using 3x the disk space to implement this?
  - find out what is doing things in /etc
    - Steve: audit current isn't the point, as if it's possible then it's a problem of what may happen in the future (during the lifespan of the rollout)
      - Tooling to make it easier to audit this'
Could start with a last-known-good type thing which doesn't allow for /etc/-editable
  - the way to do it, but it may not be very usable for people in that state
Chromium OS: http://www.chromium.org/chromium-os/chromiumos-design-docs/filesystem-autoupdate


Work Items

Work items:
[stgraber] test implementing the image-based swap for Ubuntu desktop (full image swap, not saving any data at this point): DONE
[stgraber] investigate support in the Wubi filesystem for separate /home (lp:~stgraber/+junk/image-setup): DONE
[vorlon] talk to ted in more detail: DONE
implement last-good-boot flag for ARM: POSTPONED
track the read-only-/usr progress in 12.10: POSTPONED

Dependency tree

* Blueprints in grey have been implemented.