« hexhibition | Main | old times »

making xen 3.0.2 work on ubuntu 6.0x ("dapper drake")

(pardon the interruption, non-geeks. it's been a while since I posted something like this, but I figured I'd save other people a few hours of googling and stuffing around.)

So I've been setting up a new box (for hosting this and some other websites), and figured I'd go for Ubuntu to see if it holds its promise of being a better Debian (or, at least, one with a release cycle for "the rest of us". Of course, not long after I started to use it, they announced they were pushing back the release of dapper from April to June...). In the process of shoe-horning Xen 3.0.1 onto it a few weeks back, it looked like I had to run Ubuntu 5.10 ("breezy badger", i'm a bit over the proliferation of onerous code/release names, but whatever. if it makes them happy...) for the Xen dom0 stuff due to random buggery with hotplug and the (old) kernel it used (2.6.12). or something like that. Well, it worked. I had a dom0 system running 5.10, and a domU system running the soon-to-be-released 6.0x ("dapper drake"), which seemed good enough for me (after all, I wasn't planning on running much on the outside anyway).

In a post-holiday buzz, I noticed Xen 3.0.2 had been released, and figured I may as well give it a whirl - I get to run a current kernel, for instance, and maybe I can update the dom0 system to 6.0x as well - it's nice to start off up-to-date, while I've got time to stuff around with it all (maybe I won't have as much free time later. who knows?). First, I upgraded the Xenified kernels (dom0 and domU) to 2.6.16, and installed the new version of the hypervisor and xend and such. No worries! Everything still worked. I then upgraded the dom0 system to Dapper, and it broke - xend wouldn't start. Here's how I fixed it, mostly with the help of google, which took me to various mailing list posts and such on the xen-user list.

I've generally been installing Xen from source. They seem to make it really hard to just download the source from either of the websites (one, two), but a quick guess by looking at the URLs for the binaries reveals this.

I found a mention of somebody's ubuntuized packages (figuring maybe they knew something I didn't about how to make it work), though there's precious little else on the website about it and they only have i386 binaries - if you need to build from source on an amd64 (x86_64, etc.) box, you might (as at 2006-04-21) have to edit Config.mk and change the following bit...

ifeq ($(XEN_TARGET_ARCH),x86_64)
LIBDIR = lib64
else
LIBDIR = lib
endif

so it says LIBDIR = lib instead of LIBDIR = lib64, so the ubuntu (debian) package building scripts don't get confused when they're looking for libxenstore.so after it's all been compiled and staged. Somewhere towards the end of running dpkg-buildpackage you'll see it complaining about not knowing what libxenstore.so is (but at least it can find it this time, and hence doesn't abort building the package). This is a gross hack and shouldn't be taken as the final solution - there'll be a more correct way of fixing it, but this one works for now. You probably want to add your own entry to debian/changelog at this point, so you know it's your modified version of the package (but use a sub-version-number, otherwise you might never get new packages).

If you're installing from source, you might want to add the following from the ubuntu/debian xen package's /etc/init.d/xend, which goes at the start of the script (after the check for /proc/xen/capabilities) :

# create directories if required
if [ ! -d /var/run/xend ]
then
        mkdir -p /var/run/xend
fi

if [ ! -d /var/run/xenstored ]
then
        mkdir -p /var/run/xenstored
fi

If you don't do this, xend won't start - even worse, you just get a generic "no such file or directory" error, without any real hint of what file or directory it's whining about.

The next little hitch is that (even if you use the packages mentioned above) you'll find that xend can't start the network interface for the domU kernel and aborts booting it up, saying hotplug must be broken. Upgrading to dapper removes hotplug (it's udev all the way - if you think you'll try installing hotplug to make it work, apt-get happily offers to remove a couple of rather vital - for this system - packages like lvm and mdadm, which makes it somewhat less compelling as a solution). After a bit more investigative googling, it turns out that it will work with udev, it's just that the Xen install puts a file in /etc/udev/rules.d called xen-backend.rules. This isn't getting used, but if you rename it to something with a number in front of it like 92-xen-backend.rules, you'll be ok. Mind you, doing an /etc/init.d/udev restart didn't help, I actually had to reboot to make it work (ick!).

Anyway, this lists the hoops I had to jump through to make it work on my Ubuntu system - if you're rather unlucky, you might need to jump through a few more. I hope this is useful to somebody. I figure it'll all get sorted out soon enough in the packages (I wish the ubuntu package maintainers had left contact details in the debian/control file, though - currently it lists the Debian Xen Team).

* 14:51 * geek · comments (3)

Comments

Thanks dude! I tried to setup Xen on Ubuntu too, but got stuk with that udev issue. Your post helped me to solve all the problems. Thanks once more!

> Posted by VK at May 17, 2006 6:29 PM

Yes indeed, this was very helpful! Thanks.

> Posted by John at May 30, 2006 10:08 AM

Great information!

One addition I discovered on edgy was that all of the #!/bin/sh in /etc/xen/scripts was causing problems. I fixed it with the following:


cd /etc/xen/scripts
sed -i -e 's/\/bin\/sh/\/bin\/bash/g' `grep -l "/bin/sh" *`

sorry for the formatting... i tried..

> Posted by John Holder at November 2, 2006 7:59 AM


Comments have been closed for this post. If you've got something to say, please contact me by other means. Thanks!