LTSUpgrades
3066
Comment:
|
6188
|
Deletions are marked like this. | Additions are marked like this. |
Line 10: | Line 10: |
Ubuntu does currently support version to next version release upgrades. We do not support skipping versions. We will have to change this for LTS->LTS upgrades. | 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. |
Line 14: | Line 20: |
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). |
|
Line 15: | Line 26: |
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. |
|
Line 18: | Line 33: |
This spec affects update-manager. |
|
Line 19: | Line 36: |
=== 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 dappers 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-requists 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-requists 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/pycental 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 conf-file 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 subpressing theme-change signals |
|
Line 22: | Line 98: |
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. |
|
Line 24: | Line 110: |
== BoF agenda and discussion == | 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. |
Line 26: | Line 114: |
* xserver changes (dapper->edgy: xserver-xorg-video-all must be hinted to install) -> envy breaks, due to some broken diversions * python/pycental transition (python2.4-foo -> python-foo) * many file-overwrite problems and conf-file questions * UUID change (looks good, except grub, check for the swap partition mkswap changes the UUID - most likely that is something that is not happening during a upgrade but happening during boot, most likely hibernation) * pata->sata (mostly good, only cdroms left as problematic device) |
The CDROM upgrade may require manual hinting for the upgrade calculation (this needs to be tested). |
Line 35: | Line 117: |
* "breaks" support in dpkg, needs to be solved via the pre-requisites * upgrader: pre-requisites support+maintainer script failure protection |
== Future == |
Line 38: | Line 119: |
* xubuntu upgrade problem: theme crashes, not xubuntu specific -> system state changes under our feet -> firefox is another example |
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. |
Line 42: | Line 125: |
* try to detect automatix, envy and refuse upgrade in this case (e.g. look into dpkg database and see if it was ever installed) * trying as hard as possible to detect if the system was altered in some way that may cause breakage during the upgrade |
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: |
Line 47: | Line 131: |
* Pre-requisites essential | * 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 |
Line 49: | Line 138: |
* finding a way to make a upgrade testable (unionfs overlay, we have two options): 1) test if the packages will upgrade cleanly 2) test if the HW is working afterwards (including e.g. grub) |
The dm-snapshot documentation is available at: http://lxr.linux.no/source/Documentation/device-mapper/snapshot.txt |
Line 54: | Line 141: |
* there are two options for the test: - run the test in a virtual machine: - reboot into special test-mode - create dm COW for the upgrade tester - run script 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 - run it in a unionfs - run it with dm-setup: - Create a big backing store file on the FS for a COW file - make it a blockdevice with loopback - make a special initramfs that will do the requierd setup - add option to grub menu "upgrade test" - boot into it and start up and run a upgrade - (future: having a option for commit the upgrade would be nifty) dm-snapshot documentation: http://lxr.linux.no/source/Documentation/device-mapper/snapshot.txt (also in 2.6.15) and its avaiable in dapper! |
All the required features are available in dappers 2.6.15 kernel. |
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 dappers 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-requists 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-requists 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/pycental 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 conf-file 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 subpressing 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 dappers 2.6.15 kernel.
LTSUpgrades (last edited 2008-08-06 16:34:57 by localhost)