Upgrade Squeeze to Wheezy

Once again, Debian keeps the Xen users on their toes. Upgrading to Wheezy on a standard system is fairly straight forward, but once Xen is involved, I ran into some strangeness. Note to non-xen users, however. Dovecot also introduces some strangeness.


Following is my checklist to do squeeze to wheezy upgrades. I'm going to turn on comments on this article, and I'll leave it on unless the spam gets too much. Feel free to contact me by going to http://www.dailydata.net and clicking on the Contact Us button.


I intend to use this as my checklist for the other dozen or so DOM0's I have to upgrade very soon, so expect changes as I find things I did not include here.


  1. If you have anything which takes a while to start up on reboot, you might disabled them during the update. On my Xen DOM0's, I turn off all virtuals and set auto to not happen during this stage make sure your system is completely up to date on squeeze.
  2. Ran into some strangeness upgrading Dovecot. I'm doing another upgrade this evening, so will hopefully have more info soon. Recommend you back up the entire dovecot conf dir (/etc/dovecot) AND the SSL keys if you have them (they should be someplace in /etc/ssl). I plan to answer "yes" to upgrading the configuration, then work out how to do that (I use a database back end for our dovecot install). More information later.
  3. DO NOT allow migration to dependency based boot loading. So far I'm 0 for 5 on that working during upgrades
  4. Ensure you have your squeeze install fully updated.
    apt-get update && apt-get upgrade
    apt-get dist-upgrade
    # make sure nothing is on hold
    # anything on hold will show up after second command
    dpkg --audit
    dpkg --get-selections | grep hold
    # reboot the system at this point. probably not needed, but I do it 
    # anyway to make sure things work reboot
  5. edit /etc/apt/sources.list and squeeze to wheezy to begin the upgrade. Delete all lines which say wheezy and replace them with the following
    deb http://ftp.us.debian.org/debian/ wheezy main non-free contrib
    deb-src http://ftp.us.debian.org/debian/ wheezy main non-free contrib
    deb http://security.debian.org/ wheezy/updates main contrib non-free
    deb-src http://security.debian.org/ wheezy/updates main contrib non-free
  6. now, you are ready to do the upgrade
    # following command will have many package held back. That is ok
    apt-get update && apt-get upgrade
    # next line installs all the packages held back
    apt-get dist-upgrade
  7. Got some good notes from https://juliankessel.de/2013/05/07/hiccups-upgrading-squeeze-to-wheezy-in-a-xen-environment/
    # Run the following command to remove some junk wheezy leaves around
    apt-get remove $(apt-dater-host refresh | grep "x$" | \
        awk -F '\\||[[:space:]]' '{ OFS=" "; printf $2" ";}')
    1. You may need to purge and reinstall php5-sqlite
    2. You want to purge php5-suhosin if the installer doesn’t do it for you; It’s not supported anymore by wheezy. You will get errors via cron otherwise.
  8. run the following to get rid of any orphaned packages after the upgrade
    apt-get autoremove
  9. If you are not upgrading Xen, simply reboot. If you are upgrading Xen, read the following before rebooting


