LTSUpgrades
|
Size: 5971
Comment:
|
← Revision 14 as of 2008-08-06 16:34:57 ⇥
Size: 4726
Comment: converted to 1.6 markup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| * '''Launchpad Entry''': https://blueprints.launchpad.net/ubuntu/+spec/lts-upgrades | * '''Launchpad Entry''': UbuntuSpec:hardy-lts-upgrades |
| Line 10: | Line 10: |
| This spec describes what is required to implement LTS to LTS upgrades | This spec describes what is required to implement 8.04 LTS to LTS+1 upgrades |
| Line 27: | Line 27: |
| Anne is using dapper on her desktop and she does not intend to upgrade | Anne is using hardy on her desktop and she does not intend to upgrade |
| Line 37: | Line 37: |
| === Python problems === The changes in the python policy are challenging for the upgrader because it is written in python. The new policy allows only packages called "python-foo" that then contain the binary libs build against the currently supported python versions. The python-apt package currently contains: {{{ /usr/lib/python2.5/site-packages/apt_pkg.so /usr/lib/python2.4/site-packages/apt_pkg.so }}} The old policy had packages for each python version (e.g. python2.4-apt). This means that during the upgrade from hardy that uses python2.5 by default some binary libs may go away because the python packages get upgraded and do no longer contain the libs for python2.5. Examples are python-apt, python-gtk, python-vte and python-qt3. There are some ways around the problem, no one is very elegant: * provide debs/udebs with the required libs and install them into location that the upgrader is unpacked. The disadvantage is that those need to go onto the alternative CD too * rewrite the upgrader in C++ where propper shared libraries are available * copy the required python libs into the upgrader place (how to find the information?) * perform the upgrade from a special chroot environment and/or boot into special upgrade mode and/or provide a upgrade mode on the live-cd so that we have a stable environment while performing the upgrade |
|
| Line 39: | Line 63: |
| 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. |
The update-manager in hardy has a configuration file /etc/update-manager/release-upgrades that can be used to specify what upgrade options are displayed. It defaults to "lts" upgrades only and can be changed with the gnome-software-properties tool. |
| Line 51: | Line 67: |
| 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 supports two different upgrade configurations. If DistUpgrade.cfg.$fromDist is present, that will be used instead of the regular DistUpgrade.cfg. This means that a additional DistUpgrade.cfg.hardy needs to be created. If backports of apt/dpkg/python-apt are required we can use prereq.hardy.list. |
| Line 56: | Line 73: |
| The release upgrader then fetches its pre-requists from the net to calculate/perform the upgrade. |
=== CDROM upgrades === |
| Line 59: | Line 75: |
| The various "quirks" handlers need to be evaluated to see which apply for dapper->LTS+1 as well and need to be reused. |
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. |
| Line 62: | Line 77: |
| 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. === 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). |
|
| Line 137: | Line 93: |
| * 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) |
* 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) |
| Line 148: | Line 102: |
| All the required features are available in dappers 2.6.15 kernel. | All the required features are available in dapper's 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: hardy-lts-upgrades
Packages affected: update-manager
Summary
This spec describes what is required to implement 8.04 LTS to LTS+1 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 hardy 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
Python problems
The changes in the python policy are challenging for the upgrader because it is written in python. The new policy allows only packages called "python-foo" that then contain the binary libs build against the currently supported python versions. The python-apt package currently contains:
/usr/lib/python2.5/site-packages/apt_pkg.so /usr/lib/python2.4/site-packages/apt_pkg.so
The old policy had packages for each python version (e.g. python2.4-apt). This means that during the upgrade from hardy that uses python2.5 by default some binary libs may go away because the python packages get upgraded and do no longer contain the libs for python2.5. Examples are python-apt, python-gtk, python-vte and python-qt3.
There are some ways around the problem, no one is very elegant:
- provide debs/udebs with the required libs and install them into location that the upgrader is unpacked. The disadvantage is that those need to go onto the alternative CD too
- rewrite the upgrader in C++ where propper shared libraries are available
- copy the required python libs into the upgrader place (how to find the information?)
- perform the upgrade from a special chroot environment and/or boot into special upgrade mode and/or provide a upgrade mode on the live-cd so that we have a stable environment while performing the upgrade
Notification
The update-manager in hardy has a configuration file /etc/update-manager/release-upgrades that can be used to specify what upgrade options are displayed. It defaults to "lts" upgrades only and can be changed with the gnome-software-properties tool.
Release-upgrader
The release upgrader supports two different upgrade configurations. If DistUpgrade.cfg.$fromDist is present, that will be used instead of the regular DistUpgrade.cfg. This means that a additional DistUpgrade.cfg.hardy needs to be created. If backports of apt/dpkg/python-apt are required we can use prereq.hardy.list.
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.
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.
LTSUpgrades (last edited 2008-08-06 16:34:57 by localhost)