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.


We provide a nice and consistant way to upgrade a desktop system with the ReleaseUpgrader. This tool ensures a clean upgrade. It is currently limited to the desktop and requires a running X. We want to provide a text based frontend too.


Sometimes we need to make changes to the system that goes beyond just upgrading packages or we need to work around problems. We have a consistent framework for this with the ReleaseUpgrader and just provide different frontends. One of these frontends should be a text based verison for server upgrades.

Use cases

  1. Fed is running ubuntu on his DNS server and wants to perform a upgrade. Because he is not that experienced he prefers to use the ReleaseUpgrader to guide him through the upgrade.

  2. Bob is a experienced sysadmin who administrates a lot of machines. He wants a tool that can automatically upgrade his systems with as little user-interaction as possible. The uses the ReleaseUpgrader to do the upgrade because it is what he needs.


We need to add a text based frontend for the ReleaseUpgrader. There needs to be commandline options to overwrite the frontend and the default configuration. For the server upgrade the rules are a bit different than for a desktop upgrade because e.g. we do not want to enforce certain meta packages (like we do with {ubuntu,kubuntu,edubuntu,xubuntu}-desktop on the desktop). A server specific removal blacklist will be added to ensure that certain packages that were installed can not be removed during the upgrade without aborting with a error. These packages include bind9, samba, apache2, mysql-server, postgres.


The current ReleaseUpgrader will be used and a new frontend will be added. The configuration for the server upgrades needs to be slightly different than for desktop upgrades because we won't automatically install packages like "ubuntu-minimal" or "ubuntu-standard" if those are missing and it won't comment out 3rd party packages (because we trust the admin to makes this kind of decisions carefully). We will take care of task changes though. To do this, we check for the tasks on the system if they are completely installed. If so, we check if they have changed in the new release and add any missing packages.

In order to protect against network failure we need to make sure that a upgrade will continue even if the frontend goes away. We will use the same approach that is used in the new ReleaseUpgrader and run frontend and backend in different process spaces. This way, even if the network goes away the admin can reconnect to the machine and re-attach to the running upgrade process.

In order to better protect against network failures we may ask at the start of the upgrade to start a ssh process on a different port so that if something goes very wrong, there is still a ssh server to connect to.

It should be possible to record/replay all decisions (including conffile questions with the md5 of the modified and the new conffile) made during the upgrade to replay them on the next upgrade to make it easier to do mass upgrades.


The implementation will be done as a new interface to the ReleaseUpgrade that is part of the update-manager package.


The current status is:

  • Text frontend added to the dist-upgrader
  • selection of --frontend possible
  • task checking
  • new --mode=server switch to the upgrader
  • offer to start a new ssh
  • mechanism to download/start the upgrader needs to go to edgy-proposed: update-manager-core contains do-release-upgrade


  • backport update-manager-core to edgy


  • record/replay [may not make it for feisty]
  • Protection against network failures + reattach [waits for the gui-seperation branch to be merged]


ServerUpgradeTool (last edited 2008-08-06 16:20:56 by localhost)