Upgrading Xen

  1. Most likely, when you did your update, it grub asked if it could "fix" 10_linux in /etc/grub.d. Debian now has a permenant way to set that up (if you are not aware, the default grub install in debian always prioritizes standard Linux over Xen).
    1. Look in /etc/grub.d. If it looks like this, you are ok. Note that 08_linux_xen is sorted before 10_linux.
      00_header	 08_linux_xen  30_os-prober  41_custom
      05_debian_theme  10_linux      40_custom     README
      This means linux_xen will be a higher priority than linux (ie, 08 is sorted before 10).
    2. If it does not look like the above, but has linux_xen numerically after linux, note the full names and issue the following command
      dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen
      This will be honored in any future updates
    3. You can reverse the above command by issuing the following
      dpkg-divert --rename --remove /etc/grub.d/20_linux_xen
  2. Debian does not want you to set up your bridges in Xen, but to do it through the standard Debian configurations. In the past, it allowed it, and I had a script designed to use both NIC's for two different networks. This no longer works. The solution was to define it as Debian's way, noted at http://wiki.debian.org/Xen#Configure_Networking. Change by removing the eth0 connection to the following in /etc/network/interfaces to:
    iface eth0 inet manual
    auto xenbr0
    iface xenbr0 inet static
       bridge_ports eth0
    1. Note: My setup is a little more complex. I use two NIC's, one for a private network (which gets its address via DHCP) and one for public IP's. I do not want access to my DOM0's via public IP (I have a VPN to the private LAN), so I configure the external, but put an IP from the testing range (which should not be routable) there. Then, that bridge is configured but unusable for DOM0 (but can by used by the DOMU's). All network traffic from the DOM0 goes through my private LAN. Note that the LAN is configured before the outside interface (so routing tables end up right). Also, the outside interface (xenbr0 based on eth0) has a very non-routable IP address and subnet.
      # The loopback network interface
      auto lo
      iface lo inet loopback
      iface eth1 inet manual
      auto xenbr1
      iface xenbr1 inet dhcp
         bridge_ports eth1
      iface eth0 inet manual
      auto xenbr0
      iface xenbr0 inet static
         bridge_ports eth0
  3. For your paravirts, you will need to copy the new kernel modules from the DOM0's to the virtual. We mount the root partition (or wherever /lib/modules is) on /mnt, then copy.
    mount /dev/virtuals/whateverdisk /mnt
    cp -av /lib/modules/* /mnt/lib/modules
    That, of course, copies way too much stuff. If you want to be neat and clean, delete all but the new modules. Yeat another reason I'm liking HVM's a lot more.
  4. Change toolstack to xl. xm is out of date. Edit /etc/default/xen and fix the following line. As it says in the config file, you will need to reboot for changes to take effect.
    1. Note: I have had a couple failures on running xl. On one system, I noted the hypervisor was NOT set to 4.1. If you get an error message about 'xl not found, falling back to xm' or something, verify the correct hypervisor is installed. I ASSUME you can simply shut down xen and restart it, but I simply rebooted since I had the time.
    2. to verify the version of hypervisor currently running, do the following:
      cat /sys/hypervisor/version/major /sys/hypervisor/version/minor
  5. Edit your DOMU configuration files
    1. change all eth#'s to xenbr#
    2. Verify your vbd's (partitions) are set correctly. Before, you could say "phy:virtuals/something" and it would be relative to /dev. This causes problems on the new system, so make sure you use the fully qualified path/file
    3. for HVM's
      1. change absolute paths of kernel and device_model to relative (ie, only put the filenames hvmloader and qemu-dm in, not the full path)
      2. For Linux HVM's, in configuration file, set
        1. xen_platform_pci=1 # enable Xen PVHVM drivers, see http://wiki.xen.org/wiki/Xen_Linux_PV_on_HVM_drivers
    4. For PV's
      1. Change kernel and ramdisk. NOTE: kernel no longer has xen in the name, so in my case, the lines read:
        kernel = '/boot/vmlinuz-3.2.0-4-amd64'
        ramdisk = '/boot/initrd.img-3.2.0-4-amd64'


Last update:
2013-10-06 23:25
Average rating:0 (0 Votes)

You can comment this FAQ

Chuck Norris has counted to infinity. Twice.

Comment of Luis:
Hi: In the step 3, you said: For your paravirts, you will need to copy the new kernel ... show moremodules from the DOM0's to the virtual. We mount the root partition (or wherever /lib/modules is) on /mnt, then copy. My question: Do I have to do that even if I create a domU from zero?? Regards.
Added at: 2014-02-24 16:32

Comment of Rod:
The problem with paravirts is they use the kernel from the DOM0. During the upgrade process, ... show morethe kernel and libraries in the DOM0 changes (part of the upgrade), but the libraries are not upgraded in the DOMU. Because of this, you will have a kernel which can not find its modules. So, yes, for existing DOMU's, you must manually copy the libraries before booting them. If you do not, you'll get a message that the modules were not found. NOTE: this does not have anything to do with hardware virtualized DOMU's, or paravirts which you create after the upgrade. This is only for paravirts which exist prior to the upgrade (it is also true of most kernel upgrades to the DOM0, which is why I have gotten away from paravirtualization).
Added at: 2014-02-24 18:56