Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Xen 3.0.3 officialy released.
...and it would be very cool to see it in portage :)
While I understand that you'd love to see Xen 3.0.3 hit Portage, please don't file such 0-day version bump requests. Be assured that the Gentoo developers *are* watching the Xen mailing lists and other things and *know* that 3.0.3 was just released. They are working on getting it into the Portage tree, but hacking the ebuild, testing it as much as they can, and committing it to Portage takes far longer than the matter of hours you had filed this bug after the release announcement was sent. That's not including of course, the fact that devs generally have work and matters to attend to in real life that may take higher priority than a version-bump to a package they maintain. Please be patient with these things, and give the devs the time to do their work properly.
I *hope* this thing just doesn't ruined your whole life.
http://planet.gentoo.org/developers/aross/2006/10/23/0-day-bump-requests Please read the above link :) Zero day bump requests just slow things down, because the developers concerned have to use their very limited time to read/reply to your bugs... Its your choice guys.. fast bumps /or/ irritable replies from developers on bugs. I'm looking forward to Xen 3.0.3 being in Portage too, but you don't see me chasing the herd on IRC 24x7 with a pointy stick!
Created an attachment (id=100674) [details] Xen sources 2.6.16.29 (for Xen 3.0.3)
Created an attachment (id=100675) [details] Xen hypervisor 3.0.3
Created an attachment (id=100676) [details] Xen daemon 3.0.3 Reworked the ebuild to remove the vnc/sdl use flags into an ioemu flag. Added a few extra directories needed for xend to run. The dependencies for an ioemu enabled xend could do with some testing, I don't have the hardware available to test this.
Hi, tried hypervisor and daemon, they compile fine and work, however networking seems to be not working currently. It's probably something local that seem to be interfering with network-bridge script. Good work anyhow :)
For me this ebuild seems to have the same issues concerning execstacks as the xen-3.0.2.ebuild. See http://bugs.gentoo.org/show_bug.cgi?id=144032 for more infos.
Anything I can do to speed up getting 3.0.3 into the tree?
Well, i have a x86 and a amd64 at hand. So if i can help, then: let me know!
I tried the ebuilds and managed to install and run Windows 2000 as domU on my amd64 machine. Everything including networking seems to be working fine.
Updated ebuilds are available in my overlay, but require further testing before making it into the tree. I'll something up on my overlay's wiki (http://overlays.gentoo.org/dev/aross/wiki) for those who want to help out.
Thanks Andrew. I already notices, that xen-3.0.3 has masked the other day. The ebuilds from your overlay worked fine. I compiled them, bootet dom0, bottet a few domUs - no problems, except: First, i installed xen 3.0.3 and xen-tools 3.0.3, but i didn't recompile the kernel. The result: dom0 didn't boot anymore. That definitely something, where Xen must improve. On the other hand, i ask myself: shouldn't xen 3.0.3 depend on xen-sources >=2.6.16.29?
Xen supports using old versions of the vanilla kernel with the new xen patches though so maybe xen sources need to be defined by more than just the kernel version (ie the xen version as well). I dont know if this is possible in portage though so it might be a stupid idea
(In reply to comment #15) > Xen supports using old versions of the vanilla kernel with the new xen patches > though so maybe xen sources need to be defined by more than just the kernel > version (ie the xen version as well). If you're talking about using a vanilla kernel < 2.6.16.29 and applying the xen 3.0.3 patches, well that's not something we're going to be offering (although you're always free to put it up in an overlay).
Out of interest. What is currently preventing these ebuilds going into portage?
Maintainer time is limited, with almost every other package in the tree we maintain the 'latest' version - GNOME 2.14, KDE 3.5.5, etc :) Some packages require we take a different approach, but this is rare. Putting older versions of the kernel into the tree with Xen 3.0.3 patches poses a number of 'blocker' issues: (i) Maintainability; we need to support anything that's marked stable in Portage. To effectively do this, we must be able to reproduce bugs; the amount of possible configurations would thus increase dramatically. The big one: (ii) Security; we're in a constant battle with Gentoo Security to keep xen-sources out of package.mask :) Older versions of the kernel *do* have vulnerabilities, and our policy as a distribution is to *not* ship vulnerable code - it needs to be patched, updated, or removed from the distribution. Currently the latest version of Xen (3.0.3) *still* applies to a 2.6.16 kernel, even though the rest of the world has moved onto 2.6.18+ ;) So, in short, it'd be a security and maintenance nightmare - but as Andrew indicated, you're more than welcome to host these ebuilds in an overlay; they won't be supported by Gentoo, but provide a usable option for users.
Ack, now I realise you may have been talking about the attached ebuilds :-( Please note my reply was specifically discussing the 'older versions of kernel, patched with latest Xen'; not the current lack of Xen 3.0.3 in Portage! As for the answer you were looking for, I'm sure Andrew will reply sometime...
I did indeed mean the ebuilds for 3.0.3
(In reply to comment #17) > Out of interest. What is currently preventing these ebuilds going into portage? I can't commit the ebuilds until a solution for bug #154307 is found, which will probably be bumping xen-sources to 2.6.18+, based on the debian packages.
(In reply to comment #21) > I can't commit the ebuilds until a solution for bug #154307 is found, which > will probably be bumping xen-sources to 2.6.18+, based on the debian packages. Don't they still maintain 2.6.16.x ? Actually there is 2.6.16.32 released on Nov 25th. The problem is: patching 2.6.16.32 doesn't seem to work out of the box :-(
(In reply to comment #22) > Don't they still maintain 2.6.16.x ? Actually there is 2.6.16.32 released on > Nov 25th. It should read Nov 15th.
For personal use i've extracted the xen patch for the latest fedora kernel and cleaned it up for a vanilla 2.6.18.1 It's available at http://www.zolder.org/xen-2.6.18.1.patch.bz2
Any news about version bump? 3.0.2 is still affected by a "not so nice" bug that softlocks the second cpu in a SMP environment :( http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=543
I would also be happy to see Xen 3.0.3 in portage. This bug is open for almost 2 months while other major distributions are already shipping Xen 3.0.3 (usually with 2.6.18 kernel). There are many bugs in 3.0.2 which makes it unstable and unusable in various environments, which are fixed in 3.0.3. I also cannot see, how this bug depends on #154307. I think that the relation should be reversed (it is easier to make xen-3.0.3 + xen-sources-2.6.18 ebuilds than porting 3.0.2 based xen-sources to non-vulnerable kernel). If there is any way I can help, please let me know.
> I would also be happy to see Xen 3.0.3 in portage. This bug is open for almost > 2 months while other major distributions are already shipping Xen 3.0.3 > (usually with 2.6.18 kernel). Xen 3.0.4 is about to be released. I hope, that applies cleanly to the latest 2.6.16.x kernels (which don't have any security issues?) - or maybe even to a newer version? I don' know, how much be can trust those ports to 2.6.18. So let's see, what the maintainer (Adrew) decides to do. I'm curious too - but we have to be patient. So long, get ebuilds from here: http://overlays.gentoo.org/dev/aross/browser
The problem with sticking to 2.6.16 is that each security fix needs to be backported individually, rather than being able to rely on genpatches. I've added xen-sources-2.6.18 to my overlay, so feedback is greatly appreciated. The ebuild uses genpatches and the cleaned up xen 3.0.3 patch provided by Frido
(In reply to comment #28) > The problem with sticking to 2.6.16 is that each security fix needs to be > backported individually..... I was under the impression that this was the purpose of the 2.6.16 series. Version 2.6.16.36 was released on the 13th of December. From the hg repository it looks like the next release of xen will apply against a 2.6.16.33 kernel. Using only the latest kernel release (2.6.19+ when the next version of Xen is released), will mean a constant dependence on the Fedora or Debian team to port the Xen patches. Just my 2c. Cheers, Brad
(In reply to comment #29) > (In reply to comment #28) > > The problem with sticking to 2.6.16 is that each security fix needs to be > > backported individually..... > > I was under the impression that this was the purpose of the 2.6.16 series. > Version 2.6.16.36 was released on the 13th of December. From the hg repository > it looks like the next release of xen will apply against a 2.6.16.33 kernel. > > Using only the latest kernel release (2.6.19+ when the next version of Xen is > released), will mean a constant dependence on the Fedora or Debian team to port > the Xen patches. > > Just my 2c. I fully agree! So there already 4c ;-)
(In reply to comment #28) > The problem with sticking to 2.6.16 is that each security fix needs to be > backported individually..... Granted this would be extra work (aka pita), but one option might be to give the user the choice. I.e. offer both the 2.6.16 series sources and the 2.6.18+ version. Users can then add >sys-kernel/xen-sources-2.6.16 into their /etc/portage/package.mask if they want to use the 2.6.16 series. Cheers, Brad
Some notes about xen-tools ebuild: Lines: 151 newinitd "${FILESDIR}/${PVR}"/xend.initd xend 152 newconfd "${FILESDIR}"/xendomains.confd xendomains 153 newinitd "${FILESDIR}/${PVR}"/xendomains.initd xendomains In this way both init scripts will not be installed. I've tested them (no screen use flag) and I can report that they are working correctly...maybe small changes needed in "depends" section but nothing very important. Furthermore I would ask Andrew Ross if he could setup a subversion repository (like all the other "official" overlays, so we can checkout it with svn. If it is already possibile, maybe I need some help to set it up :)
Heh, I thought it was just me doing something wrong to mess up the init scripts. On the kernel front I'd be very happy to have a 2.6.18+ xen kernel in the tree, as the version of aacraid in 2.6.16 causes my new servers to crash all the time, and the version of forcedeth is now not marked experimental. I've been using 3.0.3 and 2.6.18 all day without issue.
(In reply to comment #32) > Furthermore I would ask Andrew Ross if he could setup a subversion repository > (like all the other "official" overlays, so we can checkout it with svn. If it > is already possibile, maybe I need some help to set it up :) If you use layman, create /usr/portage/local/layman/overlay.xml and add the following lines: <?xml version="1.0" ?> <overlays> <overlay name="aross" src="http://overlays.gentoo.org/svn/dev/aross" type="svn">
thanks to andrew Ross for the ebuilds. But when i try to use it: LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o: In function `backend_changed': tpm_xen.c:(.text+0x93150): undefined reference to `chip_get_private' drivers/built-in.o: In function `tpmfront_remove': tpm_xen.c:(.text+0x932b1): undefined reference to `chip_get_private' drivers/built-in.o: In function `tpmfront_suspend': tpm_xen.c:(.text+0x932da): undefined reference to `chip_get_private' drivers/built-in.o: In function `tpmfront_resume': tpm_xen.c:(.text+0x9339a): undefined reference to `chip_get_private' drivers/built-in.o: In function `vtpm_vd_recv': : undefined reference to `chip_get_private' drivers/built-in.o:: more undefined references to `chip_get_private' follow drivers/built-in.o: In function `init_vtpm': : undefined reference to `chip_set_private' drivers/built-in.o: In function `cleanup_vtpm': : undefined reference to `chip_get_private' I haven't found "chip_get_private" in 2.6.18-gentoo-r4 sources, so i suppose it's xen specific. I've done the folowwing: webby ~ # bzcat /usr/portage/distfiles/xen-sources-2.6.18.patch.bz2 | grep chip_get_private + vtpms = (struct vtpm_state *)chip_get_private(chip); + vtpms = (struct vtpm_state *)chip_get_private(chip); + vtpms = (struct vtpm_state *)chip_get_private(chip); + vtpms = (struct vtpm_state *)chip_get_private(chip); + vtpms = (struct vtpm_state *)chip_get_private(chip); + struct vtpm_state *vtpms = (struct vtpm_state *)chip_get_private(chip); + vtpms = (struct vtpm_state *)chip_get_private(chip); + struct vtpm_state *vtpms = (struct vtpm_state*)chip_get_private(chip); + struct vtpm_state *vtpms = chip_get_private(chip); I'm not a c coder but it seems that chip_get_private function is not declared anywhere. do I have missed something?
Xen 3.0.4 has been released. Andrew: will you switch to 3.0.4 immediatly? Or will you continue to release 3.0.3 and then switch over to 3.0.4?
*** Bug 159094 has been marked as a duplicate of this bug. ***
Just a heads up: I tried Andrew's overlay. Including xen, xen, tools, and xen-sources. I've had a MAJOR issue. I have an external SATA drive which I pass through to one of the domU guests via the backend driver. When I upgraded, the guest could access the drive after a time the drive becomes unaccessible. The host's logs read Buffer I/O error on device sda as well as ata1.00: exception Emask ... After rebooting the host the drive is accessible again but there is no partition table. I found that I can recreate the partition table and run fsck on the filesystem and all my data is there. Thank goodness I didn't lose anything. But as soon as I try to access the drive again (through the guest) the drive becomes currupt again. I've since downgraded xen by removing the overlay and booting from the previous kernel (also restored config files). I've had to disable udev as it now hangs. I had to also remove xend from services as it also hangs, though I'm able start it manually from the command line. The good news is that now my domU is able to access the external (eSATA) drive without currupting the partition table or any data. The Xen host appears to be pretty unstable since the downgrade so I'll probably end up re-installing this weekend or perhaps restoring from back up. Then again the external drive is my D2D backup drive and I'm not sure that I trust what's on it now ;-)
(In reply to comment #38) > Just a heads up: I tried Andrew's overlay. Including xen, xen, tools, and > xen-sources. I've had a MAJOR issue. > > I have an external SATA drive which I pass through to one of the domU guests > via the backend driver. When I upgraded, the guest could access the drive > after a time the drive becomes unaccessible. The host's logs read > > Buffer I/O error on device sda > > as well as > > ata1.00: exception Emask ... > > After rebooting the host the drive is accessible again but there is no > partition table. I found that I can recreate the partition table and run fsck > on the filesystem and all my data is there. Thank goodness I didn't lose > anything. But as soon as I try to access the drive again (through the guest) > the drive becomes currupt again. > > I've since downgraded xen by removing the overlay and booting from the previous > kernel (also restored config files). I've had to disable udev as it now hangs. > I had to also remove xend from services as it also hangs, though I'm able > start it manually from the command line. The good news is that now my domU is > able to access the external (eSATA) drive without currupting the partition > table or any data. > > The Xen host appears to be pretty unstable since the downgrade so I'll probably > end up re-installing this weekend or perhaps restoring from back up. Then > again the external drive is my D2D backup drive and I'm not sure that I trust > what's on it now ;-) > Which kernel? 2.6.26.* or 2.6.18.*?
(In reply to comment #39) > Which kernel? > 2.6.26.* or 2.6.18.*? > 2.6.18.* ... The one from Andrew's overlay.
(In reply to comment #40) > (In reply to comment #39) > > Which kernel? > > 2.6.26.* or 2.6.18.*? > > > > 2.6.18.* ... The one from Andrew's overlay. > U can try the previous version masking the the 2.6.18.* ebuild. After all, the last kernel was created taking the necessary patches from a fedora installation if I remember correctly.
from Andrew overlay, I'm getting error messages while compiling kernel : arch/x86_64/kernel/built-in.o: In function `identify_cpu': : undefined reference to `genapic' make: *** [.tmp_vmlinux1] Error 1 This only appends while trying to compile domU, without Privileged Guest (domain 0).
(In reply to comment #42) > from Andrew overlay, I'm getting error messages while compiling kernel : > > arch/x86_64/kernel/built-in.o: In function `identify_cpu': > : undefined reference to `genapic' > make: *** [.tmp_vmlinux1] Error 1 > > This only appends while trying to compile domU, without Privileged Guest > (domain 0). > I think it would be helpful telling if this error occurs with the 2.6.18.* (imported patch set from fedora) or with 2.6.16.* :)
(In reply to comment #41) > U can try the previous version masking the the 2.6.18.* ebuild. After all, the > last kernel was created taking the necessary patches from a fedora installation > if I remember correctly. > I've been running dom0 on 2.6.16.29-xen with Xen 3.0.3 for a few days now and so far no partition table curruption on the eSATA drive. So it looks like the issue was with the 2.6.18-xen kernel.
(In reply to comment #43) > (In reply to comment #42) > > from Andrew overlay, I'm getting error messages while compiling kernel : > > > > arch/x86_64/kernel/built-in.o: In function `identify_cpu': > > : undefined reference to `genapic' > > make: *** [.tmp_vmlinux1] Error 1 > > > > This only appends while trying to compile domU, without Privileged Guest > > (domain 0). > > > > I think it would be helpful telling if this error occurs with the 2.6.18.* > (imported patch set from fedora) or with 2.6.16.* :) > Oops, 2.6.18, from the aross ebuild (xen-sources-2.6.18)
Would someone provide a tutorial for a mid-level user like me? How to use the Ross' overlay (what file to create, what command-line to issue,...) Thank you.
(In reply to comment #46) > Would someone provide a tutorial for a mid-level user like me? > How to use the Ross' overlay (what file to create, what command-line to > issue,...) > Thank you. > here you go (i just had to learn this the hard way :) ) (i emerged the latest masked layman) emerge layman create the file aross.xml (name it what you like) /usr/portage/local/layman/aross.xml paste this into aross.xml <overlay name="aross" src="http://overlays.gentoo.org/svn/dev/aross" type="svn"> </overlay> you might not need the closing tag </overlay>, but it works with it. since layman -o file:///usr/portage/local/layman/aross.xml didn't work for me, i added it manually: in /etc/layman/layman.cfg add to the variable "overlays" the line file:///usr/portage/local/layman/aross.xml as in the comments to that variable explained. now save and list the overlays layman -L add the overlay layman -a aross now add to the end of your /etc/make.conf the line: source /usr/portage/local/layman/make.conf ready, you can now browse it via eix, e.g. issue eix xen (if you've installed eix), and check if you can see the versions from andrew's overlay: * app-emulation/xen Available versions: 3.0.2 3.0.2[1] 3.0.2-r1[1] 3.0.3[1] ... i hope this works for you, too :)
Created an attachment (id=106276) [details] Xen hypervisor 3.0.4-1
Created an attachment (id=106278) [details] Xen daemon 3.0.4-1
Created an attachment (id=106280) [details] Xen sources 2.6.16.33 (for Xen 3.0.4-1)
Attached 3.0.4-1 recently released Xen based on Andrew's 3.0.3 overlay.
Last Andrew's post is december 14th. We really needed someone to shake it up. But I dont understand: Why not using 2.6.18?
> But I dont understand: Why not using 2.6.18? Look at comment #44. It may have been a problem in kernel 2.6.18 in general - but it may also have been related to an issue which is the result of porting xen to 2.6.18. 2.6.18 is not officially supported by Xen, yet. So - paranoid as i am - i would like have something more "vanilla" than using Xen 2.6.18 sources by Debian, Fedora or somebody else. And "vanilla" Xen means: 2.6.16 + applying the xen patches. Well, luckily, i don't depend on specific drivers, that are only in 2.6.17, 2.6.18 or 2.6.19.
AFAIK, Xen plans to separate kernel patches from hypervisor around 3.0.5. The kernel patches will be updated to 2.6.20 (and they want some of them to go into 2.6.21, as 2.6.20 has paravirt_ops merged). So, it is possible there will be official 2.6.20 support soon. Until then, I would stick with 2.6.16.33. It would be really cool to have 3.0.4-1 merged to portage, as it contains numerous bugfixes and performance improvements. Also, 2.6.16.33 does not have any issues related to bug #154307, which prevented 3.0.3 inclusion.
3.0.2 is really a mess, so unstable per unstable... anyway, my question is: why attached xen-tools ebuild require x11 headers? i am looking for it, but if you know something... is a new requirement for xen 3.0.4? seems strange, i will never have X on my server... USE="-custom-cflags -debug -doc -ioemu% -pygrub -screen* (-sdl%) (-vnc%)" trace: --- make -C check make[1]: Entering directory `/var/tmp/portage/xen-tools-3.0.4/work/xen-3.0.4_1-src/tools/check' XENFB_TOOLS=n ./chk build Xen CHECK-BUILD Thu Jan 11 15:42:36 CET 2007 Checking check_crypto_lib: OK Checking check_libvncserver: unused, OK Checking check_openssl_devel: OK Checking check_python: OK Checking check_python_devel: OK Checking check_sdl: unused, OK Checking check_x11_devel: *** Check for x11 headers FAILED Checking check_zlib_devel: OK Checking check_zlib_lib: OK make[1]: *** [build] Error 1 make[1]: Leaving directory `/var/tmp/portage/xen-tools-3.0.4/work/xen-3.0.4_1-src/tools/check' make: *** [check] Error 2 make: Leaving directory `/var/tmp/portage/xen-tools-3.0.4/work/xen-3.0.4_1-src/tools' ---
Sorry, I forgot dependency on x11-proto/xproto. This is currently needed by VNC support on HVM guests (I think it is keysymdef.h that is needed). There is ongoing discussion on xen-devel ML about dropping this dependency and including this file into Xen. Also, you will need some files from FILESDIR of xen-tools on Andrew's overlay for successful build. (grep ebuild for FILESDIR for details).
Has someone tested the stability of the 2.6.18 suggested by A Ross?
(In reply to comment #57) > Has someone tested the stability of the 2.6.18 suggested by A Ross? > I've been using it in pre-production since he made it available. No problems at all. 1 of 2 is going into production tomorrow too.
I would need help... http://forums.gentoo.org/viewtopic-p-3840843.html#3840843
im using 2.6.18 on 2 boxes atm (xeon 5140 based), using non-HVM guests and its running fine here so far (gentoo dom0 with ubuntu dapper domU built with modified domi ebuild for updated version).
Another problem: in 3.0.4 scripts net.eth* is not executed anymore. does that mean that it should be rc-update default? well, i can't say for sure, but seems that without it won't create bridge correctly, at least with vlan. just two words about vlans config: i have twu different type of domUs: - one kind with all bridge xenbr1, and inside domU i am using vconfig - one kind with xenbr1.nnn where nnn is vlan number, created in dom0, and domU belive that it is a "normal" interface. the first one is working, the second one won't. if someone have had experience with vlan, please upgrade me. plase note that this setup is working in 3.0.2 (gentoo ebuild), but since hardware is different i can't say for sure that this is a software problem. bye d.
Hi, I dont know what all wthis xen bridge setup blahblah is good for. In my opinion xen should have nothing to do with network setup. Let gentoo build all this stuff (at least bridge setup, dont know about nat/route). My setup looks like this and is working like a charm: /etc/conf.d/net config_lan=( "19.1.1.2/29" ) routes_lan=( "default via 10.1.1.1" ) config_domu=( "null" ) config_mngt=( "null" ) config_int=( "null" ) vlans_domu="2 10 18 320 321" vconfig_domu=( "set_name_type VLAN_PLUS_VID_NO_PAD" ) config_vlan2=( "null" ) config_vlan10=( "null" ) config_vlan18=( "null" ) config_vlan320=( "null" ) config_vlan321=( "null" ) bridge_br999="int" config_br999=( "null" ) brctl_br999=( "setfd 0" "sethello 0" "stp off" ) bridge_br2="vlan2" config_br2=( "null" ) brctl_br2=( "setfd 0" "sethello 0" "stp off" ) bridge_br10="vlan10" config_br10=( "null" ) brctl_br10=( "setfd 0" "sethello 0" "stp off" ) bridge_br18="vlan18" config_br18=( "null" ) brctl_br18=( "setfd 0" "sethello 0" "stp off" ) bridge_br320="vlan320" config_br320=( "null" ) brctl_br320=( "setfd 0" "sethello 0" "stp off" ) bridge_br321="vlan321" config_br321=( "null" ) brctl_br321=( "setfd 0" "sethello 0" "stp off" ) RC_NEED_br2="net.domu" RC_NEED_br10="net.domu" RC_NEED_br18="net.domu" RC_NEED_br320="net.domu" RC_NEED_br321="net.domu" RC_NEED_br999="net.int" in xend-config.sxp: (network-script network-bridge-gentoo) network-bridge-gentoo # cat /etc/xen/scripts/network-bridge-gentoo #/bin/bash exit 0 DomainU config: vif = [ 'mac=AA:00:00:70:42:01, bridge=br320','mac=AA:00:00:70:43:01, bridge=br999' ] I think there can be a similar way for nat/route setup, but never tried. This should be implemented by the ebuild. @Daniele, the above setup describes your problem #2 and it is working here. regards Martin
The xen-tools-3.0.3.ebuild file from aross' overlay will not emerge if the 'doc' use flag is set (it works fine without doc): ----------------------- make[1]: Entering directory `/var/tmp/portage/xen-tools-3.0.3/work/xen-3.0.3_0-src/docs' install -d -m0755 html/user latex2html -split 0 -show_section_numbers -toc_depth 3 -nonavigation \ -numbered_footnotes -local_icons -noinfo -math -dir html/user \ src/user.tex 1>/dev/null 2>/dev/null make[1]: *** [html/user/index.html] Error 2 make[1]: Leaving directory `/var/tmp/portage/xen-tools-3.0.3/work/xen-3.0.3_0-src/docs' make: *** [html] Error 2 rm user.dvi interface.dvi make: Leaving directory `/var/tmp/portage/xen-tools-3.0.3/work/xen-3.0.3_0-src/docs' !!! ERROR: app-emulation/xen-tools-3.0.3 failed. Call stack: ebuild.sh, line 1546: Called dyn_compile ebuild.sh, line 937: Called src_compile xen-tools-3.0.3.ebuild, line 128: Called die !!! compiling docs failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! This ebuild is from an overlay: '/usr/portage/local/layman/aross'
From the previous comment: I should have said what use flags were applied (as reported by emerge -av xen-tools): USE="doc* ioemu pygrub -custom-cflags -debug -screen"
Hi, I just tried to compile the xen 3.0.4 ebuilds on my gentoo machine. the xen-sources and the xen ebuild worked fine, but the xen-tools package failed with the following error. gcc -O2 -fomit-frame-pointer -m32 -march=i686 -DNDEBUG -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -Wp,-MD,.xenstored_linux.o.d -I../../tools/libxc -I. -c -o xenstored_linux.o xenstored_linux.c gcc -O2 -fomit-frame-pointer -m32 -march=i686 -DNDEBUG -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -Wp,-MD,.xenstored.d -I../../tools/libxc -I. -L../../tools/libxc xenstored_core.o xenstored_watch.o xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o utils.o tdb.o hashtable.o xenstored_linux.o -lxenctrl -o xenstored ../../tools/libxc/libxenctrl.so: undefined reference to `___tls_get_addr' collect2: ld returned 1 exit status make[1]: *** [xenstored] Error 1 make[1]: Leaving directory `/var/tmp/portage/xen-tools-3.0.4/work/xen-3.0.4_1-src/tools/xenstore' make: *** [all] Error 2 make: Leaving directory `/var/tmp/portage/xen-tools-3.0.4/work/xen-3.0.4_1-src/tools' does anyone know what is causing this problem or how i might fix it?
> ../../tools/libxc/libxenctrl.so: undefined reference to `___tls_get_addr' > collect2: ld returned 1 exit status > make[1]: *** [xenstored] Error 1 imho you have a 32 bit machine and you have not recompiled world (emerge -e world) with flag -mno-tls-direct-seg-refs but maybe i'm wrong :) bye d.
Using the xen-tools-3.0.4 ebuild submitted by Jan Oravec on 2007-01-10, the package fails if the pygrub USE flag is enabled because the patch it triggers in src_unpack() won't apply due to missing files.
Created an attachment (id=108321) [details] Xen sources 2.6.16.38 (for Xen 3.0.4-1) i just tried to use a newer 2.6.16.x kernel for xen 3.0.4 on my workstation. semms to work perfectly. dom0 and domU boots without problem with 2.6.16.38. i will test it in detail the first week of february on a test-server. btw: anyone having problems with 3.0.4 and vif-scripts. i needed to update to bridge-utils-1.2 in order to get domUs to boot?
Created an attachment (id=108332) [details] xen-sources ebuild 2.6.16.38, renaming to other version works as well I cleaned up the ebuild a bit. ebuild now uses unpack by kernel-2.eclass and such things. It can be renamed to 2.6.16.33 or any other version between 2.6.16.33 and 2.6.16.38, i guess. Greetings, Sven
I have setted up an overlay to track all the ebuild that I am using. Among these I've added all the Xen related stuff. Anyone who wants to use it instead using a local overlay is welcome :) http://dev01.katarsi.net/katlay/ I have also uploaded an xml file to make life easier to track both overlays (aross and mine) though layman. Just add the following line below the layman's default one: overlays : http://www.gentoo.org/proj/en/overlays/layman-global.txt http://dev01.katarsi.net/overlays/layman-katarsi.xml Any comment regarding the settings (should be ok) are more than welcome. :)
Created an attachment (id=108430) [details] Xen 3.0.4, Linux Xen 2.6.18.6, NVidia 9746 I have finished the portage of Xen 3.0.4, Xen Tools NVidia Drivers 9746 running under Xen and Linux 2.6.18.6 with Xen patch all running on Gentoo just with emerge ;-) My ebuilds are in attachment. I hope you will include all under the official Gentoo portage. Best Regards, Guy -- Infomaniak Network SA Guy Baconniere <baco@infomaniak.ch> Unix System Administrator Certified Linux Engineer (RHCE, LPIC-2) Avenue de la Praille 26 1227 Carouge (Geneva) Switzerland (CH) AS29222 / BACO-RIPE
(From update of attachment 108430 [details]) I have finished the portage of Xen 3.0.4, Xen Tools NVidia Drivers 9746 running under Xen and Linux 2.6.18.6 with Xen patch all running on Gentoo just with emerge ;-) My ebuilds are in attachment. I hope you will include all under the official Gentoo portage. Best Regards, Guy -- Infomaniak Network SA Guy Baconniere <baco@infomaniak.ch> Unix System Administrator Certified Linux Engineer (RHCE, LPIC-2) Avenue de la Praille 26 1227 Carouge (Geneva) Switzerland (CH)
Created an attachment (id=108452) [details] xen-sources ebuild 2.6.16.38, renaming to other version works as well new ebuild. old one had one small bug.
(In reply to comment #72) > (From update of attachment 108430 [details] [edit]) > I have finished the portage of Xen 3.0.4, Xen Tools > NVidia Drivers 9746 running under Xen and Linux 2.6.18.6 > with Xen patch all running on Gentoo just with emerge ;-) > > My ebuilds are in attachment. I hope you will include > all under the official Gentoo portage. > > Best Regards, > Guy > > > -- > > Infomaniak Network SA > Guy Baconniere <baco@infomaniak.ch> > Unix System Administrator > Certified Linux Engineer (RHCE, LPIC-2) > Avenue de la Praille 26 > 1227 Carouge (Geneva) > Switzerland (CH) > Can someone add this to Andrew Ross' Overlay? I'd love to try it, as it is exactly what I need..
(In reply to comment #62) > Hi, I dont know what all wthis xen bridge setup blahblah is good for. In my > opinion xen should have nothing to do with network setup. > Let gentoo build all this stuff (at least bridge setup, dont know about > nat/route). My setup looks like this and is working like a charm: > > @Daniele, the above setup describes your problem #2 and it is working here. ok, i found a "bug". to setup correctly, with xen bridge scripts: /etc/init.d/xend start /etc/init.d/xend stop /etc/init.d/net.eth1 start /etc/init.d/xend start this should be in cause of eth1 -> peth1 renaming. said that, the real problem is that in that way xenbr1 AND xenbr1.14, ... alll works. instead, doing it manually (to setup a gentoo script later): ifconfig eth1 up [optional, by now: `ip link set eth1 addr fe:ff:ff:ff:ff:ff`] brctl addbr xenbr1 brctl addif xenbr1 eth1 [optional: setfd 0, sethello 0, stp off] ifconfig xenbr1 up [now xenbr1 is working correctly] vconfig add eth1 14 [now xenbr1 stop working, and receive only untagged packets] someone? this should be in gentoo-xen wiki, imho, when i (or much better: WE) find out a solution. bye d.
I got the following error when building xen-sources-2.6.16.38 from the overlay at http://dev01.katarsi.net/katlay/ net/sctp/input.c: In function `sctp_rcv': net/sctp/input.c:137: error: too many arguments to function `skb_linearize' make[2]: *** [net/sctp/input.o] Error 1 make[1]: *** [net/sctp] Error 2 make: *** [net] Error 2 I am not sure if this is xen related. I used the .config file that worked from xen-sources-2.6.16.33 of the same overlay.
(In reply to comment #76) > I got the following error when building xen-sources-2.6.16.38 from the overlay > at http://dev01.katarsi.net/katlay/ > > net/sctp/input.c: In function `sctp_rcv': > net/sctp/input.c:137: error: too many arguments to function `skb_linearize' > make[2]: *** [net/sctp/input.o] Error 1 > make[1]: *** [net/sctp] Error 2 > make: *** [net] Error 2 > > I am not sure if this is xen related. I used the .config file that worked from > xen-sources-2.6.16.33 of the same overlay. > Should be the Sven's one if I remember correctly.
(In reply to comment #76) > I got the following error when building xen-sources-2.6.16.38 from the overlay > at http://dev01.katarsi.net/katlay/ > > net/sctp/input.c: In function `sctp_rcv': > net/sctp/input.c:137: error: too many arguments to function `skb_linearize' > make[2]: *** [net/sctp/input.o] Error 1 > make[1]: *** [net/sctp] Error 2 > make: *** [net] Error 2 > > I am not sure if this is xen related. I used the .config file that worked from > xen-sources-2.6.16.33 of the same overlay. quick solutions could be to disable sctp-support. i'm pretty sure, you don't need it (it should be marked expimental anyway?)
I did that (disable sctp) and it worked. Thanks
(In reply to comment #72) > (From update of attachment 108430 [details] [edit]) > I have finished the portage of Xen 3.0.4, Xen Tools > NVidia Drivers 9746 running under Xen and Linux 2.6.18.6 > with Xen patch all running on Gentoo just with emerge ;-) > > My ebuilds are in attachment. I hope you will include > all under the official Gentoo portage. > > Best Regards, > Guy what's with the Nvidia patch in the archive? do i still have to patch the contained nvidia-drivers? if so, how do i do that? > > > -- > > Infomaniak Network SA > Guy Baconniere <baco@infomaniak.ch> > Unix System Administrator > Certified Linux Engineer (RHCE, LPIC-2) > Avenue de la Praille 26 > 1227 Carouge (Geneva) > Switzerland (CH) >
> what's with the Nvidia patch in the archive? > do i still have to patch the > contained nvidia-drivers? > if so, how do i do that? Is it in order to have 3D stuff on a Xen machine?
A new ebuild popped up in official portage: xen-sources-2.6.16.28-r2 I already found a bug and reported it here: Bug 164946
(In reply to comment #81) > > what's with the Nvidia patch in the archive? > > do i still have to patch the > > contained nvidia-drivers? > > if so, how do i do that? > > Is it in order to have 3D stuff on a Xen machine? > on a desktop, why not? This way i can have gentoo and windows running side by side, together with 3D-graphics Hardware acceleration. I mean that's teh only reason Windows I want Windows, because of the Games. (and few other things, all requiring a nice Desktop). How do I patch the nvidia-drivers before I emerge the ebuild? go to the directory and run patch -p1 << the.patch ?
> on a desktop, why not? This way i can have gentoo and windows running side by > side, together with 3D-graphics Hardware acceleration. I mean that's teh only > reason Windows I want Windows, because of the Games. (and few other things, all > requiring a nice Desktop). > > How do I patch the nvidia-drivers before I emerge the ebuild? go to the > directory and run patch -p1 << the.patch ? > nevermind, the ebuild has the patch as well, and applies it itself.
I have committed a set of ebuilds (based in part on the ebuilds posted here) to my dev overlay. Browsable at: http://overlays.gentoo.org/dev/marineam/browser/xen And easily downloaded from: http://overlays.gentoo.org/svn/dev/marineam/xen/ Let me know if there are any problems. Note: I haven't even looked at 2.6.18 or the nvidia stuff.
Somehow I get the feeling that Debian will have 3.0.4 stable before we do... :>
That is entirely likely the xen ebuilds have never been marked stable in portage :-P I would like to push the stuff in my overlay into the portage tree before to long though, the only thing I'm unsure of at the moment are the kernel ebuilds. It might be possible that the weird xen patching process is overwriting some of the updates in 2.6.16.39. I haven't looked into it very closely though to see.
Yup, just compared the differences between applying xen to 2.6.16.39 as a patch and applying the xen sparse tree. Using the sparse tree some of the updates in .39 did get changed reverted. The .33 ebuild can still use the sparse tree but I'll have to switch other versions to using patches instead.
I still don't have access to suitable hardware for testing the xen 3.0.4 ebuilds, so if another dev has working (and tested) ebuilds, feel free to commit them and add yourself to the xen team.
(In reply to comment #85) > I have committed a set of ebuilds (based in part on the ebuilds posted here) to > my dev overlay. > > Browsable at: > http://overlays.gentoo.org/dev/marineam/browser/xen > And easily downloaded from: > http://overlays.gentoo.org/svn/dev/marineam/xen/ > > Let me know if there are any problems. > > Note: I haven't even looked at 2.6.18 or the nvidia stuff. > Any chance to get an entry in layman ?
(In reply to comment #90) > (In reply to comment #85) > > I have committed a set of ebuilds (based in part on the ebuilds posted here) to > > my dev overlay. > > > > Browsable at: > > http://overlays.gentoo.org/dev/marineam/browser/xen > > And easily downloaded from: > > http://overlays.gentoo.org/svn/dev/marineam/xen/ > > > > Let me know if there are any problems. > > > > Note: I haven't even looked at 2.6.18 or the nvidia stuff. > > > > Any chance to get an entry in layman ? > I'll look into getting it into the list, in the mean time just use do svn co http://overlays.gentoo.org/svn/dev/marineam/xen/
Ok, the overlay is in layman now. The name is marineam-xen.
Created an attachment (id=110436) [details] Patch to enable the vnclisten config variable xen-tools 3.0.4-1 removed a line that allowed the vnclisten option to be set on hvm doms. This patch adds the patch file to fix this and a call to epatch to the 3.0.4_p1 ebuild in the marineam-xen overlay. The patch submitted to xen on which this was based is in this post to xen-devel: http://comments.gmane.org/gmane.comp.emulators.xen.devel/35678
(In reply to comment #93) > Created an attachment (id=110436) [edit] [details] > Patch to enable the vnclisten config variable > > xen-tools 3.0.4-1 removed a line that allowed the vnclisten option to be set on > hvm doms. This patch adds the patch file to fix this and a call to epatch to > the 3.0.4_p1 ebuild in the marineam-xen overlay. The patch submitted to xen on > which this was based is in this post to xen-devel: > http://comments.gmane.org/gmane.comp.emulators.xen.devel/35678 > Thanks! Added to the overlay. I also added a 2.6.16.40 kernel.
I just upgraded from 3.0.0 to 3.0.4-1 (from http://overlays.gentoo.org/svn/dev/marineam/xen/) using kernel 2.6.16.40. Suddenly xend stopped using eth0 for the bridge and it wants to use eth1, I have to force this by adding: (network-script 'network-bridge netdev=eth0 bridge=xenbr0') in /etc/xen/xend-config.sxp This is very strange, and how does xend knows which one is default and what changed in the logic? @nd problem is the after xend starts and makes the bridge/peth0 my config of eth0 is lost, however this does not happen when if choose eth1 to make the bridge. Everything is running fine in production.
I just upgraded from 3.0.0 to 3.0.4-1 (from http://overlays.gentoo.org/svn/dev/marineam/xen/) using kernel 2.6.16.40. I'm running on Dell Poweredge 750. Xen hangs at "Freeing unused kernel memory" Is this related to the faq in xen-sources? Anyone can confirm this?? 6.2. Why does Fedora Core 3 stop working after printing the line "Freeing unused kernel memory: ..."? FC3 uses the new udev system for managing device nodes in /dev. To successfully boot, and to get any console output from init, you either need to manually create some device nodes or you need to load and run a suitable initrd. The former solution requires you to mount the root filesystem and then: # mknod /path/to/dev/null c 1 3 # mknod /path/to/dev/console c 5 1 If you instead wish to load an initrd file then you can use one provided in the /boot directory of your FC3 filesystem, or you can use the slightly-modified one that we supply. To load and run your initrd file, or to modify it, see this and this above. You may also want to disable X by editing /etc/inittab if you do not use X, or if X is configured incorrectly and is causing your boot to fail. To do this, change "id:5:initdefault:" to "id:3:initdefault:".
short amd64 modification, please add to ebuild: RDEPEND="x86? (sys-boot/grub) amd64? (sys-boot/grub-static) sys-kernel/xen-sources"
(In reply to comment #97) > short amd64 modification, please add to ebuild: > > RDEPEND="x86? (sys-boot/grub) > amd64? (sys-boot/grub-static) > sys-kernel/xen-sources" Please don't depend only on grub-static for amd64. Please make it grub || grub-static. BTW: grub (without -static) works fine on amd64.
Created an attachment (id=114574) [details] Kernel 2.6.20.4 with Xen 3.0.4 support I have new packages for Gentoo to compile Xen 3.0.4 Kernel 2.6.20.4 with Xen and Nvidia support. Feel free to include in the official Gentoo portage. Read INSTALL inside the archive for more info. Have Fun. Best Regards, Guy Baconniere
(In reply to comment #99) > I have new packages for Gentoo to compile Xen 3.0.4 > Kernel 2.6.20.4 with Xen and Nvidia support. Uh! I had to launch a Xen in production mode and because of this bug I had to choose another distribution. If some has time to feedback, it would be very nice.
Hi, refering to http://forums.gentoo.org/viewtopic-t-465367-start-25.html?sid=fcc2a130078a853dc43b3b8847502538 it would be very useful to add the squashfs kernel patch to xen-sources to save space and sync time in all XentooUs, and XentooO as well. How about adding it to the mainstream xen-source ebuild ?
That new kernel (2.6.20.4) compiles fine but refuses to boot here. I don't have a great deal of time to diagnose the problem - but here's a bit of output in case anyone feels like replicating: ------------[ cut here ]------------ kernel BUG at arch/x86_64/kernel/genapic_xen.c:34! invalid opcode: 0000 [1] SMP CPU 0 Pid: 1, comm: swapper Not tainted 2.6.20.4-xen0 #2 RIP: e030:[<ffffffff8026d7f2>] Initializing CPU#1 [<ffffffff8026d7f2>] xen_send_IPI_mask+0x7a/0xa2 RSP: e02b:ffff880000005de0 EFLAGS: 00010086 RAX: ffff8800010189a0 RBX: 0000000000000001 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000ffffffff RBP: 0000000000000001 R08: 0000000000000005 R09: 0000000000000000 R10: ffffffff80695000 R11: ffffffff8026d778 R12: 0000000000000000 R13: ffff880000796770 R14: 0000000000000001 R15: ffff8800010167a0 FS: 0000000000000000(0000) GS:ffffffff80695000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000000201000 CR4: 0000000000002620 Process swapper (pid: 1, threadinfo ffff880000004000, task ffff88000008f510) Stack: ffff880000005e00 0000000000000002 0000000000000000 ffff880000005e70 0000000000000000 ffffffff80245b92 0000000000000000 00000000804093a4 000000000000000f ffffffff00000000 ffff880001015110 0000000000000104 Call Trace: [<ffffffff80245b92>] try_to_wake_up+0x30c/0x374 [<ffffffff806c6987>] migration_call+0xde/0xee [<ffffffff8028a655>] notifier_call_chain+0x20/0x32 [<ffffffff806c83fc>] cpu_up+0xd4/0xf0 [<ffffffff802658e7>] init+0x8c/0x303 [<ffffffff80228b81>] schedule_tail+0x3d/0x9e [<ffffffff8025ca68>] child_rip+0xa/0x12 [<ffffffff8026585b>] init+0x0/0x303 [<ffffffff8025ca5e>] child_rip+0x0/0x12 Code: 0f 0b eb fe e8 e8 b7 19 00 48 ff c3 48 83 fb 04 75 c6 48 85 RIP [<ffffffff8026d7f2>] xen_send_IPI_mask+0x7a/0xa2 RSP <ffff880000005de0> <0>Kernel panic - not syncing: Attempted to kill init! <0>------------[ cut here ]------------ kernel BUG at arch/x86_64/kernel/genapic_xen.c:34! invalid opcode: 0000 [2] SMP CPU 0 Pid: 1, comm: swapper Not tainted 2.6.20.4-xen0 #2 RIP: e030:[<ffffffff8026d8ae>] [<ffffffff8026d8ae>] xen_send_IPI_shortcut+0x94/0x102 RSP: e02b:ffff880000005a88 EFLAGS: 00010086 RAX: ffff8800010189a0 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000001 RDI: 00000000ffffffff RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000030 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffffffff8026c9cf R14: 0000000000000001 R15: ffff8800010167a0 FS: 0000000000000000(0000) GS:ffffffff80695000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000000201000 CR4: 0000000000002620 Process swapper (pid: 1, threadinfo ffff880000004000, task ffff88000008f510) Stack: 0000000000000feb 0000000000000000 0000000000000001 ffffffff8026c938 ffffffff8026c9cf 0000000000000000 0000000000000000 ffffffff00000000 ffffffff805ce961 ffffffff805ce94a ffff88000008f510 0000000000000001 Call Trace: [<ffffffff8026c938>] __smp_call_function+0x5f/0x7e [<ffffffff8026c9cf>] smp_really_stop_cpu+0x0/0x10 [<ffffffff8026c97d>] smp_send_stop+0x26/0x4f [<ffffffff80281d13>] panic+0x94/0x13d [<ffffffff8021737a>] do_exit+0x7e/0x794 [<ffffffff803eaf72>] do_unblank_screen+0xd/0x119 [<ffffffff80266fa1>] kernel_math_error+0x0/0x90 [<ffffffff8026776d>] do_invalid_op+0xb1/0xbb [<ffffffff8026d7f2>] xen_send_IPI_mask+0x7a/0xa2 [<ffffffff8040923a>] unmask_evtchn+0x5a/0xd1 [<ffffffff8021c006>] vsnprintf+0x564/0x5a8 [<ffffffff80261f47>] error_exit+0x0/0x6e [<ffffffff8026d778>] xen_send_IPI_mask+0x0/0xa2 [<ffffffff8026d7f2>] xen_send_IPI_mask+0x7a/0xa2 [<ffffffff80245b92>] try_to_wake_up+0x30c/0x374 [<ffffffff806c6987>] migration_call+0xde/0xee [<ffffffff8028a655>] notifier_call_chain+0x20/0x32 [<ffffffff806c83fc>] cpu_up+0xd4/0xf0 [<ffffffff802658e7>] init+0x8c/0x303 [<ffffffff80228b81>] schedule_tail+0x3d/0x9e [<ffffffff8025ca68>] child_rip+0xa/0x12 [<ffffffff8026585b>] init+0x0/0x303 [<ffffffff8025ca5e>] child_rip+0x0/0x12 Code: 0f 0b eb fe e8 2c b7 19 00 48 ff c3 48 83 fb 04 74 58 eb b6 RIP [<ffffffff8026d8ae>] xen_send_IPI_shortcut+0x94/0x102 RSP <ffff880000005a88> <0>Kernel panic - not syncing: Attempted to kill init! <0>------------[ cut here ]------------ kernel BUG at arch/x86_64/kernel/genapic_xen.c:34! invalid opcode: 0000 [3] SMP CPU 0 Pid: 1, comm: swapper Not tainted 2.6.20.4-xen0 #2 RIP: e030:[<ffffffff8026d8ae>] [<ffffffff8026d8ae>] xen_send_IPI_shortcut+0x94/0x102 RSP: e02b:ffff880000005728 EFLAGS: 00010086 RAX: ffff8800010189a0 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000001 RDI: 00000000ffffffff RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000030 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffffffff8026c9cf R14: 0000000000000001 R15: ffff8800010167a0 FS: 0000000000000000(0000) GS:ffffffff80695000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000000201000 CR4: 0000000000002620 Process swapper (pid: 1, threadinfo ffff880000004000, task ffff88000008f510) Stack: 00000000000019d4 0000000000000000 0000000000000001 ffffffff8026c938 ffffffff8026c9cf 0000000000000000 0000000000000000 ffffffff00000000 ffffffff805ce961 ffffffff805ce94a ffff88000008f510 0000000000000001 Call Trace: [<ffffffff8026c938>] __smp_call_function+0x5f/0x7e [<ffffffff8026c9cf>] smp_really_stop_cpu+0x0/0x10 [<ffffffff8026c9a4>] smp_send_stop+0x4d/0x4f [<ffffffff80281d13>] panic+0x94/0x13d [<ffffffff8021737a>] do_exit+0x7e/0x794 [<ffffffff803eaf72>] do_unblank_screen+0xd/0x119 [<ffffffff80266fa1>] kernel_math_error+0x0/0x90 [<ffffffff8026c9cf>] smp_really_stop_cpu+0x0/0x10 [<ffffffff8026776d>] do_invalid_op+0xb1/0xbb [<ffffffff8026d8ae>] xen_send_IPI_shortcut+0x94/0x102 [<ffffffff8040bab3>] kcons_write_dom0+0x15/0x27 [<ffffffff80281e1a>] __call_console_drivers+0x5e/0x6c [<ffffffff80261ce3>] _spin_lock_irqsave+0x9/0x2b [<ffffffff80218f03>] release_console_sem+0x1c4/0x207 [<ffffffff8028260b>] vprintk+0x2d9/0x2e9 [<ffffffff80261f47>] error_exit+0x0/0x6e [<ffffffff8026c9cf>] smp_really_stop_cpu+0x0/0x10 [<ffffffff8026d8ae>] xen_send_IPI_shortcut+0x94/0x102 [<ffffffff8026d98d>] xen_send_IPI_allbutself+0x4a/0x68 [<ffffffff8026c938>] __smp_call_function+0x5f/0x7e [<ffffffff8026c9cf>] smp_really_stop_cpu+0x0/0x10 [<ffffffff8026c97d>] smp_send_stop+0x26/0x4f [<ffffffff80281d13>] panic+0x94/0x13d [<ffffffff8021737a>] do_exit+0x7e/0x794 [<ffffffff803eaf72>] do_unblank_screen+0xd/0x119 [<ffffffff80266fa1>] kernel_math_error+0x0/0x90 [<ffffffff8026776d>] do_invalid_op+0xb1/0xbb [<ffffffff8026d7f2>] xen_send_IPI_mask+0x7a/0xa2 [<ffffffff8040923a>] unmask_evtchn+0x5a/0xd1 [<ffffffff8021c006>] vsnprintf+0x564/0x5a8 [<ffffffff80261f47>] error_exit+0x0/0x6e [<ffffffff8026d778>] xen_send_IPI_mask+0x0/0xa2 [<ffffffff8026d7f2>] xen_send_IPI_mask+0x7a/0xa2 [<ffffffff80245b92>] try_to_wake_up+0x30c/0x374 [<ffffffff806c6987>] migration_call+0xde/0xee [<ffffffff8028a655>] notifier_call_chain+0x20/0x32 [<ffffffff806c83fc>] cpu_up+0xd4/0xf0 [<ffffffff802658e7>] init+0x8c/0x303 [<ffffffff80228b81>] schedule_tail+0x3d/0x9e [<ffffffff8025ca68>] child_rip+0xa/0x12 [<ffffffff8026585b>] init+0x0/0x303 [<ffffffff8025ca5e>] child_rip+0x0/0x12 Code: 0f 0b eb fe e8 2c b7 19 00 48 ff c3 48 83 fb 04 74 58 eb b6 RIP [<ffffffff8026d8ae>] xen_send_IPI_shortcut+0x94/0x102 RSP <ffff880000005728> <0>Kernel panic - not syncing: Attempted to kill init!
Same with me, AMD64... Code: 0f 0b 66 66 90 66 90 eb fe e8 e9 ab 16 00 48 ff c3 48 83 fb RIP [<ffffffff80214759>] xen_send_IPI_shortcut+0x99/0x120 RSP <ffff8800059c2c48> <0>Kernel panic - not syncing: Attempted to kill init! <0>------------[ cut here ]------------ kernel BUG at arch/x86_64/kernel/genapic_xen.c:34! invalid opcode: 0000 [7] SMP CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.20.4 #1 RIP: e030:[<ffffffff80214759>] [<ffffffff80214759>] xen_send_IPI_shortcut+0x99/0x120 RSP: e02b:ffff8800059c28c8 EFLAGS: 00010086 RAX: ffff8800018338c0 RBX: 0000000000000001 RCX: 0000000000000000 RDX: ffff88008127fec0 RSI: 0000000000000001 RDI: 00000000ffffffff RBP: ffffffff805b3a00 R08: 000000000000749f R09: 00000000ffffffff R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000001 R13: ffffffff802133e0 R14: 000000000000000b R15: ffff8800059c3e30 FS: 0000000000000000(0000) GS:ffffffff80564000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000000201000 CR4: 0000000000000660 Process swapper (pid: 1, threadinfo ffff8800059c2000, task ffff8800059c1510) Stack: 0000000000000001 0000000000000000 0000000000000000 ffffffff8021330b ffffffff802133e0 0000000000000000 0000000000000000 ffffffff00000000 ffffffff804c89ad ffffffff804c8996 ffff8800059c1510 0000000000000001 Call Trace: [<ffffffff8021330b>] __smp_call_function+0x6b/0xa0 [<ffffffff802133e0>] smp_really_stop_cpu+0x0/0x20 [<ffffffff80213392>] smp_send_stop+0x52/0x60 [<ffffffff8022d84d>] panic+0x8d/0x150 [<ffffffff8022e58e>] printk+0x4e/0x60 [<ffffffff80230bc3>] do_exit+0xc3/0x860 and so on. System is running fine with 2.6.18xen Kernel (also red had). Same configs with 2.6.20.4, but panic. Martin
Has anyone else been able to get headless VNC support working on Gentoo? I've set up both Gentoo32 and Gentoo64 DOM0 systems with the marineam xen overlay (Xen 3.04). On both systems when I start the domu, there is no VNC port opened on the Dom0 machine. VNC support is required in order to install a Windows server domu, and an Xserver domu on a headless server. I created a forum post for further discussion at http://forums.gentoo.org/viewtopic-t-551077-highlight-xen.html Thanks
(In reply to comment #99) > Created an attachment (id=114574) [edit] [details] > Kernel 2.6.20.4 with Xen 3.0.4 support > > I have new packages for Gentoo to compile Xen 3.0.4 > Kernel 2.6.20.4 with Xen and Nvidia support. this version does not compile for me: [...] AS arch/i386/kernel/vsyscall.o CC arch/i386/kernel/vm86.o CC arch/i386/kernel/early_printk.o CC arch/i386/kernel/fixup.o SYSCALL arch/i386/kernel/vsyscall-syms.o LD arch/i386/kernel/built-in.o AS arch/i386/kernel/head-xen.o arch/i386/kernel/head-xen.S: Assembler messages: arch/i386/kernel/head-xen.S:251: Error: too many positional arguments arch/i386/kernel/head-xen.S:253: Error: too many positional arguments make[1]: *** [arch/i386/kernel/head-xen.o] Error 1 make: *** [arch/i386/kernel] Error 2
Overdue status update for everyone watching this bug: Pushing 3.0.4 into portage is currently blocking on security bug #170917. The bug is related to fully virtualized guests and I won't have the hardware for that for another week or week and a half. If someone wants to help test things to get this moving a little sooner let me know via email or irc. I also have a report of an issue with HVM guests on amd64; until my new hardware arrives I am stuck with a x86 xen test box. I'm not going to let this issue block pushing it into portage and I'll work on fixing it as soon as I get the hardware. If anyone else wants to look into it though, go for it. Also note that I currently plan on only putting 2.6.16.y based kernels into portage. After I get the stuff currently in my overlay into portage I will start looking into getting a more modern kernel working as well and hopefully with fewer issues than the 2.6.20 kernel posted here. So sorry I didn't have much time to deal with xen up until now, but things should start moving soon! :-)
Roman, mind sharing your emerge --info with us...? seems to compile fine here.
(In reply to comment #107) > Roman, mind sharing your emerge --info with us...? seems to compile fine here. sure, here we go: Portage 2.1.2.2 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.5-r0, 2.6.16.39-xen i686) ================================================================= System uname: 2.6.16.39-xen i686 Intel(R) Pentium(R) D CPU 3.20GHz Gentoo Base System release 1.12.9 Timestamp of tree: Sat, 28 Apr 2007 11:20:01 +0000 ccache version 2.4 [enabled] dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.15-r1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe -mno-tls-direct-seg-refs" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=prescott -O2 -pipe -mno-tls-direct-seg-refs" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.inode.at/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="de_AT.utf8" LC_ALL="de_AT.utf8" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/php-testing /usr/portage/local/layman/ostefano /usr/portage/local/layman/marineam-xen /usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="acl bash-completion berkdb bzip2 cracklib crypt gdbm ncurses nls nptl pam readline shadow ssl tcpd unicode x86 zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="apm ark ati chips cirrus cyrix dummy fbdev glint i128 i740 i810 imstt mga neomagic nsc nv rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I finally committed xen 3.0.4_1 with linux 2.6.16.33 and 2.6.16.49. The .49 kernel should be pretty well off as far as security issues go. I have not yet put a .18 or .20 kernel into the tree yet, I'll need to do some work to get a kernel going that has fewer issues than the ones posted here appear to have. Give it a try and file bugs for any problems you find! :-)
(In reply to comment #109) > I finally committed xen 3.0.4_1 with linux 2.6.16.33 and 2.6.16.49. The .49 > kernel should be pretty well off as far as security issues go. I have not yet > put a .18 or .20 kernel into the tree yet, I'll need to do some work to get a > kernel going that has fewer issues than the ones posted here appear to have. > > Give it a try and file bugs for any problems you find! :-) > Hi, I installed linux-2.6.16.49-xen, started make defconfig and set some more Options: CONFIG_DVB=y CONFIG_DVB_CORE=y CONFIG_DVB_B2C2_FLEXCOP=m CONFIG_DVB_B2C2_FLEXCOP_PCI=m Here are the make-errors: ... drivers/built-in.o: In function `dvb_init': saa7134-dvb.c:(.text+0x8b6b3): undefined reference to `mt352_attach' saa7134-dvb.c:(.text+0x8b748): undefined reference to `nxt200x_attach' drivers/built-in.o: In function `mt352_aver777_init': saa7134-dvb.c:(.text+0x8c17a): undefined reference to `mt352_write' saa7134-dvb.c:(.text+0x8c195): undefined reference to `mt352_write' saa7134-dvb.c:(.text+0x8c1a6): undefined reference to `mt352_write' saa7134-dvb.c:(.text+0x8c1b7): undefined reference to `mt352_write' saa7134-dvb.c:(.text+0x8c1c8): undefined reference to `mt352_write' drivers/built-in.o:saa7134-dvb.c:(.text+0x8c1fb): more undefined references to `mt352_write' follow make: *** [.tmp_vmlinux1] Fehler 1 Dieter
(In reply to comment #110) > (In reply to comment #109) > > I finally committed xen 3.0.4_1 with linux 2.6.16.33 and 2.6.16.49. The .49 > > kernel should be pretty well off as far as security issues go. I have not yet > > put a .18 or .20 kernel into the tree yet, I'll need to do some work to get a > > kernel going that has fewer issues than the ones posted here appear to have. > > > > Give it a try and file bugs for any problems you find! :-) > > > Hi, > I installed linux-2.6.16.49-xen, started make defconfig and set some more > Options: > CONFIG_DVB=y > CONFIG_DVB_CORE=y > CONFIG_DVB_B2C2_FLEXCOP=m > CONFIG_DVB_B2C2_FLEXCOP_PCI=m > > Here are the make-errors: > ... > drivers/built-in.o: In function `dvb_init': > saa7134-dvb.c:(.text+0x8b6b3): undefined reference to `mt352_attach' > saa7134-dvb.c:(.text+0x8b748): undefined reference to `nxt200x_attach' > drivers/built-in.o: In function `mt352_aver777_init': > saa7134-dvb.c:(.text+0x8c17a): undefined reference to `mt352_write' > saa7134-dvb.c:(.text+0x8c195): undefined reference to `mt352_write' > saa7134-dvb.c:(.text+0x8c1a6): undefined reference to `mt352_write' > saa7134-dvb.c:(.text+0x8c1b7): undefined reference to `mt352_write' > saa7134-dvb.c:(.text+0x8c1c8): undefined reference to `mt352_write' > drivers/built-in.o:saa7134-dvb.c:(.text+0x8c1fb): more undefined references to > `mt352_write' follow > make: *** [.tmp_vmlinux1] Fehler 1 > > Dieter > Well, my recommendation is not use defconfig, I have no idea what settings are in that, or if it even defaults to a xen kernel. Do you need the dvb drivers? If not just disable it and we'll call it good, if you do I'll take a look and see if I can find a fix. Also, in the future please open a new bug for issues that crop up with xen and assign the bug to xen@gentoo.org instead of simply continuing this old bug.
i managed to get a similar crash as to http://bugs.gentoo.org/show_bug.cgi?id=151764#c103 using 2.6.20.4 xen-sources, looks like thats definitely b0rked all round atm :) Portage 2.1.2.6 (default-linux/amd64/2006.1, gcc-4.1.2, glibc-2.5-r2, 2.6.20-ck1 x86_64) ================================================================= System uname: 2.6.20-ck1 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz Gentoo Base System release 1.12.10 Timestamp of tree: Sat, 05 May 2007 16:20:01 +0000 ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.32 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=nocona -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.internode.on.net/pub/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage-overlays/layman/enlightenment /usr/local/portage-overlays/testing /usr/local/portage-overlays/testing-xen /usr/local/portage-overlays/spring" SYNC="rsync://10.100.10.1/gentoo-portage" USE="X acpi aim alsa amd64 apache2 audiofile avahi avi bash-completion berkdb big-tables bitmap-fonts bzip2 cairo canvas cdr cli cpdflib cracklib crypt cups curl dba dbus debug divx4linux dlloader dri dv dvb dvd dvdr dvdread ethereal exif extraengine fam ffmpeg firefox flac fortran gd gdbm gif gimpprint glut gmp gpm gtk gtk2 iconv icq idn imap innodb ipv6 isdnlog jabber java jpeg json kerberos lcms ldap libcaca libg++ logrotate mad mhash midi mng mono mozsvg mp3 mpeg mppe-mppc mysql mysqli ncurses nls nptl nptlonly nsplugin nvidia ogg opengl pam pcntl pcre pdf pear perl php png posix ppds pppd pulseaudio python readline reflection ruby samba sdl session slang snmp soap sockets spl sqlite ssl suhosin svg tcpd tiff truetype truetype-fonts type1-fonts unicode userlocales utf8 vorbis wddx wma xine xinerama xml xml2 xmlrpc xorg xosd xprint xsl xvid yahoo zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
