LTSUpgrades (dapper->hardy)

This used the to "LTSUpgrades" and is kept for reference. The new LTSUpgrades contains infomration about the hardy->hardy+1 LTS upgrade.


This spec describes what is required to implement LTS to LTS upgrades and some of the high level problems that need to be overcome for it.

Release Note

This makes it possible to do release upgrades from one long-term support release to the next in one step.


Our LTS releases are supported for 3 years on the desktop and 5 on the server. This means that with the regular upgrades (that can't skip versions) the user will have to perform up a lot of them (and waste a lot of time/bandwidth).

Use Cases

Anne is using dapper on her desktop and she does not intend to upgrade to any other version than a LTS. When the new LTS comes out she gets a button telling her about the new LTS release and she happily upgrades.


This spec affects update-manager.



The update-manager in dapper needs to be changed so that it looks into a new "meta-release-lts" file on the server for new distro versions instead of the current "meta-release" file. Looking into that file should be the default. The changes required on dapper's u-m are minimal and need to be pushed via a SRU.

For the server upgrade we need to upload a new "update-manager-core" package to dapper-updates. This is similar to what had to be done for the edgy->feisty server upgrade.


The release upgrader must be modified so that it supports two different upgrade configurations. One to upgrade from the last regular release to the new LTS and one to upgrade from the last LTS to the current LTS.

The release upgrader then fetches its pre-requisites from the net to calculate/perform the upgrade.

The various "quirks" handlers need to be evaluated to see which apply for dapper->LTS+1 as well and need to be reused.

Try to detect third party tools that may cause problems and refuse upgrade in this case (e.g. look into dpkg database and see if it was ever installed). This requires additional testing and research for common third party tools.

A menu item for friendly-recover will be added that can continue broken upgrades. It will be based on the text frontend of the release upgrader and make it possible to complete a upgrade even when X is in a bad state (also this should be less of a issue with bulletproof X now).

CDROM upgrades

The pre-requisites for the upgrade need to go onto the CD. Build once for the previous LTS (e.g. dapper) and once for the previous regular version (e.g. gutsy). The upgrader needs to figure which one to use.


Additional automatic testing using a virtual machine should be performed to test this upgrade very thoroughly. The new test-backend based on qemu/kvm (in development) for the AutomaticUpgradeTesting should be used to catch errors like failing daemons and to perform additional tests like if the X server comes up again or if the new kernel gets booted etc.

Potential problems

There are some changes that may cause problems for the LTS upgrade:


The release upgrader will be modified so that it can read two different configuration files depending on what release the upgrade is started from.

Test/Demo Plan

Install the updated update-manager on dapper (best is a VM) and run it with --lts-upgrade and --check and a "Upgrade" button should appear. Press that button and follow the on-screen instructions.

Outstanding Issues

The CDROM upgrade may require manual hinting for the upgrade calculation (this needs to be tested). There are various issues that may come up, one is that the amount of translation package available on the CD may have changed, the other is that the CD may lack transitional packages. Generally the upgrade will be refused if translations would have to be removed in order to calculate the upgrade. This should be relaxed to a question asked to the user if he wants to continue.

The switch from Edubuntu to two CDs requires changes as well. If update-manager detects a installed edubuntu-desktop system, it will ask the user for the (optional) addon CD. If no CD is inserted, it will fallback to the network. This needs to be tested.


Finding a way to test the upgrade in a fully revertable way would offer us a great many more testers. It should be investigated if it is feasible to implement a test-mode. With a test-mode like this it would be possible to find out in advance if all packages upgrade cleanly and if not to send a problem report.

A possible way to do this is a qemu/kvm based upgrade. It would require booting into a special test-mode where the main filesystem is mounted ro and a device-mapper COW device is created over the real root filesystem that is used for the upgrade test. The following steps are required:

The dm-snapshot documentation is available at:

All the required features are available in dapper's 2.6.15 kernel.


LTSUpgradesDapperHardy (last edited 2008-08-06 16:26:28 by localhost)