Differences between revisions 57 and 58
Revision 57 as of 2007-03-26 08:13:17
Size: 10368
Editor: ?jfs
Comment: Add some info for 2.4 kernel users with desktop tasks
Revision 58 as of 2007-03-26 10:51:05
Size: 10487
Editor: ?FransPop
Comment: Installing x11-common to solve conflicts is conditional
Deletions are marked like this. Additions are marked like this.
Line 21: Line 21:
 * {{{aptitude install initrd-tools libfam0 xlibmesa-glu x11-common}}}  * {{{aptitude install initrd-tools libfam0 xlibmesa-glu}}}
Line 25: Line 25:
   * {{{x11-common}}}: if {{{xfree86-common}}} is installed. (jfs) Is this right? See #416239 (KDE gets removed because of this)    * 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)

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 tests) If using 2.4, consider upgrading the kernel first, specially if using a Desktop environment. You have two options: upgrade to sarge's 2.6 kernel first (reboot and test) and then to etchs' or do 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 \
       $(COLUMNS=180 dpkg -l 'kernel-image-2.6*' | \
         awk '/^ii/ { print $2 }')
    • 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
  • 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
  • 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
  • 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)

    • might be easier to setup two paths: desktop and non-desktop aggregating this and the unmarkauto openoffice
  • aptitude dist-upgrade

    • 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 devices might not work after reboot properly afterwards.
    • 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>

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

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

unmarkauto

Stunned by the ugliness of the unmarkauto line. 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 uneccessary. If aptitude could be upgraded first it would avoid the ugliness of the first unmarkauto too.

  • (jfs) We have not tested an aptitude ugprade 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).

A cleaner way to list the kernel-image-2.6* packages:

aptitude unmarkauto openoffice.org vim $(dpkg-query -W 'kernel-image-2.6*')

--joeyh