Introduction

GNU/Linux Debian Lenny security support has been dropped since a few days (since the 6th of February to be exact). All administrators are encouraged to upgrade their system from Lenny (5.0) to Squeeze (6.0) as soon as possible.

I only had one server left running Lenny, so yesterday I decided to upgrade it. Everything went… well, I won’t say smooth but less than 24 hours later, everything is running again. Not so bad for a migration. :)

The migration from Lenny to Squeeze

In order to migrate to Squeeze we first need to grab the latest packages for Lenny. That’s obviously very easy:

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade

With this done, we can go on and upgrade our /etc/apt/sources.list. You will need to replace every occurrence of the « lenny » keyword by « squeeze ». If you had the volatile repository enabled (look for « lenny/volatile »), you will need to remove it, as it no longer exists for Squeeze.

When you’re done replacing all occurrences, you may start updating the packages index and then the system itself:

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade

Everything should go pretty straightforward. You should be asked the following questions:

  • Do you want to move to dependency based boot? Yes, you most likely want that. If it fails, look for the names of the initscripts causing trouble, then « remove –purge » them.
  • Do you want to switch from using device name to using device UUID instead? I’m not really fond of the UUID naming schema, but as it appears to be the new common usage, I accepted.
  • Do you want to switch directly to GRUB2 or keep GRUB1 and do chain-loading? Well, for any standard setup GRUB2 should just work out-of-the-box. I’d advice not to chain load the boot-loaders in this case. If you’re using a specific file-system format on /boot, or if you have a complicated boot environment (multiple OSes, exotic hardware drivers, etc.) you may decide to enable chain-loading.
After answering those questions and waiting for the installation to finish, the system rebooted perfectly. Xen wasn’t longer running, but that’s another story.

Cleaning up Xen 3.2 and setting up Xen 4.0

After this migration, we need to re-enable Xen, as the « generic » flavored kernel was installed by default. We also need to migrate the whole Xen toolstack from 3.2 to 4.0, as we’ll now be using a 2.6.32 kernel.

First, try to find every Xen related packages left on your system:

$ dpkg -l | grep xen

At this point, you should remove BUT NOT PURGE (you want to keep the configuration files) all the Xen related packages, except those that were migrated automatically to Xen 4.0.

Once you’re done with this, you may start re-installing Xen:

$ sudo apt-get install xen-hypervisor-4.0-i386 xen-linux-system-2.6-xen-686 xen-utils-4.0 xen-tools

My server is a 32 bits one so I went for the i386/686 version of Xen. If you have 64 bits capable hardware, you’d rather go with the x64 version (named amd64 in Debian).

The problem with the new GRUB2 is that the configuration generation scripts (in /etc/grub.d/) will always put the « generic » flavors of the kernel first in the boot-loader’s configuration. While this if fine for most users, we, in the other hand, need to boot the « xen » flavor. In order to achieve this, you will need to rename one of the GRUB2 generator:

$ cd /etc/grub.d/
$ sudo mv 10_linux 25_linux
$ update-grub2

You can now reboot and enjoy your migrated environment! :)

Conclusion

Everything is not perfect with this migration: one of the iptables feature used by Xen to tag network traffic on bridges/NAT mixed configuration has been deprecated in the latest kernel, resulting on the following dmesg polution:

physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore.

While this is not looking very good, it seems that everything is still running fine. I’m not sure whether that’s a deprecation notice of if something is really missing.

Migrating the DomU from Lenny to Squeeze was not as easy, but that will be the subject for another article :)