LTSUpgradesDapperHardy

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.

  • Launchpad Entry: lts-upgrades

  • Packages affected: update-manager

Summary

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.

Rationale

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.

Scope

This spec affects update-manager.

Design

Notification

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.

Release-upgrader

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.

Testing

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:

  • xserver package name changes (dapper->edgy): We can work around this with hinting to ensure that xserver-xorg-video-all is installed.

  • check if envy is used by dapper users and if that may cause breakage
  • python/pycentral transition (python2.4-foo -> python-foo): this may require manual hinting

  • UUID change: looks good, some problems with grub, but that is not a problem with the upgrades but a general problem with grub
  • pata->sata transition: this looks mostly good, only cdroms left as problematic device and the edgy->feisty quirks code deals with it already.

  • "breaks" support in dpkg: this needs to be solved via the pre-requisites mechanism
  • better protection/recovery when maintainer scripts fail: on a desktop install we will continue with the upgrade even if we have dpkg giving us errors (the default behavior for apt is to stop on the first dpkg error). The reason for continuing is that as much as possible should be unpacked/configured, otherwise we may end up with a system without e.g. initramfs
  • initial tests show many file-overwrite problems and conffile questions that we need to find with automatic tests
  • xubuntu upgrade problem: when the theme changes, it crashes. This needs to be investigated. A possible solution is suppressing theme-change signals
  • X dies/restarts during the upgrade. I have seen this in some logs and it would be good if we could protect against it.

Implementation

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.

Future

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:

  • reboot into special test-mode
  • create dm COW for the upgrade tester
  • run script in COW target that will modify /etc/X11/xorg.conf to use "vesa" and modify /etc/fstab so that "/" is mounted from "/dev/hda" (and possibly other FS mount points have to change too)
  • run qemu/kvm with that COW as rootfs and run the upgrade test in it
  • when it finished, reboot again into the real system
  • copy the upgrade logs from the COW device

The dm-snapshot documentation is available at: http://lxr.linux.no/source/Documentation/device-mapper/snapshot.txt

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


CategorySpec

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