This time the keyboard device is there even under the hypervisor, but xinit “cannot invoke xkbcomp” under the hypervisor. It’s there in /usr/bin/xkbcomp, but xinit cannot “invoke” it under the hypervisor while it can invoke it when it’s not running under the hypervisor. Mysterious.

I’d like to add a “restore” feature to xen-create-image to go alongside the “install disk”, “install lvm” etc options. It would take an existing disk, mount it and apply some “restore” scripts to it. It would skip over the “create the disk and put stuff on it” part.

The xen-create-image script (in xen-tools) is almost all the way there. It’s fairly modular. It calls other scripts to do parts of its work (like xt-create-xen-config). Those scripts get the (extensive) list of options by inheriting them in the environment.

That means xen-create-image exports the list of config options to its environment. It does this in the exportEnvironment function — except for the ip address list. That is done in runCustomisationHooks. Most unfortunte for me, because the main part of the script goes like this:

Unfortunately, that means that not only are the ip variables not available if I’m not installing, but neither do the customisation hooks get run. I had been hoping to make a new “distro” called “restore” in which I could put scripts like “restore-database-from-dump” and “fix-up-networking-for-new-dom0-location” and suchlike.

This one refers to the breakage of the —ip=auto in xen-create-image from xen-tools 4.2-1. Some parameter checking was implemented, and the value if the —ip option is supposed to resemble an IPv4 address (but the literal string “auto” obviously doesn’t look like an IPv4 address).

UPDATE: fixed in 4.2.1-1. Yay! Unfortunately, it’s not in Debian squeeze, it’s in unstable. To get it, but still prefer stable packages for everything else: