Product SiteDocumentation Site

6.6. Upgrading from One Stable Distribution to the Next

One of the best-known features of Debian is its ability to upgrade an installed system from one stable release to the next: dist-upgrade — a well-known phrase — has largely contributed to the project's reputation. With a few precautions, upgrading a computer can take as little as a few, or a few dozen, minutes depending on the download speed from the package repositories.

6.6.1. Recommended Procedure

Since Debian has quite some time to evolve in-between stable releases, you should read the release notes before upgrading.
In this section, we will focus on upgrading a Lenny system to Squeeze. This is a major operation on a system; as such, it is never 100% risk-free, and should not be attempted before all important data has been backed up.
Another good habit which makes the upgrade easier (and shorter) is to tidy your installed packages and keep only the ones that are really needed. Helpful tools to do that include aptitude, deborphan and debfoster (see Section 6.4.1, “ aptitude). For example, you can use the following command:
# deborphan | xargs aptitude remove
Now for the upgrading itself. First, you need to change the /etc/apt/sources.list file to tell APT to get its packages from Squeeze instead of Lenny. If the file only contains references to Stable rather than explicit codenames, the change isn't even required, since Stable always refers to the latest released version of Debian. In both cases, the database of available packages must be refreshed (with the aptitude update command or the refresh button in synaptic).
Once these new package sources are registered, you need to upgrade the aptitude and apt packages; their versions in Lenny have some limitations that could compromise the automatic upgrade.
Remember to upgrade (or install) the most essential packages listed below, otherwise you might find that your system is unbootable:
  • the bootloader grub-pc or grub-legacy (sometimes lilo);
  • the tools that build the initial ramdisk (initrd): initramfs-tools;
  • the standard library: libc6 or one of its optimized variants such as libc6-i686;
  • the management system for device files: udev;
  • last but not least, the kernel: depending on the hardware, the metapackages to use are linux-image-486, linux-image-686 or linux-image-686-bigmem. These packages will only work for the i386 architecture; owners of computers based on different hardware will use other packages, most likely linux-image-2.6-amd64 for AMD64 or linux-image-powerpc* for PowerPC.
Once these first steps are done, it is time to handle the upgrade itself, either with aptitude or synaptic. You should carefully check the suggested actions before applying them: you might want to add suggested packages or deselect packages which are only recommended and known not to be useful. In any case, the front-end should come up with a scenario ending in a coherent and up-to-date Squeeze system. Then, all you need is to do is wait while the required packages are downloaded, answer the Debconf questions and possibly those about locally modified configuration files, and sit back while APT does its magic.

6.6.2. Handling Problems after an Upgrade

In spite of the Debian maintainers' best efforts, a major system upgrade isn't always as smooth as you could wish. New software versions may be incompatible with previous ones (for instance, their default behavior or their data format may have changed). Also, some bugs may slip through the cracks despite the testing phase which always precedes a Debian release.
To anticipate some of these problems, you can install the apt-listchanges package, which displays information about possible problems at the beginning of a package upgrade. This information is compiled by the package maintainers and put in /usr/share/doc/package/NEWS.Debian files for the benefit of users. Reading these files (possibly through apt-listchanges) should help you avoid bad surprises.
You might sometimes find that the new version of a software doesn't work at all. This generally happens if the application isn't particularly popular and hasn't been tested enough; a last-minute update can also introduce regressions which are only found after the stable release. In both cases, the first thing to do is to have a look at the bug tracking system at http://bugs.debian.org/package, and check whether the problem has already been reported. If it hasn't, you should report it yourself with reportbug. If it is already known, the bug report and the associated messages are usually an excellent source of information related to the bug:
  • sometimes a patch already exists, and it is available on the bug report; you can then recompile a fixed version of the broken package locally (see Section 15.1, “Rebuilding a Package from its Sources”);
  • in other cases, users may have found a workaround for the problem and shared their insights about it in their replies to the report;
  • in yet other cases, a fixed package may have already been prepared and made public by the maintainer.
Depending on the severity of the bug, a new version of the package may be prepared specifically for a new revision of the stable release. When this happens, the fixed package is made available in the proposed-updates section of the Debian mirrors (see Section 6.1.1.1, “Stable Updates”). The corresponding entry can then be temporarily added to the sources.list file, and updated packages can be installed with apt-get or aptitude.
Sometimes the fixed package isn't available in this section yet because it is pending a validation by the Stable Release Managers. You can verify if that's the case on their web page. Packages listed there aren't available yet, but at least you know that the publication process is ongoing.