Improve aufs support in update-manager for karmic
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 https:/
Blueprint information
- Status:
- Not started
- Approver:
- Colin Watson
- Priority:
- Low
- Drafter:
- Michael Vogt
- Direction:
- Needs approval
- Assignee:
- Michael Vogt
- Definition:
- Review
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
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-
2009-06-15: We're getting mount --union in Karmic, perhaps it is the right replacement for aufs in this specification? http://
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?
