Comment 43 for bug 144631

Just to add my experience here: I had some stuff working on Xen-3.0, Kubuntu feisty host, gutsy-server guest. Paravirtualized, using kernel 2.6.19-4-generic, on a socket-A based host. I upgraded dom0 to gutsy (and fixed the damage after the upgrade tool crashed), updated my config to point to the new kernel and initrd (2.6.22-14-xen), and none of the Xen domains would boot.

Zeroth fix: according to Xen's website somewhere, xend requires python-xml for the shiny new XMLRPC interface, but the Ubuntu package doesn't depend on it. I had some warnings about API calls not being found in the xend log until I installed python-xml. I don't know if that was actually a problem or not. (Given the state of xen-3.1 documentation right now, I'm lucky I ever found out that much.)

First problem: no output except from the kernel, ending with the "EXT3-fs: mounted filesystem with ordered data mode." message. First solution: passing "xencons=tty" in extra. This puts out a bunch of "Couldnt get a file descriptor referring to the console" messages, even with console=tty0 included.

Second problem: hwclock hangs, using 100% CPU (as judged by the 'time' column from 'xm list' in dom0). Second solution: get rid of hwclock. I was desperate to make things work at this point, because I foolishly upgraded before finishing a major project for somebody, which was being tested in one of the domUs. So I disabled hwclock* in /etc/rc?.d and stripped execute permissions from /lib/udev/set_hwclock as mentioned in this bug report. After that, domU booted happily.

IMHO, XenSource should ship this stuff in a non-broken mode where the framebuffer console (which also doesn't work, as far as I can tell) is disabled by default. Finding how to debug should not be an additional shooting-in-the-dark debugging process.