Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Wrong version number. Too old version.|
|Product:||[Fedora] Fedora||Reporter:||Nils Toedtmann <bugzilla.redhat.com>|
|Component:||xen||Assignee:||Rik van Riel <riel>|
|Status:||CLOSED WONTFIX||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-06-20 17:07:42 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Nils Toedtmann 2005-06-20 10:47:27 EDT
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): xen-2-20050522, xen-2-20050530 How reproducible: Always Steps to Reproduce: rpm -q xen xm dmesg head -1 /usr/share/doc/xen-2/ChangeLog rpm -q --changelog xen Actual Results: rpm -q xen: xen-2-20050522 xm dmesg: 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-2.99.20050424-4 xm dmesg: Xen version 3.0-devel Latest ChangeSet: 2005/04/23 17:01:19 1.1377 Additional info: 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).
Comment 1 Michael Paesold 2005-06-20 17:00:45 EDT
+1 from me for this request.
Comment 2 Rik van Riel 2005-06-20 17:07:42 EDT
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.