Improve aufs support in update-manager for karmic

Registered by Michael Vogt

In jaunty we started exploring how aufs can be used to test upgrades. For karmic this should go further to see if we can perform actual upgrades based on aufs that then sync back the writeable snapshot to the real filesystem (after upgrade or after the first boot). Performance of aufs is a issue (we need real numbers here too) and we need to talk about how a UI could look like if we want to give the user the option to test boot into a aufs upgraded system that has not been synced to the real system yet.

We need to fix in the process and how the free space calculation can be done. We still need to provide regular upgrades without aufs for e.g. the linux-image-server kernels (in hardy at least they do not have a aufs module).

Blueprint information

Not started
Colin Watson
Michael Vogt
Needs approval
Michael Vogt
Series goal:
Not started
Milestone target:

Related branches



2009-06-12: In light of recent developments to drop aufs...are we still considering this blueprint for Karmic? -robbie.w
2009-06-15: I think its still needed, but the title is of course very misleading now. It should be update-manager-what-snapshot-mechanism-to-use-for-karmic now :)
2009-06-15: We're getting mount --union in Karmic, perhaps it is the right replacement for aufs in this specification? - evand
2009-06-15: So is the plan to use UnionFS? I don't feel comfortable approving the spec without the "alternative way" decided first. -robbie.w
2009-06-15 cjwatson: I expect we'd need to support both in the code; since this is for upgrades, it's going to have to run on older kernels that won't have whatever new union-mount mechanism we come up with. I'd suggest an approach rather like casper, where it's capable of trying various union-mount mechanisms until it finds one that works?


Work Items

This blueprint contains Public information 
Everyone can see this information.