The last few days I have done some upgrade testing in Debian, to
see if the upgrade from Lenny to Squeeze will go smoothly. A few bugs
have been discovered and reported in the process
(#585410 in nagios3-cgi,
#584879 already fixed in
enscript and #584861 in
kdebase-workspace-data), and to get a more regular testing going on, I
am working on a script to automate the test.
The idea is to create a Lenny chroot and use tasksel to install a
Gnome or KDE desktop installation inside the chroot before upgrading
it. To ensure no services are started in the chroot, a policy-rc.d
script is inserted. To make sure tasksel believe it is to install a
desktop on a laptop, the tasksel tests are replaced in the chroot
(only acceptable because this is a throw-away chroot).
A naive upgrade from Lenny to Squeeze using aptitude dist-upgrade
currently always fail because udev refuses to upgrade with the kernel
in Lenny, so to avoid that problem the file /etc/udev/kernel-upgrade
is created. The bug report
#566000 make me suspect
this problem do not trigger in a chroot, but I touch the file anyway
to make sure the upgrade go well. Testing on virtual and real
hardware have failed me because of udev so far, and creating this file
do the trick in such settings anyway. This is a
known
issue and the current udev behaviour is intended by the udev
maintainer because he lack the resources to rewrite udev to keep
working with old kernels or something like that. I really wish the
udev upstream would keep udev backwards compatible, to avoid such
upgrade problem, but given that they fail to do so, I guess
documenting the way out of this mess is the best option we got for
Debian Squeeze.
Anyway, back to the task at hand, testing upgrades. This test
script, which I call upgrade-test for now, is doing the
trick:
#!/bin/sh
set -ex
if [ "$1" ] ; then
desktop=$1
else
desktop=gnome
fi
from=lenny
to=squeeze
exec < /dev/null
unset LANG
mirror=http://ftp.skolelinux.org/debian
tmpdir=chroot-$from-upgrade-$to-$desktop
fuser -mv .
debootstrap $from $tmpdir $mirror
chroot $tmpdir aptitude update
cat > $tmpdir/usr/sbin/policy-rc.d <<EOF
#!/bin/sh
exit 101
EOF
chmod a+rx $tmpdir/usr/sbin/policy-rc.d
exit_cleanup() {
umount $tmpdir/proc
}
mount -t proc proc $tmpdir/proc
# Make sure proc is unmounted also on failure
trap exit_cleanup EXIT INT
chroot $tmpdir aptitude -y install debconf-utils
# Make sure tasksel autoselection trigger. It need the test scripts
# to return the correct answers.
echo tasksel tasksel/desktop multiselect $desktop | \
chroot $tmpdir debconf-set-selections
# Include the desktop and laptop task
for test in desktop laptop ; do
echo > $tmpdir/usr/lib/tasksel/tests/$test <<EOF
#!/bin/sh
exit 2
EOF
chmod a+rx $tmpdir/usr/lib/tasksel/tests/$test
done
DEBIAN_FRONTEND=noninteractive
DEBIAN_PRIORITY=critical
export DEBIAN_FRONTEND DEBIAN_PRIORITY
chroot $tmpdir tasksel --new-install
echo deb $mirror $to main > $tmpdir/etc/apt/sources.list
chroot $tmpdir aptitude update
touch $tmpdir/etc/udev/kernel-upgrade
chroot $tmpdir aptitude -y dist-upgrade
fuser -mv
I suspect it would be useful to test upgrades with both apt-get and
with aptitude, but I have not had time to look at how they behave
differently so far. I hope to get a cron job running to do the test
regularly and post the result on the web. The Gnome upgrade currently
work, while the KDE upgrade fail because of the bug in
kdebase-workspace-data
I am not quite sure what kind of extract from the huge upgrade logs
(KDE 167 KiB, Gnome 516 KiB) it make sense to include in this blog
post, so I will refrain from trying. I can report that for Gnome,
aptitude report 760 packages upgraded, 448 newly installed, 129 to
remove and 1 not upgraded and 1024MB need to be downloaded while for
KDE the same numbers are 702 packages upgraded, 507 newly installed,
193 to remove and 0 not upgraded and 1117MB need to be downloaded
I am very happy to notice that the Gnome desktop + laptop upgrade
is able to migrate to dependency based boot sequencing and parallel
booting without a hitch. Was unsure if there were still bugs with
packages failing to clean up their obsolete init.d script during
upgrades, and no such problem seem to affect the Gnome desktop+laptop
packages.
