This page exists as an aid for working through the issues with the sarge->etch upgrade path, by providing a current picture of the recommended approaches, and their pros and cons.

See also the [http://lists.debian.org/debian-release/2007/03/msg00776.html latest discussion] on the mailing lists.

Method "C"

Recommended postinstall steps

Some cleanup which will ease etch->lenny upgrades:

Various cleanup:

Possible problems

This doesn't guarantee a usable kernel is installed at all points in the upgrade (regardless of kernel); at some point in the dist-upgrade, udev is installed and hotplug is removed, leaving the previous kernel without working hotplug support (if 2.4) or with an unsupported (by udev) kernel (if 2.6), and the new kernel is not yet installed.

Also, there is a big udev warning asking you to purge hotplug. Will it interfere?

Alternatives

Test cases

Test case 1 (vorlon)

Package set

sarge chroot built with Prio: standard and above, with these additions:

Results

Success. 151 packages removed; all sarge-only, except for akode and hotplug. (XXX: may not be correct, I think I missed reviewing the block of "unused" removals)

Test case 2 (vorlon)

Package set

Results

Success. 145 packages removed; mostly sarge-only, except for 48 packages; most of these are auto-installed packages, either libs or other packages that are no longer part of the desktop task; or they are dummy packages not needed after upgrade.

Test case 3 (fjp)

Package set

Standard current Sarge desktop install with both 2.4 and 2.6 kernel installed; running 2.6 during upgrade.

Results

Success. In total 1108 packages upgraded/installed and 145 removed.

Almost all removed packages were sarge only, pseudo packages or libraries. Exceptions:

gcc-3.4-base, g++-3.3

etch uses 4.1

hotplug

conflicts with udev

gstreamer0.8-*

superseded by gstreamer0.10

pkg-config

was dependency from gstreamer

bluefish

apparently dropped from gnome desktop task

gnome-doc-tools

was dependency from yelp (gnome help browser)

docbook-dsssl

was dependency from gnome-doc-tools

openjade

was dependency from docbook-dsssl

xmms

was dependency from kicker-applets and nautilus

The [http://people.debian.org/~fjp/tmp/upgrade_desktop.html logs for this upgrade] are available for reference. The separate stages of the upgrade and issues have been marked.

Test case 4 (fjp)

Package set

Standard current Sarge install with all server tasks selected and both 2.4 and 2.6 kernel installed; running 2.6 during upgrade.

Results

Success.

For most server installs it will probably be possible to do the kernel installation much earlier. With all standard server tasks installed, I could do:

The addition of initrd-tools in the 3rd step is needed to prevent removal of existing kernels; coreutils is needed to prevent the "readlink error". This step will also update libc6, install udev and remove base-config and hotplug.

The next steps are:

Reason X11 (and even some bits of Gnome) is installed is that some Sarge server tasks depend on graphical management tools. Because the X11 installation is less complete than for desktop, x11-common needs to be added to the manually installed packages to avoid conflicts.

The [http://people.debian.org/~fjp/tmp/upgrade_server.html logs for this upgrade] are available for reference. The separate stages of the upgrade and issues have been marked.

Test case 5 (jfs)

Package set

Minimal (virtual) Sarge install with 2.4 kernel installed.

Results

Success.

Lsb-base is not installed (just recommended) In total: 120 packages upgraded, 33 new, 2 removed (libnewt0.51 netkit-inetd). When the kernel is upgraded: 1 package removed (hotplug), 8 newly installed.

Test case 6 (jfs)

Package set

Standard (virtual) Sarge install (no tasks) with 2.6 kernel installed.

Results

Success.

In total: 199 packages upgraded, 58 new, 9 removed (base-config, gcc-3.4, hotplug, libnewt, python2.3..)

Test case 7 (jfs)

Package set

Standard (virtual) Sarge Desktop install with just 2.4 kernel installed.

Results

Success.

In total:704 packages upgraded, 401 new, 145 removed (including kernel upgrade)

Download: ~ 772 MB downloaded

I ended up having avahi-daemon installed (with a new open port: mdns), I didn't expect a new network service being enabled by default after an upgrade.

The [http://people.debian.org/~jfs/etch/upgrade_desktop_2.4.html logs for this upgrade] are available for reference. The separate stages of the upgrade have been marked.

Test case 8 (#416301)

Package set

Customised sarge Desktop with KDE and most of Gnome (but not using the desktop task), custom 2.6 kernel

Results

Partial success: dbus was not upgraded in dist-upgrade, had to be manually installed to solve conflicts and redo dist-upgrade.

In total (including kernel upgrade): 687 (81+17+589) packages upgraded, 318 (15+296+7) new , 56 (2+54) removed

Download: ~ 701 (128+16.5+539+18) MB downloaded

After installing dbus manually and dist-upgrading again: 1+7 new (including avahi, hal),4 removed (old dbus), 4 upgraded (kde-core kde-devel kdebase kdenetwork)

Note: install pulled in FAM (user was not using it, due to conflict with openAFS) as well as portmap (FAM dependency).

Discussion

unmarkauto

Stunned by the ugliness of the unmarkauto line (now replaced by a cleaner function -- fjp). FWIW, as of 0.4.4-1, aptitude has a special case in it to not remove "unused" linux kernel images. This should at least make the unmarkauto for lenny that is suggested above unnecessary. If aptitude could be upgraded first it would avoid the ugliness of the first unmarkauto too.

Setting Aptitude::Delete-Unused to false would be another approach (if it's available in sarge, haven't checked).

--joeyh

Comment by plugwash

Aptitudes interactive mode while it may be nice for some is not at all intuitive (e.g. it says A-C menu at the top but pressing those keys doesn't seem to bring up any menus) and presumably using an interactive system will also result in the actions taken not being recorded in a typescript ideally it would be best if you could explain how to achieve the goals of that step without using aptitudes interactive interface but failing that please at least add a link to a tutorial about it.

I'd also suggest adding a comment abuot making sure your sources are still pointing at sarge during the initial part of the upgrade as there will be many systems out there using the stable/testing names in sources.list rather than the sarge/etch names.