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.


Not everyone has broadband network or cheap Internet. We need to find a way to support dist-upgrades (preferable 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 a half gigabyte of packages - this would take about 20 hours of downloading. He would benefit by a decreased download size.
  • Maria does very security critical 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.


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 available but slow and expensive.


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 The tools should basically 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 otherwise 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 actual package download on a faster connected machine. If the OfflineUpdateSpec 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 call out 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.

Security implications

Because we will offer to run a upgrade script when a certain type of CD is inserted (effectively a auto-run feature) we need to be careful to not open a door for malware CDs this way. To ensure this, we will only offer to upgrade if we find the dist-upgrader and a proper signature for it. The signature needs to verify against a trusted key in /etc/apt/trusted.gpg.

The update-notifier (or a helper script of it) will take care about the signature checking and if that check was successful it will offer to run the upgrader. It will use unpack/start it itself. There will also be a "cdromupgrade" script on the CD as a convenient way for users to upgrade, but that script can't be used by update-notifier because the script itself is not authenticated.

Implementation Plan

The implementation needs to cover the following steps:

  1. modify update-notifier:
    • detect CDROMs that contain a dist-upgrader, do signature checking if it is a valid one [done]
    • offer to do the upgrade via a dialog [done]
    • if we can upgrade, run a helper script that extracts and run the dist-ugprader with the correct CDROM mount path [done]
    • backport the changes to dapper (?) to make the feature available for the dapper->edgy upgrade

  2. modify the ubuntu CD creation script to include the required files (make sure that there is a "upgrade" application on the CD so that even without update-notifier a upgrade is only a sh /cdrom/cdromupgrade. We can't just do it on double-click because the CD is mounted noexec. [done]

  3. modify dist-upgrader:
    • check if it can actually upgrade the current distribution
    • display ReleaseNotes (if we want to display them)

    • run in a special CDROM upgrade mode [done]


The dist-upgrader supports a new "--cdrom" switch that will put it into CDROM upgrade mode. There is also a "cdromupgrade" wrapper script that is designed to be put onto the toplevel dir of the CD that will call the dist-upgrader with the --cdrom parameter. It will try to run the dist-upgrader that needs to be put into the CDROM_ROOT/dists/stable/dist-upgrader/binary-all/ directory. The script can't be run directly from the CD because it is mounted noexec but the update-notifier will call it.

Outstanding issues

  • Do we want to backport the changes for the update-notifier to dapper? This way people we have a easy way to upgrade from dapper->edgy via a CD. OTOH with dapper as LTS release and edgy a bit more experimental we may not want to make this too easy.

  • 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 anymore 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 APTonCD main page. --CypherBios


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