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.
+For ca. et og et halvt år siden +startet +jeg på et kart over overvåkningskamera i Norge, i regi av +personvernforeningen. Det har +blitt oppdatert regelmessing, og jeg oppdaterte det nettopp. Fra den +spede start med 22 kamera registrert er det nå registrert 54 kamera. +Det er bare en brøkdel av de kamera som finnes i Norge, men det går +sakte men sikkert i riktig retning.
+ +Informasjonen registreres fortsatt direkte inn i +OpenStreetmap, og hentes +automatisk over i + +når jeg kjører et script for å filtrere ut overvåkningskamera fra +OSM-dumpen for Norge.