Differences between revisions 74 and 75
Revision 74 as of 2007-03-27 01:37:57
Size: 13426
Comment: Add note about --with-recommends
Revision 75 as of 2007-03-27 01:45:03
Size: 13492
Comment: Description of the dist-upgrade issue
Deletions are marked like this. Additions are marked like this.
Line 60: Line 60:
This doesn't guarantee a usable kernel is installed at all points in the upgrade (if using 2.6); at some point in the dist-upgrade, udev is installed and hotplug is removed, leaving the previous kernel without working hotplug support, and the new kernel is not yet installed. 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.

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"

  • 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").
  • [jfs-Pending more testing] Users depending on hotplug and using 2.4, should consider upgrading the kernel first, specially if using a Desktop environment (as udev, pulled in by gnome-volume-manager, will force removal of hotplug when dist-upgrading). You have two options: upgrade to sarge's 2.6 kernel first (reboot and test) and then to etchs' or do a minimal upgrade (all steps before the 'dist-upgrade' below) then 'aptitude install coreutils' and upgrade to etch's 2.6 kernel (reboot and test).
  • 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

    • 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?
  • 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
    • (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?BRdpkg -l *-image-* | grep ^ii. Note: might be wise to recommend use of -686 or -486 instead of old -386.

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>

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

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

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

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) We have not tested an aptitude upgrade first, as previously recommended with the RN with this procedure, but previous tests suggest that if aptitude is upgraded first large chunks of the system get removed. See last comments of [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401317 #401317]

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 presumablly 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 achive 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 reffering 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.