LTSUpgrades
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.
Launchpad Entry: https://blueprints.launchpad.net/ubuntu/+spec/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.
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 bootet 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
- 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
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
A LTS upgrader for Kubuntu is going to be difficult as it requires more backported components like kdelibs, kdebase and konsole to make the build-in terminal window work.
The CDROM upgrade may require manual hinting for the upgrade calculation (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.