CDRomBasedUpgradesSpec

Differences between revisions 17 and 18
Revision 17 as of 2006-08-28 09:55:42
Size: 6711
Editor: c-66-41-152-252
Comment: Spelling
Revision 18 as of 2006-08-29 09:46:53
Size: 7090
Editor: p54A65EAE
Comment: implementation plan
Deletions are marked like this. Additions are marked like this.
Line 44: Line 44:
No code for this special case has been written yet. The implementation needs to cover the following steps:
 1. modify update-notifier to detect CDROMs that we can upgrade from and offer to do the install (make sure that there is a "upgrade" application on the CD so that even without update-notifier a upgrade is only a double-click)
 1. modify the ubuntu CD creation script to include the required files
 1. modify the dist-upgrader itself to run in a special CDROM upgrade mode

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.

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 (rewrite sources.list, upgrading, detecting cruft, cleaning up etc).

The difference between the "normal" dist-upgrader mode should 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 should try to estimate the amount of time it will take to download the packages not found upgradable on the CD. This can be done by showing how long it will take with a typical modem/isdn line (56k modem) and a "normal" DSL line (1Mb).

We may consider hooking this with some simple "generate a download wget script/import downloaded debs" button for the download to do the actuall package download on a faster conntected machine. If the OfflineUpdatesSpec is ready by then we probably want to reuse as much from it as possible. 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. It is currently able to detect CDs that look like ubuntu CDs. To make the approach more flexible and robust it will callout to a python script that analyses the CD and take the appropriate action based on if it is a CD with packages, a dist-upgradable CD, a language-pack addon CD or a CD created with the offline-update tool. The detection will be based on the information found in the .disk directory on the CD (e.g. if it has a valid meta-release file it will be assumed to be a dist-upgradeable CD, if it contains a langpack CD signature it will be assumed to be a langpack CD etc).

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

We should also show how long it will take for various network connection speed to download the stuff needed from the net (like "this will take 2h for a 56k modem, 10min on 2Mbit broadband). Or even include a speed-test to figure the speed to the server out yourself.

Implementation

The implementation needs to cover the following steps:

  1. modify update-notifier to detect CDROMs that we can upgrade from and offer to do the install (make sure that there is a "upgrade" application on the CD so that even without update-notifier a upgrade is only a double-click)
  2. modify the ubuntu CD creation script to include the required files
  3. modify the dist-upgrader itself to run in a special CDROM upgrade mode

Outstanding issues

  • 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. There is little we can do about this, but we should try to make sure that our OfflineUpdate tools support this use-case as good as possible.

  • The new desktop-cd has no deb packages on it aynmore so this works for the alternative-install-cd only. This makes this feature less important, but it should still be provided.

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.

}}}

  • Sort of, but only if you upgrade by hand. This specification is about reducing the requirement for manual work. (The main point of the note you saw is to emphasise that the desktop CD cannot currently be used for upgrades.) -- ColinWatson

  • We missed one important point in yesterdays BOF. Even external CD-Creators are not allowed to ship e.g. patented software, e.g. MP3 Codecs (or they pay patent fees). So, there is always an issue with our official universe/multiverse repositories, even when they are not produced by Ubuntu/Canonical, but from third party CD ISO Shops. -- StephanHermann

  • I disagree that the new desktop cd makes the need for CD-based upgrades less important. It makes it more troublesome to provide for CD-based upgrades but they are just as important as they ever were. --IanJackson

  • Maybe a gui-based tool called aptoncd can help. It is under development, and it's specs are compatible with CDRomBasedUpgradesSpec , because what the tool do is a CD/DVD with all packages of selected repositories (main, restricted, universe or multiverse) and can make a CD/DVD with downloaded packages of apt-cache creating a removable repository that can be used in a lot of machines to make [dist]upgrades. To know more about the project, please visit [http://www.cypherbios.org/aptoncd/ APTonCD main page]. --CypherBios


CategorySpec

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