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

Status:
Not started
Approver:
Steve Langasek
Priority:
Medium
Drafter:
Stéphane Graber
Direction:
Approved
Assignee:
Oliver Grawert
Definition:
Approved
Series goal:
Accepted for quantal
Implementation:
Not started
Milestone target:
milestone icon ubuntu-12.10-beta-1

Related branches

Sprints

Whiteboard

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.