Differences between revisions 90 and 91
Revision 90 as of 2009-03-16 03:30:30
Size: 15897
Editor: anonymous
Comment: converted to 1.6 markup
Revision 91 as of 2009-12-25 10:58:14
Size: 15858
Editor: FranklinPiat
Comment: DebianBug
Deletions are marked like this. Additions are marked like this.
Line 203: Line 203:
  * (jfs) My tests with a full desktop system show that if aptitude is upgraded first, large chunks of the system get removed. This has also been observed by others, see last comments of [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401317|#401317]]. I've removed the "upgrade aptitude" recommendation from the Release Notes.   * (jfs) My tests with a full desktop system show that if aptitude is upgraded first, large chunks of the system get removed. This has also been observed by others, see last comments of [[DebianBug:401317|#401317]]. I've removed the "upgrade aptitude" recommendation from the Release Notes.

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 latest discussion on the mailing lists.

Method "C"

  • Run aptitude interactively and check that there are no packages scheduled for removal or update (if a packages were installed with apt-get, aptitude may sometimes not know about it and list it for removal; in general, the system should be up-to-date and "clean").
  • Systems using 2.4, should consider upgrading the kernel to version 2.6 first, specially if using a Desktop environment (as udev, pulled in by gnome-volume-manager, will force removal of hotplug when dist-upgrading). There is only one option: upgrade to sarge's 2.6 kernel first (reboot and test) and then to etch's. You cannot do this after a minimal upgrade for Desktop environments since installing the kernel will install udev, remove hotplug and take all the desktop with it.
  • aptitude unmarkauto openoffice.org vim \
       $(dpkg-query -W 'kernel-image-2.6*' | cut -f1)
    • for desktop installs openoffice.org used to be pulled in by openoffice.org-bin which no longer exists
    • for desktop installs vim used to be pulled in through vim-gtk, but apparently nothing depends on that anymore
    • for 2.6 kernel images this is needed because otherwise the dist-upgrade may try to uninstall them if the kernel was installed through a kernel-image meta package
    • to check if packages are marked auto, use search 'i~M <package name>'

  • edit sources.list to point to Etch
  • aptitude update

    • we should warn users about the "warnings" aptitude insists on printing here; these should disappear if aptitude is run a second time
    • (jfs) done
  • aptitude upgrade

    • could also be switched with next step; advantage of doing the next step early could be that glibc is upgraded early; OTOH, doing easy/safe stuff first also makes sense
    • (jfs) I second this.
  • aptitude install initrd-tools libfam0 xlibmesa-glu

    • initrd-tools: if installed

    • libfam0: if libfam0c102 is installed, notice that you may have this installed even though you are *not* using FAM (#416301)

    • xlibmesa-glu: if installed

    • if xfree86-common is installed, x11-common may need to be included here in some cases to resolve all conflicts during the dist-upgrade (see case 4); however, for standard desktop installs this will result in the removal of packages (#416239)

    • maybe its easier to setup two paths: desktop and non-desktop here?
      • (vorlon) yes, we need two paths, because in some desktop setups the above will remove the running kernel (see test #4 below)
    • Note: doing this users which do not have Fam will pull both fam and portmap in(see logs of 416301)
  • Note: Users with a 2.6 kernel can upgrade to etch's version before the dist-upgrade (see test 6), this will reduce the "exposure" time
  • aptitude dist-upgrade

    • (jfs) in previous RN we recommended --with-recommends. Should we consider adding it?
    • users of the 2.6 kernel wishing to test the kernel upgrade first should be advised to do the upgrade before this (as they might get the new kernel in this step) they will need to upgrade coreutils and udev before their upgrades; however, in some cases upgrading the kernel may result in an unacceptable number of packages being removed
    • users of 2.4 kernel w/o desktop environment can wait until after this step to do the kernel upgrade. Note: or kernel upgrade removes hotplug, so old kernel might not boot with all devices.
    • users of 2.4 kernels w desktop environment (more precisely GNOME upgrade, see #398924) will have hotplug removed in favour of udev, so if the system reboots through the upgrade (or after it) devices might not work.
    • if using lilo and it is not rerun after this, the system will not boot from here on
    • if using 2.6, and the kernel has not been upgraded, the system will not boot up properly (due to new udev)
    • if the system is rebooted midway through the process it might be unbootable or boot with errors
    • it seems that some customised desktops will not pull in new dbus (#416301), it needs to be manually installed (see test case 8)
    • (jfs) Check: users of localized versions of Mozilla (mozilla-locale-XX) might get it removed without iceweasel getting installed? (#416239)
  • aptitude update (get gpg sigs)

  • aptitude install linux-image-2.6-<flavor>

    • not needed if the system already has a kernel-image-2.6 meta package installed; in that case the 2.6.18 kernel will already have been pulled in
    • check which kernels are installed with
      dpkg -l *-image-* | grep ^ii. Note: might be wise to recommend use of -686 or -486 instead of old -386.

    • Users with backported 2.6.18-4 kernels will have to manually fix symlinks (should we documment this, it might be quite common) See #416331

Recommended postinstall steps

  • aptitude purge hotplug

  • if using grub: edit /etc/kernel-img.conf (not doing so could break upgrades to lenny)
  • if using lilo: run lilo

Some cleanup which will ease etch->lenny upgrades:

  • aptitude unmarkauto linux-image-2.6-<flavor>

  • aptitude purge kernel-image-2.6-<flavor>

    • make a note that this should be the metapackage, NOT the running kernel. Users might get confused (see #416303)
  • move contents from /etc/network/options to /etc/sysctl.conf

Various cleanup:

  • remove gcc-3.3, g++-3.3 and related packages (etch uses 4.1 by default)
  • remove dummy packages; you may need to 'unmarkauto' the new packages that depend on the dummy packages
    • we could provide a list of dummy packages based on RN's find-dummies script
  • purge removed packages to remove configuration files

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?

  • -- no, per the udev maintainer this is not strictly required. ?SteveLangasek

Alternatives

  • For users that are familiar with using aptitude interactively, that is an alternative option. Any conflicts will need to be resolved manually, which can be quite tricky.

  • If the dist-upgrade step as described above results in conflicts that cannot be resolved or results in unacceptable removals, it is possible to try apt-get dist-upgrade instead. The user will need to be extra alert the next time he uses aptitude as this will leave a lot of pending actions.

Test cases

Test case 1 (vorlon)

Package set

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

  • apt-get install lvm2 kernel-image-2.4.27-3-686
  • tasksel install desktop

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

  • debootstrap --arch i386 sarge
  • aptitude install ~pstandard
  • aptitude install lvm2 kernel-image-2.6-686
  • tasksel install desktop

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 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:

  • aptitude unmarkauto kernel-image-2.6.8-686

  • edit sources.list to point to Etch
  • aptitude update

  • aptitude install coreutils initrd-tools linux-image-2.6-686

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.

  • (vorlon) the correct coreutils dependency has been added to the unstable version of linux-2.6, which will enter etch shortly; so 'coreutils' should not be mentioned in the final release notes, though it should be kept here for the benefit of those helping with testing in the short term.

The next steps are:

  • aptitude install libfam0 xlibmesa-glu x11-common

  • aptitude dist-upgrade

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 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 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).

Quirks

Sarge2EtchUpgradeQuirks Issues encountered during the upgrade

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.

  • (jfs) My tests with a full desktop system show that if aptitude is upgraded first, large chunks of the system get removed. This has also been observed by others, see last comments of #401317. I've removed the "upgrade aptitude" recommendation from the Release Notes.

  • (jfs) I have not tested an aptitude upgrade in server environments, however.

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

  • (fjp) This has the disadvantage that a lot of old libraries will remain installed.

--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.

  • (fjp) That is why we're not recommending it as a primary method, but only suggesting it as an alternative for people already experienced with using aptitude interactively.
  • (plugwash) as the very first step of the primary method you have "Run aptitude interactively and check that there are no packages scheduled for removal or update" i was refering to this not to the option to use aptitude for the main part of the upgrade.

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.

  • (fjp) That is already documented in the release notes and will certainly be kept.
  • (plugwash) The current version of the release notes tells users to change their sources.list to etch right at the beggining of the upgrade and doesn't mention doing anything to the sarge system beyond telling them they should be on the last point release and pointing them to an apendix if they don't think they are. the new path reccomends some steps to be done before changing the sources and updating apt and as such that part of the guide looks like it may need some work to fit with this procedure. If that is already plannned then no problem.
  • (jfs) I've included the unmarkauto steps before the changes to the sources.list in the RN.
  • (plugwash) i'm thinking of the users who have a sources.list saying stable and have already done the apt-get update and aborted an apt-get upgrade before realising a new version of debian has been released. such users will need to get back to a sarge sources.list setup before they can check out thier systems.