CDRomBasedUpgradesSpec

Differences between revisions 2 and 3
Revision 2 as of 2006-06-09 17:17:43
Size: 1536
Editor: 88-136-149-244
Comment:
Revision 3 as of 2006-06-19 17:17:10
Size: 4479
Editor: ALagny-109-1-2-23
Comment: session results in paris
Deletions are marked like this. Additions are marked like this.
Line 18: Line 18:
* John has only got a slow dial up connection (modem) to the internet. Upgrading to dapper would require him to download around an half gbyte of packages - this would take about 20 hours of downloading. He would benefit by a descreased download size.

* Maria does very security critcal work on her computer. So she decided to not connect it to the internet at all. All packages for an upgrade have to be provided on a cd or usb stick.
Line 19: Line 23:

The dist-upgrader code (part of the update-manager bzr) is affected by this spec.
Line 22: Line 28:
== Problems ==

 * The main problem are custom repositories and packages that are installed from the universe or multiverse components. So a single CD with only main won't be sufficient in the most cases. A possible solution for Ubuntu packages could be a custom created CD that would contain all required packages to upgrade the corresponding system. Another option would be to just use a DVD version only - including all Ubuntu components. Alternatively the alternate cd/dvd could be used as a base for the upgrade, so the download size could be decreased.

 * A second problem is the automatic detection of the upgrade cd/dvd. The dist-upgrader tool is on the medium and has to be started. This could be done by a hal hook, which could detect update mediums.

 * Thirdly bugs in the dist-upgrader cannot be fixed easily or at all if it's on the medium. Generally it is the same situtaion as for the installer on the desktop/live cd.
 
Line 23: Line 37:

The CD needs to contain some meta-information like what version it is, what it can upgrade and the actual code to do the upgrade (similar to the meta-release file on http://changelogs.ubuntu.com/meta-release). The tools should basicly do the same things as the "normal" dist-upgrader.

The difference between the "normal" dist-upgrader should probably be that it asks if it should use the network (if there are any network sources in the sources.list) and that it should warn about the fact that for network usage a lot of packages need to be installed. If no network is available the sources.list should still be rewritten, but no "cache.update()" should be run. We need to make sure that the cdrom source is disabled/removed if the user cancels the upgrade otherwiese the user will see scary messages from update-manager about updates on the CD. The user should be able to cancel if the download for him is too much.

We may consider hooking this with some simple "generate a download wget script" button for the download to do the actuall package download on a offline site. It might be worth consider to have a "start downloading" option that starts and stores the packages to continue later.

The update-notifer code to detect Ubuntu CDs should be reused for the detection.

The dist-upgrader should by all means check if there is a updated version on the network if there is network available (to make it possible to fix bugs after release too).

Summary

The dist-upgrader that was introduced for breezy->dapper upgrades relies heavily on being on a (fast) network. A process for (dist)upgrades without network should be added as well.

Rationale

Not everyone has broadband network or cheap internet. We need to find a way to support dist-upgrades (perferable via the dist-ugprader mechanism) via cdroms.

Use cases

* John has only got a slow dial up connection (modem) to the internet. Upgrading to dapper would require him to download around an half gbyte of packages - this would take about 20 hours of downloading. He would benefit by a descreased download size.

* Maria does very security critcal work on her computer. So she decided to not connect it to the internet at all. All packages for an upgrade have to be provided on a cd or usb stick.

Scope

The dist-upgrader code (part of the update-manager bzr) is affected by this spec.

It should both support the case when the machine is not networked at all or when the network is avialable but slow and expensive.

Problems

  • The main problem are custom repositories and packages that are installed from the universe or multiverse components. So a single CD with only main won't be sufficient in the most cases. A possible solution for Ubuntu packages could be a custom created CD that would contain all required packages to upgrade the corresponding system. Another option would be to just use a DVD version only - including all Ubuntu components. Alternatively the alternate cd/dvd could be used as a base for the upgrade, so the download size could be decreased.
  • A second problem is the automatic detection of the upgrade cd/dvd. The dist-upgrader tool is on the medium and has to be started. This could be done by a hal hook, which could detect update mediums.
  • Thirdly bugs in the dist-upgrader cannot be fixed easily or at all if it's on the medium. Generally it is the same situtaion as for the installer on the desktop/live cd.

Design

The CD needs to contain some meta-information like what version it is, what it can upgrade and the actual code to do the upgrade (similar to the meta-release file on http://changelogs.ubuntu.com/meta-release). The tools should basicly do the same things as the "normal" dist-upgrader.

The difference between the "normal" dist-upgrader should probably be that it asks if it should use the network (if there are any network sources in the sources.list) and that it should warn about the fact that for network usage a lot of packages need to be installed. If no network is available the sources.list should still be rewritten, but no "cache.update()" should be run. We need to make sure that the cdrom source is disabled/removed if the user cancels the upgrade otherwiese the user will see scary messages from update-manager about updates on the CD. The user should be able to cancel if the download for him is too much.

We may consider hooking this with some simple "generate a download wget script" button for the download to do the actuall package download on a offline site. It might be worth consider to have a "start downloading" option that starts and stores the packages to continue later.

The update-notifer code to detect Ubuntu CDs should be reused for the detection.

The dist-upgrader should by all means check if there is a updated version on the network if there is network available (to make it possible to fix bugs after release too).

Implementation

Code

Data preservation and migration

Outstanding issues

BoF agenda and discussion

Julien Hémono - Isn't it done by the alternate CD ? : {{{Alternate install CD

The alternate install CD allows you to perform certain specialist installations of Ubuntu. It provides for the following situations:

  • creating pre-configured OEM systems;
  • setting up automated deployments;

    ---> * upgrading from older installations without network access;

  • LVM and/or RAID partitioning;
  • installing GRUB to a location other than the Master Boot Record;
  • installs on systems with less than about 192MB of RAM.

}}}


CategorySpec

CDRomBasedUpgradesSpec (last edited 2008-08-06 17:00:16 by localhost)