DistUpgradeProcessImprovements

Differences between revisions 8 and 9
Revision 8 as of 2006-10-31 15:45:22
Size: 4043
Editor: p54A67899
Comment:
Revision 9 as of 2006-10-31 15:58:53
Size: 4046
Editor: 195
Comment: Fix typos
Deletions are marked like this. Additions are marked like this.
Line 25: Line 25:
There are various ways to attack the problem. One is AutomaticUpgradeTesting to find errors early and automatically. Next we need to make sure that packages/postinst scripts with errors can not trash the system (to the extend that this is possible). A option to test/roll-back a upgrade would be good as well, but this is technically very challenging. There are various ways to attack the problem. One is AutomaticUpgradeTesting to find errors early and automatically. Next we need to make sure that packages/postinst scripts with errors can not trash the system (to the extent that this is possible). An option to test/roll-back an upgrade would be good as well, but this is technically very challenging.
Line 44: Line 44:
Another sources of problems were the changes in the environment during the upgrade itself. Those are the hardest to protect against. If e.g. the theme engine becomes suddently broken for a certain amount of time, this can causes crashes in the upgrader during the process. Another source of problems were the changes in the environment during the upgrade itself. Those are the hardest to protect against. If e.g. the theme engine becomes suddenly broken for a certain amount of time, this can causes crashes in the upgrader during the process.
Line 49: Line 49:
 1. Should probably mention that using `apt-get dist-upgrade` will calculate a upgrade but that this upgrade will most likely not a good one because e.g. ubuntu-desktop can't be upgraded.
 1. Find as much postinst problems as possible with automatic testing. If we still have failing postinsts then those should be logged as problems but libapt should try to continue as long as possible
 1. Should probably mention that using `apt-get dist-upgrade` will calculate a upgrade but that this upgrade will most likely not be a good one because e.g. ubuntu-desktop can't be upgraded.
 1. Find as many postinst problems as possible with automatic testing. If we still have failing postinsts then those should be logged as problems but libapt should try to continue as long as possible

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

The upgrade experience from dapper->edgy was not good for a lot of people. This spec tries to identify what caused the problems and what we can do to fix them.

Rationale

Currently there are situations that can make the dist-upgrade fail. In the worst case, this means that the system becomes unbootable or that X won't start. We need to make sure that even when errors happen during the upgrade the system is still bootable and X will still work.

Use cases

1. Alice heard that ubuntu is a great distro. She runs a script in the forums that automatically installs multimedia stuff. When she upgrade later a problem caused by that script makes the system unstable and she is disappointed by ubuntu and the upgrade process.

2. Bob has installed some python modules manually. When he upgrades a python package postinst fails because of this and the upgrade is not fully completted. He decides to try a different distro because of that.

Scope

There are various ways to attack the problem. One is AutomaticUpgradeTesting to find errors early and automatically. Next we need to make sure that packages/postinst scripts with errors can not trash the system (to the extent that this is possible). An option to test/roll-back an upgrade would be good as well, but this is technically very challenging.

Analysing the problem

The following problems have been observed during the dapper->edgy upgrade:

  1. upgrade could not be calculated (e.g. with unofficial compiz: #58424)
  2. {pre,post}inst failures (e.g. firestarter, python-$foo: #56779, #59932, #64615, #67913, #67996, #68378, #69019, #69104, #59347, #63450, #66347, #67368, #67559, #67696,#68177,#68765)
  3. X didn't came up (#67069)
  4. kernel wouldn't boot (#68848)
  5. upgrader crashes because of environment changes (e.g. theme changes: #68027, #69124)
  6. upgrader crahes because of programming errors (#68553)
  7. system behaves differently in a fundamental way after the upgrade (#69145,#69059,#69208,#67803)
  8. misc problems that makes the upgrade difficult (#69051, #68467, #67090)

Here is a list with all the identified upgrade bugs so far:BR https://launchpad.net/distros/ubuntu/+bugs?field.tag=edgy-upgrade

The data we have so far indicates that most of the problems are caused by failures in maintainer scripts. This means that apt/update-manager needs to better prepared for those and should try to ignore these errors as much as possible.

Another source of problems were the changes in the environment during the upgrade itself. Those are the hardest to protect against. If e.g. the theme engine becomes suddenly broken for a certain amount of time, this can causes crashes in the upgrader during the process.

Design

The above mentioned problems should be attacked by the following means:

  1. Should probably mention that using apt-get dist-upgrade will calculate a upgrade but that this upgrade will most likely not be a good one because e.g. ubuntu-desktop can't be upgraded.

  2. Find as many postinst problems as possible with automatic testing. If we still have failing postinsts then those should be logged as problems but libapt should try to continue as long as possible
  3. We should spend time to have a recovery mode (vesa/vga) in X
  4. ?
  5. We should probably force the upgrader to change itself to a theme that we have tested (human)
  6. ?
  7. ?
  8. ?

Implementation

Code

Data preservation and migration

Unresolved issues

BoF agenda and discussion


CategorySpec

DistUpgradeProcessImprovements (last edited 2008-08-06 16:36:24 by localhost)