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.

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.

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.

DO NOT allow migration to dependency based boot loading. So far I'm 0 for 5 on that working during upgrades

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
# DO NOT ATTEMPT TO PROCEED UNTIL NOTHING IS ON HOLD.
# reboot the system at this point. probably not needed, but I do it # anyway to make sure things work
reboot

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

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.

run the following to get rid of any orphaned packages after the upgrade

apt-get autoremove

If you are not upgrading Xen, simply reboot. If you are upgrading Xen, read the following before rebooting

Upgrading Xen

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

Look in /etc/grub.d. If it looks like this, you are ok. Note that 08_linux_xen is sorted before 10_linux.

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:

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.

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.

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.

TOOLSTACK=xl

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.

to verify the version of hypervisor currently running, do the following:

cat /sys/hypervisor/version/major /sys/hypervisor/version/minor

Edit your DOMU configuration files

change all eth#'s to xenbr#

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

for HVM's

change absolute paths of kernel and device_model to relative (ie, only put the filenames hvmloader and qemu-dm in, not the full path)

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