Red Hat Bugzilla – Bug 161083
Wrong version number. Too old version.
Last modified: 2007-11-30 17:11:08 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4
Description of problem:
Version is "3.0-devel" (also referenced as "unstable") from 2005-04-24, not 2.x from 2005-05-25 or 2005-05-30 as the rpm version suggests.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
rpm -q xen
head -1 /usr/share/doc/xen-2/ChangeLog
rpm -q --changelog xen
Actual Results: rpm -q xen:
Xen version 3.0-devel
Latest ChangeSet: information unavailable
head -1 /usr/share/doc/xen-2/ChangeLog:
ChangeSet@1.1377, 2005-04-23 17:01:19+01:00, email@example.com
Expected Results: rpm -q xen:
Xen version 3.0-devel
Latest ChangeSet: 2005/04/23 17:01:19 1.1377
Disclaimer: I really appreciate the work the fedora team has done to bring xen to the masses. My suggestions shall just help make it easier to use xen and to experiment with it. They are meant as proposals, not as rebukes ;-)
* The wrong version is misleading, as the xen api has changed from 2.0.X to 3.0(-devel). Neither it is a xen-2 nor it is from 20050522. You could even upgrade xen-2-20050522 to xen-2.0.6! The FC4 rpm should be named "xen-3.0pre.$DATE-$REL" or "xen.2.99.$DATE-$REL" or similar. See the ntp rpm versioning as example.
* xen-unstable from 2005-04-24 is rather old. Since then, many bugs have been fixed and some features are added (Eg. xend now uses unix sockets instead of tcp sockets for VM consoles). BK changeset numbers have grown from 1.1377 to 1.1724. Recent domain-U kernels won't boot. If you decide to use "unstable" instead of "stable" (2.0.x) you should stick with development.
* The xen kernel image (/boot/xen.gz) is much like a linux kernel image. Like the latter, it should have a version (/boot/xen-2-20050522.gz) and it should have its own rpm package which can be multiple installed. Eg, name the two packages "xen-kernel"+"xen", or "xen"+"xen-tools".
* As i am in: i'd suggest splitting the kernel-xenU package into kernel-xenU (only the kernel image, to be installed in dom0) and kernel-xeU-modules (all the other stuff like modules, System.map, ..., to be installed in domU).
+1 from me for this request.
I agree with the verion number issue, but it's too late to fix that for FC4.
As for upgrading to a new Xen snapshot, that also requires changing the kernel,
since the handling of ACPI moved from Xen into domain 0. I tried upgrading
rawhide to a newer Xen (before FC4), but that version did not boot on my test
system, so I decided to stay with the version from FC4 test 3.
I agree on the /boot/xen-<version>.gz idea in principle, but in practice it
turns out that things break far too often if the xen.gz does not match the
installed utilities - that interface is also still in flux.
IMHO the proper fix for the xenU kernel living outside of the domain's
filesystem is to have a Xen bootloader - which is available upstream and will be
in newer Xen RPMs for rawhide. That way the kernel can just live inside the domU.
I will upgrade Xen in rawhide, once Xensource has a Xenolinux for 2.6.12.