Discuss how to allow Ubuntu-based devices to receive full-image updates
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:
-
ubuntu-12.10-beta-1
- Started by
- Completed by
Whiteboard
Pad: http://
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://
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.
