Package Details: xen 4.5.1-1

Git Clone URL: https://aur.archlinux.org/xen.git (read-only)
Package Base: xen
Description: Virtual Machine Hypervisor & Tools
Upstream URL: http://www.xenproject.org/
Licenses: GPL2
Conflicts: xen-4.2, xen-4.2-testing-hg, xen-4.3, xen-4.3-testing-hg, xen-gdbsx, xen-git, xen-hg-unstable, xen-rc
Submitter: sergej
Maintainer: kantras
Last Packager: kantras
Votes: 151
Popularity: 0.942718
First Submitted: 2009-11-09 11:22
Last Updated: 2015-07-04 23:45

Required by (0)

Sources (24)

Latest Comments

daniel_shub commented on 2016-04-04 16:22

Is your plan to create a xen-4.5 package and keep xen as the most current? If so, you might want to consider creating a xen-4.6 package at the same time. That way someone who wants to stay on the 4.x release, never has to change packages.

kantras commented on 2016-04-04 16:15

I'm actually finishing rebuilding the system I usually developed on, to be able to ramp back up again - I have been watching the comments, just been tied up with some work issues

daniel_shub commented on 2016-04-04 16:11

@frony0 I think it would be better to request to take over as maintainer instead of creating a new package. While having a xen-4.5 package wouldn't be bad, the xen package should track the latest version.

frony0 commented on 2016-04-04 15:57

BeepDog, perhaps post your version to aur under the name "xen-4.6", since kantras seems to be AWOL?

BeepDog commented on 2016-03-29 00:36

I used the 4.6.1 packages that @JohnTh provided on gitlab: https://gitlab.com/johnth/aur-xen/tree/master

Works great, but does not include pvgrub (I guess that's part of stubdom?) I've got a feature request open for grub2 in core to include the PvGrub2 stuff:
http://wiki.xen.org/wiki/PvGrub2
and
https://bugs.archlinux.org/task/44201

I'm gonna try to build a custom grub package real quick so I can use that pvgrub2, because it's supposed to be WAY better than pvgrub and pygrub.

vmaffione commented on 2016-03-17 21:46

I managed to compile it, by means of the following changes

1) do what hypernetoman suggests (removing a comment in a public header file)
2) applying this patch to PKGBUILD
--- PKGBUILD 2016-03-17 22:45:49.670416160 +0100
+++ PKGBUILD.old 2016-03-17 22:45:31.183750160 +0100
@@ -129,7 +129,7 @@ build() {
export CFLAGS=-fno-caller-saves
./autogen.sh
./configure PYTHON=/usr/bin/python2 --prefix=/usr --sbindir=/usr/bin --with-sysconfig-leaf-dir=conf.d --with-initddir=/etc/init.d \
- --enable-systemd --disable-docs --enable-stubdom --enable-qemu-traditional --enable-rombios \
+ --enable-systemd --disable-docs --disable-stubdom --enable-qemu-traditional --enable-rombios \
--with-extra-qemuu-configure-args="--disable-bluez --disable-gtk --enable-spice --enable-usb-redir" # --enable-ovmf
make LANG=C PYTHON=python2
}
@@ -147,6 +147,9 @@ package() {
install -Dm755 "$srcdir/09_xen" etc/grub.d/09_xen
install -Dm644 "$srcdir/efi-xen.cfg" etc/xen/efi-xen.cfg

+ mkdir -p usr/lib/systemd/system
+ cp $srcdir/$pkgname-$pkgver/tools/hotplug/Linux/systemd/xenstored* usr/lib/systemd/system
+
# Fix paths in scripts, move to right locations and create missing directories
sed -i 's:/var/run:/run:' etc/init.d/xencommons
sed -i 's:/var/lock:/run/lock:' etc/xen/scripts/hotplugpath.sh

lembang commented on 2016-03-01 20:56

@johnTh
by modifying the ferror it helps to compile the package, although this is not a real solution for this. Thank you.
I force the test to always return 0

JohnTh commented on 2016-02-29 22:09

I am also getting this error. It was not happening a week ago. Package updates have broken something.
The step that is failing is configuring stubdom/gmp-x86_64
Details are in stubdom/gmp-x86_64/config.log
The sizeof type test configure programs build fine, but when run, return 1 because ferror(...) returns 1 after fprintf(...) in the programs built in this Xen build environment. This stops the configure, thought the programs still seem to function as intended, putting type sizes in conftest.val.
Search for ferror in stubdom/gmp-x86_64/configure to show or modify the programs.
I am still looking into why and how to fix.

lembang commented on 2016-02-29 00:49

@malinas
Seems we encounter almost the same error, i have already use gcc-multilib and still experience this error. Any idea?

pacman -Q | grep gcc
gcc-libs-multilib 5.3.0-5
gcc-multilib 5.3.0-5
lib32-gcc-libs 5.3.0-5


checking size of unsigned short... configure: error: cannot compute sizeof (unsigned short)
See `config.log' for more details.
Makefile:170: recipe for target 'gmp-x86_64' failed
make[1]: *** [gmp-x86_64] Error 77
make[1]: Leaving directory '/home/the/aur/aur-xen-master-d1563f51708bc0cd58e989c7e9ab615254c66d6b/src/xen-4.6.1/stubdom'
Makefile:106: recipe for target 'install-stubdom' failed
make: *** [install-stubdom] Error 2
==> ERROR: A failure occurred in build().

malinas commented on 2016-02-26 19:38

ld -nostdlib -L/tmp/makepkg/xen/src/xen-4.6.1/stubdom/cross-root-x86_64/x86_64-xen-elf/lib -m elf_x86_64 -T arch/x86/minios-x86_64.lds /tmp/makepkg/xen/src/xen-4.6.1/stubdom/mini-os-x86_64-grub/mini-os.o -o /tmp/makepkg/xen/src/xen-4.6.1/stubdom/mini-os-x86_64-grub/mini-os
ld: warning: section `.bss' type changed to PROGBITS
gzip -f -9 -c /tmp/makepkg/xen/src/xen-4.6.1/stubdom/mini-os-x86_64-grub/mini-os >/tmp/makepkg/xen/src/xen-4.6.1/stubdom/mini-os-x86_64-grub/mini-os.gz
checking for suitable m4... m4
checking if m4wrap produces spurious output... no
checking how to switch to text section... .text
checking how to switch to data section... .data
checking for assembler label suffix... :
checking for assembler global directive... .globl
checking for assembler global directive attribute...
checking if globals are prefixed by underscore... no
checking how to switch to read-only data section... .section .rodata
checking for assembler .type directive... .type $1,@$2
checking for assembler .size directive... .size $1,$2
checking for assembler local label prefix... .L
checking for assembler byte directive... .byte
checking how to define a 32-bit word... .long
checking if .align assembly directive is logarithmic... no
checking if the .align directive accepts an 0x90 fill in .text... yes
checking for unsigned short... make[2]: Leaving directory '/tmp/makepkg/xen/src/xen-4.6.1/extras/mini-os'
install -d -m0755 -p "/tmp/makepkg/xen/src/xen-4.6.1/dist/install/usr/lib/xen/boot"
install -m0644 -p mini-os-x86_64-grub/mini-os.gz "/tmp/makepkg/xen/src/xen-4.6.1/dist/install/usr/lib/xen/boot/pv-grub-x86_64.gz"
yes
checking size of unsigned short... configure: error: cannot compute sizeof (unsigned short)
See `config.log' for more details.
Makefile:170: recipe for target 'gmp-x86_64' failed
make[1]: *** [gmp-x86_64] Error 77
make[1]: *** Waiting for unfinished jobs....
ar rcs qemu.a vl.o osdep.o monitor.o pci.o loader.o isa_mmio.o machine.o dma-helpers.o virtio.o virtio-blk.o virtio-net.o virtio-console.o fw_cfg.o block-raw-posix.o lsi53c895a.o esp.o usb-ohci.o eeprom93xx.o eepro100.o ne2000.o pcnet.o rtl8139.o e1000.o msmouse.o ide.o pckbd.o ps2.o vga.o dma.o fdc.o mc146818rtc.o serial.o i8259.o i8254.o pc.o cirrus_vga.o parallel.o piix_pci.o usb-uhci.o hpet.o device-hotplug.o pci-hotplug.o piix4acpi.o xenstore.o xen_platform.o xen_machine_fv.o xen_machine_pv.o xen_backend.o xenfb.o xen_console.o exec-dm.o pci_emulation.o helper2.o battery_mgmt.o xenfbfront.o pass-through.o pt-msi.o pt-graphics.o block-vbd.o
make[3]: Leaving directory '/tmp/makepkg/xen/src/xen-4.6.1/stubdom/ioemu/i386-stubdom'
make[2]: Leaving directory '/tmp/makepkg/xen/src/xen-4.6.1/stubdom/ioemu'
make[1]: Leaving directory '/tmp/makepkg/xen/src/xen-4.6.1/stubdom'
Makefile:106: recipe for target 'install-stubdom' failed
make: *** [install-stubdom] Error 2

that's the master one. config.log exit status 0. I guess, I will just update my own 4.6 build from a year ago.

malinas commented on 2016-02-26 18:18

John, that is nice.. i already patched the broken pakcages back in Feb 2015, and actually ran a 4.6 unstable branch back then. However, server ben down some months and after update, I can't for the love of my life make xen see the LVM root on boot :/ I will give yours a try and cross my fingers! ,p

JohnTh commented on 2016-02-19 11:51

Hi,

I have been having go updating the Xen AUR to latest versions (4.5.2 and 4.6.1) with most XSA patches. The files are here:
https://gitlab.com/johnth/aur-xen/tree/xen-4.5
https://gitlab.com/johnth/aur-xen/tree/master
Both branches should build without error using multilib-build, but are not well tested.
These include ovmf and xen.efi.

Let me know any suggestions.

hypernetoman commented on 2016-02-18 20:47

Hello!

I was getting a compilation error both with xen-4.5.1 and xen-4.4.2 (packages xen and xen-4.4, resp.):

gcc -E ... -o compat/grant_table.i compat/grant_table.c
compat/grant_table.c:33:1: error: unterminated comment
/*
^
compat/grant_table.c:28:0: error: unterminated #ifndef
#ifndef __XEN_PUBLIC_GRANT_TABLE_H__
^
Makefile:61: recipe for target 'compat/grant_table.i' failed
make[3]: *** [compat/grant_table.i] Error 1



I've fixed it by adding this in the PKGBUILD previous to `make LANG=C PYTHON=python2` in build():
`sed -i.backup '33,54d' xen/include/public/grant_table.h`

It removes the offendig block comment which prevents compilation.
It fixes it for me both in xen and xen-4.4.

Hope it helps.

mnovick1988 commented on 2016-02-18 06:49

KamijouTouma: did you look at Config.log, sounds more like a env-var issue. not a makepkg issue.

KamijouTouma commented on 2016-01-18 08:12

checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... i686-xen-elf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
Makefile:83: recipe for target 'cross-root-i686/i686-xen-elf/lib/libc.a' failed
make[1]: *** [cross-root-i686/i686-xen-elf/lib/libc.a] Error 77
make[1]: Leaving directory '/tmp/yaourt-tmp-kami/aur-xen/src/xen-4.5.1/stubdom'
Makefile:73: recipe for target 'install-stubdom' failed
make: *** [install-stubdom] Error 2
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build xen.
==> Restart building xen ? [y/N]

alaricljs commented on 2016-01-05 22:09

Recently did an orphaned package cleanup and lost a couple of xen-required libs:

#> pacman -Qi vde2 libnl |egrep "Name|Required"
Name : vde2
Required By : None
Name : libnl
Required By : libpcap


Without libnl 'xl -list' doesn't work (and no doubt more)
Without vde2 hvm VMs don't work

jakogut commented on 2015-12-21 22:36

It seems binutils dropped support for PE binary linking, which broke the EFI binary generation in the Xen build process. The Fedora guys made a patch to replace it with mingw64, which you can find here:

https://github.com/jakogut/xen-igvtg-aur/blob/master/xen_efi_build.patch

kline commented on 2015-12-17 04:19

Did the xen-syms changes get worked into i686?
Xen won't build right now on a pretty clean Arch install: http://pastebin.com/raw/SkCgkpNh

baratharon commented on 2015-11-30 07:09

I can compile and install it, thanks!
Tested on up-to-date Arch x86_64.

BuLLeKeUp commented on 2015-11-29 19:47

If you want to try with the latest Xen release (4.5.2) and an updated PKGBUILD, I've put my modifications on my personal website and I'm waiting for feedback before requesting merging.

It may solve some building issues encountered before and also enables OVMF support (tested on an Ubuntu 15.10 VM).

https://www.bullekeup.net/files/arch/packages/xen/srctarballs/

xen-ovmf packages are intended for people who want a standard Bios Xen boot, xen-efi is for people who want to actually boot xen via efi.
Last one needs a PEP enabled binutils, which PKGBUILD is available here :

https://www.bullekeup.net/files/arch/packages/binutils-pep/srctarballs/

baratharon commented on 2015-11-22 18:01

Still, failed to build the package:

checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... i686-xen-elf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
Makefile:83: recipe for target 'cross-root-i686/i686-xen-elf/lib/libc.a' failed
make[1]: *** [cross-root-i686/i686-xen-elf/lib/libc.a] Error 77
make[1]: Leaving directory '/home/build/xen/src/xen-4.5.1/stubdom'
Makefile:73: recipe for target 'install-stubdom' failed
make: *** [install-stubdom] Error 2
==> ERROR: A failure occurred in build().
Aborting...

BuLLeKeUp commented on 2015-11-11 00:44

@ImATiger :
I'm unable to reproduce the problem you encounter... I just have rebuild xen from scratch, just to be sure, no problem... Maybe a network problem ? (proxy, DNS, ...)

@ata :
You need to apply the patch supplied earlier (see previous comments) in order to be able to compile 32 bit executables. Or you can apply this patch for the PKGBUILD, with build dependencies on each package instead of multilib-devel meta package:

--- PKGBUILD 2015-07-05 01:43:49.000000000 +0200
+++ PKGBUILD_new 2015-11-11 01:32:11.575921000 +0100
@@ -14,6 +14,7 @@
depends=(bridge-utils curl gnutls iproute2 libaio libcap-ng libiscsi libjpeg-turbo libpng libseccomp lzo2 nss pixman pciutils python python2 sdl yajl spice usbredir)
[[ "$CARCH" == "x86_64" ]] && depends+=(lib32-glibc)
makedepends=(bin86 cmake dev86 git iasl markdown ocaml-findlib figlet wget spice-protocol)
+[[ "$CARCH" == "x86_64" ]] && makedepends+=(gcc-multilib lib32-fakeroot lib32-libltdl)
optdepends=('xen-docs: Official Xen Documentation' 'openvswitch: Optional Networking support')
conflicts=(xen-4.2{,-testing-hg} xen-{gdbsx,hg-unstable,rc,git} xen-4.3{,-testing-hg})
backup=(etc/modules-load.d/$pkgname.conf etc/$pkgname/xl.conf etc/conf.d/xen{stored,consoled,domains,commons} etc/$pkgname/grub.conf)

@cokomoko :
Have you enough RAM available to compile the package ? I had issues in the past with many packages because they were to heavy to be compiled in RAM and since yaourt works in RAM by default (tmpfs)... Maybe try compiling the package yourself outside /tmp ?

If this is not the problem, I don't think it is linked with makepkg / AUR system (I personally have successfully build this package several times). Maybe try searching in Xen mailing lists, and report your issue upstream if needed.

ImATiger commented on 2015-11-10 04:26

I've been trying to build xen for a couple days. It times out trying to download from xenbits.xen.org.
This is just to inform anyone who can fix it.

ata commented on 2015-11-08 16:47

checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... i686-xen-elf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
Makefile:83: recipe for target 'cross-root-i686/i686-xen-elf/lib/libc.a' failed
make[1]: *** [cross-root-i686/i686-xen-elf/lib/libc.a] Error 77
make[1]: Leaving directory '/tmp/yaourt-tmp-ata/aur-xen/src/xen-4.5.1/stubdom'
Makefile:73: recipe for target 'install-stubdom' failed
make: *** [install-stubdom] Error 2
==> HATA: build() içinde bir hata oluştu.
Çıkılıyor...
==> HATA:makepkg xen'i inşa edemedi.

cokomoko commented on 2015-11-03 23:39

My system updated
But it's a problem compilation:

make[6]: Entering directory '/tmp/yaourt-tmp-cokomoko/aur-xen/src/xen-4.5.1/tools/firmware/seabios-dir-remote'
Building ld scripts
Version: rel-1.7.5-0-ge51488c-dirty-20151104_014113-cokomoko
Traceback (most recent call last):
File "./scripts/layoutrom.py", line 709, in <module>
main()
File "./scripts/layoutrom.py", line 671, in main
info16 = parseObjDump(infile16, '16')
File "./scripts/layoutrom.py", line 586, in parseObjDump
relocsection = sectionmap[sectionname]
KeyError: '.text.asm./tmp/yaourt-tmp-cokomoko/aur-xen/src/xen-4.5.1/tools/firmware/seabios-dir-remote/src/fw/smp.c.79'
Makefile:155: recipe for target 'out/romlayout16.lds' failed
make[6]: *** [out/romlayout16.lds] Error 1
make[6]: Leaving directory '/tmp/yaourt-tmp-cokomoko/aur-xen/src/xen-4.5.1/tools/firmware/seabios-dir-remote'
/tmp/yaourt-tmp-cokomoko/aur-xen/src/xen-4.5.1/tools/firmware/../../tools/Rules.mk:116: recipe for target 'subdir-all-seabios-dir' failed
make[5]: *** [subdir-all-seabios-dir] Error 2
make[5]: Leaving directory '/tmp/yaourt-tmp-cokomoko/aur-xen/src/xen-4.5.1/tools/firmware'
/tmp/yaourt-tmp-cokomoko/aur-xen/src/xen-4.5.1/tools/firmware/../../tools/Rules.mk:111: recipe for target 'subdirs-all' failed
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory '/tmp/yaourt-tmp-cokomoko/aur-xen/src/xen-4.5.1/tools/firmware'
Makefile:38: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory '/tmp/yaourt-tmp-cokomoko/aur-xen/src/xen-4.5.1/tools/firmware'
/tmp/yaourt-tmp-cokomoko/aur-xen/src/xen-4.5.1/tools/../tools/Rules.mk:116: recipe for target 'subdir-install-firmware' failed
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory '/tmp/yaourt-tmp-cokomoko/aur-xen/src/xen-4.5.1/tools'
/tmp/yaourt-tmp-cokomoko/aur-xen/src/xen-4.5.1/tools/../tools/Rules.mk:111: recipe for target 'subdirs-install' failed
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory '/tmp/yaourt-tmp-cokomoko/aur-xen/src/xen-4.5.1/tools'
Makefile:69: recipe for target 'install-tools' failed
make: *** [install-tools] Error 2
==> HATA: build() içinde bir hata oluştu.
Çıkılıyor...
==> HATA:makepkg xen'i inşa edemedi.
==> xen yeniden inşa edilsin mi ? [e/H]
==> -----------------------------------
==>

kantras commented on 2015-11-03 22:56

FYI - I've been trying to free up some cycles in my spare time to go in and fix a number of things; more updates to follow

BuLLeKeUp commented on 2015-11-03 22:42

@cokomoko

The bug you have is an old one (see http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01687.html)

It was related to a misdeclared array in symbols.c : symbols_offsets array was declared with a size of 4 bytes (an integer, even on 64 bit machines by default),
triggering a warning / error on accesses bellow that size when building w/ some compilers (which is normal).
But it has been patched since then (verified in current source tarball)

I just builded Xen 4.5.1 on a fresh installed Arch (using patch provided before) without problem.

May be try updating your system and do a clean build of the package ?

cokomoko commented on 2015-11-03 22:07

@BuLLeKeUp

Makefile:128: recipe for target 'out/src/stacks.o' failed
make[6]: *** [out/src/stacks.o] Error 1
make[6]: Leaving directory '/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.1/tools/firmware/seabios-dir-remote'
/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.1/tools/firmware/../../tools/Rules.mk:116: recipe for target 'subdir-all-seabios-dir' failed
make[5]: *** [subdir-all-seabios-dir] Error 2
make[5]: Leaving directory '/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.1/tools/firmware'
/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.1/tools/firmware/../../tools/Rules.mk:111: recipe for target 'subdirs-all' failed
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory '/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.1/tools/firmware'
Makefile:38: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory '/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.1/tools/firmware'
/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.1/tools/../tools/Rules.mk:116: recipe for target 'subdir-install-firmware' failed
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory '/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.1/tools'
/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.1/tools/../tools/Rules.mk:111: recipe for target 'subdirs-install' failed
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory '/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.1/tools'
Makefile:69: recipe for target 'install-tools' failed
make: *** [install-tools] Error 2
==> HATA: build() içinde bir hata oluştu.
Çıkılıyor...

BuLLeKeUp commented on 2015-11-03 21:43

As ephreal and daniel_shub pointed out, multilib-devel meta package is needed to compile xen on x86_64 systems, so here is a patch for the PKGBUILD to add this build dependency on x86_64 systems.

--- PKGBUILD 2015-07-05 01:43:49.000000000 +0200
+++ PKGBUILD_new 2015-11-03 22:27:20.542693000 +0100
@@ -14,6 +14,7 @@
depends=(bridge-utils curl gnutls iproute2 libaio libcap-ng libiscsi libjpeg-turbo libpng libseccomp lzo2 nss pixman pciutils python python2 sdl yajl spice usbredir)
[[ "$CARCH" == "x86_64" ]] && depends+=(lib32-glibc)
makedepends=(bin86 cmake dev86 git iasl markdown ocaml-findlib figlet wget spice-protocol)
+[[ "$CARCH" == "x86_64" ]] && makedepends+=(multilib-devel)
optdepends=('xen-docs: Official Xen Documentation' 'openvswitch: Optional Networking support')
conflicts=(xen-4.2{,-testing-hg} xen-{gdbsx,hg-unstable,rc,git} xen-4.3{,-testing-hg})
backup=(etc/modules-load.d/$pkgname.conf etc/$pkgname/xl.conf etc/conf.d/xen{stored,consoled,domains,commons} etc/$pkgname/grub.conf)

cokomoko commented on 2015-11-03 18:49

please update package:

symbols.c: In function 'symbols_lookup':
symbols.c:23:61: hata: array subscript is above array bounds [-Werror=array-bounds]
#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
^
symbols.c:128:47: bilgi: in expansion of macro 'symbols_address'
while (low && symbols_address(low - 1) == symbols_address(low))
^
symbols.c:23:61: hata: array subscript is above array bounds [-Werror=array-bounds]
#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
^
symbols.c:136:13: bilgi: in expansion of macro 'symbols_address'
if (symbols_address(i) > symbols_address(low)) {
^
cc1: all warnings being treated as errors
/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.0/xen/Rules.mk:168: recipe for target 'symbols.o' failed
make[4]: *** [symbols.o] Error 1
make[4]: Leaving directory '/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.0/xen/common'
/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.0/xen/Rules.mk:156: recipe for target '/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.0/xen/common/built_in.o' failed
make[3]: *** [/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.0/xen/common/built_in.o] Error 2
make[3]: Leaving directory '/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.0/xen/arch/x86'
Makefile:100: recipe for target '/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.0/xen/xen' failed
make[2]: *** [/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.0/xen/xen] Error 2
make[2]: Leaving directory '/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.0/xen'
Makefile:26: recipe for target 'install' failed
make[1]: *** [install] Error 2
make[1]: Leaving directory '/tmp/yaourt-tmp-cokomoko/xen/src/xen-4.5.0/xen'
Makefile:65: recipe for target 'install-xen' failed
make: *** [install-xen] Error 2
==> HATA: build() içinde bir hata oluştu.
Çıkılıyor...

ephreal commented on 2015-10-26 20:13

I just want to add that gcc_multilib is indeed necessary to build the package. I was trying to build for a day or two, and with the errors that I was getting, everything led to gcc not being 32 bit capable. So, as daniel_shub pointed out, I tried installing gcc_multilib. With that, the making of xen proceeded flawlessly.

phg commented on 2015-10-22 05:51

Btw. I traced it down to the invocation of ``autogen.sh``
in ``build()``: If I comment that line, the package again
builds and installs flawlessly.

Since the package builds nicely without, is there any
real need for calling autotools explicitly instead of
just using the configure scripts that ship with the source?

phg commented on 2015-10-21 18:33

The build fails somewhere inside the Grub part of stubdom with the weirdest
compiler error ever. For reference, I’ll cite it in full:

mkdir -p grub-x86_64
CPPFLAGS="-isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/posix -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../tools/xenstore/include -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/x86 -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/posix -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/lwip-x86_64/src/include -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/lwip-x86_64/src/include/ipv4 -I/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/include -I/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../xen/include" CFLAGS="-mno-red-zone -fno-caller-saves -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -fno-stack-protector -fno-exceptions" make DESTDIR= -C grub OBJ_DIR=/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub-x86_64
make[2]: Entering directory '/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub'
gcc -c -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/posix -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../tools/xenstore/include -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/x86 -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/posix -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/lwip-x86_64/src/include -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/lwip-x86_64/src/include/ipv4 -I/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/include -I/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../xen/include -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../extras/mini-os/include/posix -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../tools/xenstore/include -I/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../tools/libxc/include -I/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../tools/include -I. -I../grub-upstream/stage1 -I../grub-upstream/stage2 -I../grub-upstream/netboot -I/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../tools/firmware/vgabios -DWITHOUT_LIBC_STUBS -DSUPPORT_NETBOOT -DSUPPORT_GRAPHICS -DSUPPORT_SERIAL -DPRESET_MENU_STRING='""' -DPACKAGE='"grubdom"' -DVERSION='"0.97"' -D__ASSEMBLY__ -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../extras/mini-os/include/x86 -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../extras/mini-os/include/x86/x86_64 -DFSYS_TFTP=1 -DFSYS_EXT2FS=1 -DFSYS_FAT=1 -DFSYS_FFS=1 -DFSYS_ISO9660=1 -DFSYS_JFS=1 -DFSYS_MINIX=1 -DFSYS_REISERFS=1 -DFSYS_UFS2=1 -DFSYS_VSTAFS=1 -DFSYS_XFS=1 -mno-red-zone -fno-caller-saves -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -fno-stack-protector -fno-exceptions -O1 -fno-omit-frame-pointer -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs boot-x86_64.S -o /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub-x86_64/boot-x86_64.o
mkdir -p /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub-x86_64/netboot /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub-x86_64/stage2
touch /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub-x86_64/dirs
gcc -c -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/posix -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../tools/xenstore/include -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/x86 -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/posix -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/lwip-x86_64/src/include -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/lwip-x86_64/src/include/ipv4 -I/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/include -I/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/../xen/include -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../extras/mini-os/include/posix -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../tools/xenstore/include -I/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../tools/libxc/include -I/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../tools/include -I. -I../grub-upstream/stage1 -I../grub-upstream/stage2 -I../grub-upstream/netboot -I/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../tools/firmware/vgabios -DWITHOUT_LIBC_STUBS -DSUPPORT_NETBOOT -DSUPPORT_GRAPHICS -DSUPPORT_SERIAL -DPRESET_MENU_STRING='""' -DPACKAGE='"grubdom"' -DVERSION='"0.97"' -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../extras/mini-os/include/x86 -isystem /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub/../../extras/mini-os/include/x86/x86_64 -DFSYS_TFTP=1 -DFSYS_EXT2FS=1 -DFSYS_FAT=1 -DFSYS_FFS=1 -DFSYS_ISO9660=1 -DFSYS_JFS=1 -DFSYS_MINIX=1 -DFSYS_REISERFS=1 -DFSYS_UFS2=1 -DFSYS_VSTAFS=1 -DFSYS_XFS=1 -mno-red-zone -fno-caller-saves -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -fno-stack-protector -fno-exceptions -O1 -fno-omit-frame-pointer -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs ../grub-upstream/netboot/fsys_tftp.c -o /home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub-x86_64/netboot/fsys_tftp.o
In file included from ../grub-upstream/netboot/etherboot.h:34:0,
from ../grub-upstream/netboot/fsys_tftp.c:34:
../grub-upstream/netboot/fsys_tftp.c: In function ‘send_rrq’:
../grub-upstream/stage2/shared.h:44:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
# define RAW_ADDR(x) ((x) + (int) grub_scratch_mem)
^
../grub-upstream/stage2/shared.h:92:18: note: in expansion of macro ‘RAW_ADDR’
#define FSYS_BUF RAW_ADDR (0x68000)
^
../grub-upstream/netboot/fsys_tftp.c:271:18: note: in expansion of macro ‘FSYS_BUF’
buf = (char *) FSYS_BUF;
^
../grub-upstream/netboot/fsys_tftp.c: In function ‘buf_fill’:
../grub-upstream/netboot/fsys_tftp.c:258:1: error: extended registers have no high halves
}
^
Makefile:79: recipe for target '/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub-x86_64/netboot/fsys_tftp.o' failed
make[2]: *** [/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub-x86_64/netboot/fsys_tftp.o] Error 1
make[2]: Leaving directory '/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom/grub'
Makefile:406: recipe for target 'grub' failed
make[1]: *** [grub] Error 2
make[1]: Leaving directory '/home/build/src/makepkg-tmp/xen/src/xen-4.5.1/stubdom'
Makefile:73: recipe for target 'install-stubdom' failed
make: *** [install-stubdom] Error 2
==> ERROR: A failure occurred in build().
Aborting...


Interestingly, the package built without trouble inside an Arch VM I set up at
work. Also, the vanilla xen-4.5.1 source itself builds nicely, even with the
same configure options. Something about this PKGBUILD makes the build error out
as above.

trixpan commented on 2015-10-17 18:55

multilib sorted compiling issues in here as well.

However, after a successful build I had:

Blank xenstore after boot (visible by Dom0 showing up as null)

Unable to start any VM with a NIC.

NicolasCPA commented on 2015-10-13 05:23

@zootboy: Thanks.

zootboy commented on 2015-10-13 04:46

@NicolasCPA: Yaourt uses /tmp as its build dir. Arch defaults to making this a ramdrive. If there isn't enough space available to do a full build, redirect yaourt's build dir to a disk instead.

kantras commented on 2015-08-31 15:41

This is on my list of enhancements, that will be coming soon

daniel_shub commented on 2015-08-31 14:56

The update to spice-protcol got me around the first error I was having. I then ran into the error reported by piwwo. I got around that by installing gcc-multilib instead of the standard gcc. I think the makedepends should be updated to include gcc-multilib as an explicit dependency. I think the AUR guidelines state that the base-devel group can be expected, but gcc-multilib is part of the multilib-devel group.

pdc commented on 2015-08-29 13:13

It compiled for me with the latest version of spice-protocol (0.12.9-1).

daniel_shub commented on 2015-08-24 22:31

I am unable to build the package in an clean x86_64 chroot:

ERROR: User requested feature spice
configure was not able to find it.
Install spice-server and spice-protocol devel

make[3]: Entering directory '/build/xen/src/xen-4.5.1/tools/qemu-xen-dir'
make[3]: *** No rule to make target 'all'. Stop.
make[3]: Leaving directory '/build/xen/src/xen-4.5.1/tools/qemu-xen-dir'
Makefile:201: recipe for target 'subdir-all-qemu-xen-dir' failed
make[2]: *** [subdir-all-qemu-xen-dir] Error 2
make[2]: Leaving directory '/build/xen/src/xen-4.5.1/tools'
/build/xen/src/xen-4.5.1/tools/../tools/Rules.mk:111: recipe for target 'subdirs-install' failed
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory '/build/xen/src/xen-4.5.1/tools'
Makefile:69: recipe for target 'install-tools' failed
make: *** [install-tools] Error 2

jakogut commented on 2015-08-13 21:40

The package failed to build for me with an error about not finding SPICE, even though I had spice-protocol installed from the official repos. It works with spice-protocol-git from the AUR.

Timizki commented on 2015-08-13 16:02

By changing gcc to gcc-multilib I get past those errors in newlib-x86_32 module. Which where actually linking error (/usr/bin/ld: cannot find -lgcc) not compile errors, if I understands correctly.

Timizki commented on 2015-08-13 15:17

The actual problem is not those "unrecognized command line option -V"
"unrecognized command line option -qversion" errors but the compile error in the newlib-x86_32 module. Atleast in x86_64 arch.

My config.log file taken from newlib-x86_32 build can be found at http://pastebin.com/HHPMeTPx

risk commented on 2015-08-10 08:31

There are 2 issues I ran into
1) It couldn't find spice-protocol-devel.
workaround: disabled spice protocol in PKGBUILD
2) configure on stubdom failed, due to GCC being too new.
"unrecognized command line option -V"
"unrecognized command line option -qversion"

alaviss commented on 2015-08-06 14:33

Compile checking out/src/stacks.o
src/stacks.c:226:5: warning: 'call16big' is static but used in inline function 'farcall16big' which is not static
call16big((u32)callregs - StackSeg * 16, StackSeg, _cfunc16__farcall16);
^
src/stacks.c:219:5: warning: 'call16' is static but used in inline function 'farcall16' which is not static
call16((u32)callregs - StackSeg * 16, StackSeg, _cfunc16__farcall16);
^
src/stacks.c: In function 'run_thread':
src/stacks.c:342:5: error: 'asm' operand has impossible constraints
asm volatile(
^
Makefile:128: recipe for target 'out/src/stacks.o' failed
make[6]: *** [out/src/stacks.o] Error 1
make[6]: Leaving directory '/tmp/yaourt-tmp-lrz/aur-xen/src/xen-4.5.1/tools/firmware/seabios-dir-remote'
/tmp/yaourt-tmp-lrz/aur-xen/src/xen-4.5.1/tools/firmware/../../tools/Rules.mk:116: recipe for target 'subdir-all-seabios-dir' failed
make[5]: *** [subdir-all-seabios-dir] Error 2
make[5]: Leaving directory '/tmp/yaourt-tmp-lrz/aur-xen/src/xen-4.5.1/tools/firmware'
/tmp/yaourt-tmp-lrz/aur-xen/src/xen-4.5.1/tools/firmware/../../tools/Rules.mk:111: recipe for target 'subdirs-all' failed
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory '/tmp/yaourt-tmp-lrz/aur-xen/src/xen-4.5.1/tools/firmware'
Makefile:38: recipe for target 'all' failed
make[3]: *** [all] Error 2
make[3]: Leaving directory '/tmp/yaourt-tmp-lrz/aur-xen/src/xen-4.5.1/tools/firmware'
/tmp/yaourt-tmp-lrz/aur-xen/src/xen-4.5.1/tools/../tools/Rules.mk:116: recipe for target 'subdir-install-firmware' failed
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory '/tmp/yaourt-tmp-lrz/aur-xen/src/xen-4.5.1/tools'
/tmp/yaourt-tmp-lrz/aur-xen/src/xen-4.5.1/tools/../tools/Rules.mk:111: recipe for target 'subdirs-install' failed
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory '/tmp/yaourt-tmp-lrz/aur-xen/src/xen-4.5.1/tools'
Makefile:69: recipe for target 'install-tools' failed
make: *** [install-tools] Error 2

I hit this error while compiling Xen on Arch Linux x86_64 with [testing] enabled

nocko commented on 2015-08-04 16:59

Updated spice-protocol 0.12.9 PKGBUILD:

# $Id$
# Maintainer: Sergej Pupykin <pupykin.s+arch@gmail.com>
# Maintainer: Patryk Kowalczyk < patryk at kowalczyk dot ws>

pkgname=spice-protocol
pkgver=0.12.9
pkgrel=1
pkgdesc="Headers for SPICE protocol"
arch=(any)
url="http://spice-space.org"
license=('BSD' 'LGPL2.1')
source=(http://spice-space.org/download/releases/$pkgname-$pkgver.tar.bz2)

build() {
cd "$srcdir/$pkgname-$pkgver"
./configure --prefix=/usr
make
}

package() {
cd "$srcdir/$pkgname-$pkgver"
make DESTDIR="$pkgdir/" install
install -Dm644 COPYING "$pkgdir/usr/share/licenses/$pkgname/COPYING"
}
md5sums=('893d9940cd34428f92997f4b634484d3')

nocko commented on 2015-08-04 15:58

New spice-protocol released that fixes spice problem (http://www.spice-space.org/download/releases/spice-protocol-0.12.9.tar.bz2)... the package has been flagged out-of-date. With any luck, the packager will get to repackaging soon.

kantras commented on 2015-08-01 20:43

@polyzium: Known issue with the most recent version of spice-protocol - disable for now

ArthurBorsboom commented on 2015-08-01 16:33

Read below...

polyzium commented on 2015-08-01 14:59

After solving "i have no idea" problem, the compiling still fails.

"ERROR: User requested feature spice
configure was not able to find it.
Install spice-server and spice-protocol devel"

I have spice and spice-protocol installed

polyzium commented on 2015-08-01 14:33

Xen fails to compile. I have no idea why.
http://pastebin.com/r4Rmrjah

polyzium commented on 2015-08-01 14:33

Xen fails to compile with gcc-multilib.
I have no idea why.
http://pastebin.com/r4Rmrjah

ArthurBorsboom commented on 2015-07-23 08:50

@piwwo, I did the same.

piwwo commented on 2015-07-23 08:28

Ok that works for me with multilib, however not with spice, not even with spice-protocol-git. I removed spice from config for now.

pacman -Q spice spice-protocol-git
spice 0.12.5-1
spice-protocol-git 20121019-2

kantras commented on 2015-07-21 13:29

@piwwo: gcc-multilib (plus the the associated packages) are a part of the official 'multilib' repository; this repository contains a number of things including 32 bit versions of several support libraries. You should be able to edit /etc/pacman.conf and uncomment the section for multilib to enable it. Once you then request to install gcc-multilib, its going to ask to change out several packages with their multilib equivant ones; this version of gcc is the same as the one you'd been using but has support to be able to compile 32 bit versions on request.

piwwo commented on 2015-07-21 09:24

Ok what version of gcc-multilib? on AUR or AUR4?

ArthurBorsboom commented on 2015-07-19 16:46

Replacing gcc with gcc-multilib fixed the compilation issue for me.

kantras commented on 2015-07-19 02:25

can someone who is having compile issues please try gcc-multilib from the multilib repository - the error that piwwo posted appeared to be related to compiling the 32-bit version of one of the support tools.

ArthurBorsboom commented on 2015-07-14 20:55

@kantras: I experience the same issue as piwwo.

- spice disabled
- same gcc, no multilib
- kernel 4.0.7-2

piwwo commented on 2015-07-13 09:56

Uhm I think I am using gcc.
# pacman -Q gcc
gcc 5.1.0-5

Package gcc-multilib was not found.

Here is the config log

http://pastebin.com/sLcCpzvG

kantras commented on 2015-07-10 23:19

@nocko: looks like spice-protocol 0.12.8 is broken, based on the thread: https://bugzilla.redhat.com/show_bug.cgi?id=1239102#c3 - as a workaround, if you're not using Spice, open the PKGBUILD file, find the option '--enable-spice' and change it to '--disable-spice' to compile with Spice support removed.

kantras commented on 2015-07-10 22:43

@piwwo: are you using gcc or gcc-multilib? If i'm reading the error message right, it would be the ./src/xen-4.5.1/stubdom/newlib-x86_32/config.log file

nocko commented on 2015-07-10 14:57

cd qemu-xen-dir; \
$source/configure --enable-xen --target-list=i386-softmmu \
--enable-debug --enable-trace-backend=stderr \
--prefix=/usr/lib/xen \
--libdir=/usr/lib/xen/lib \
--includedir=/usr/lib/xen/include \
--source-path=$source \
--extra-cflags="-I/home/nock/Downloads/xen/src/xen-4.5.1/tools/../tools/include \
-I/home/nock/Downloads/xen/src/xen-4.5.1/tools/../tools/libxc/include \
-I/home/nock/Downloads/xen/src/xen-4.5.1/tools/../tools/xenstore/include \
-I/home/nock/Downloads/xen/src/xen-4.5.1/tools/../tools/xenstore/compat/include \
" \
--extra-ldflags="-L/home/nock/Downloads/xen/src/xen-4.5.1/tools/../tools/libxc \
-L/home/nock/Downloads/xen/src/xen-4.5.1/tools/../tools/xenstore \
-Wl,-rpath,/usr/lib/xen/lib" \
--bindir=/usr/lib/xen/bin \
--datadir=/usr/share/qemu-xen \
--localstatedir=/var \
--disable-kvm \
--disable-docs \
--disable-guest-agent \
--python=python2 \
--disable-bluez --disable-gtk --enable-spice --enable-usb-redir \
--cpu=x86_64 \
; \
make all

ERROR: User requested feature spice
configure was not able to find it.
Install spice-server and spice-protocol devel

related config.log:

In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0:
/usr/include/spice-server/spice.h:475:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_INVALID’
SPICE_IMAGE_COMPRESS_INVALID = 0,
^
In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0,
from /usr/include/spice-server/spice.h:23,
from /tmp/qemu-conf-25875-31202-17030.c:1:
/usr/include/spice-1/spice/enums.h:185:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_INVALID’ was here
SPICE_IMAGE_COMPRESS_INVALID,
^
In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0:
/usr/include/spice-server/spice.h:476:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_OFF’
SPICE_IMAGE_COMPRESS_OFF = 1,
^
In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0,
from /usr/include/spice-server/spice.h:23,
from /tmp/qemu-conf-25875-31202-17030.c:1:
/usr/include/spice-1/spice/enums.h:186:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_OFF’ was here
SPICE_IMAGE_COMPRESS_OFF,
^
In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0:
/usr/include/spice-server/spice.h:477:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_AUTO_GLZ’
SPICE_IMAGE_COMPRESS_AUTO_GLZ = 2,
^
In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0,
from /usr/include/spice-server/spice.h:23,
from /tmp/qemu-conf-25875-31202-17030.c:1:
/usr/include/spice-1/spice/enums.h:187:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_AUTO_GLZ’ was here
SPICE_IMAGE_COMPRESS_AUTO_GLZ,
^
In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0:
/usr/include/spice-server/spice.h:478:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_AUTO_LZ’
SPICE_IMAGE_COMPRESS_AUTO_LZ = 3,
^
In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0,
from /usr/include/spice-server/spice.h:23,
from /tmp/qemu-conf-25875-31202-17030.c:1:
/usr/include/spice-1/spice/enums.h:188:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_AUTO_LZ’ was here
SPICE_IMAGE_COMPRESS_AUTO_LZ,
^
In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0:
/usr/include/spice-server/spice.h:479:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_QUIC’
SPICE_IMAGE_COMPRESS_QUIC = 4,
^
In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0,
from /usr/include/spice-server/spice.h:23,
from /tmp/qemu-conf-25875-31202-17030.c:1:
/usr/include/spice-1/spice/enums.h:189:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_QUIC’ was here
SPICE_IMAGE_COMPRESS_QUIC,
^
In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0:
/usr/include/spice-server/spice.h:480:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_GLZ’
SPICE_IMAGE_COMPRESS_GLZ = 5,
^
In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0,
from /usr/include/spice-server/spice.h:23,
from /tmp/qemu-conf-25875-31202-17030.c:1:
/usr/include/spice-1/spice/enums.h:190:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_GLZ’ was here
SPICE_IMAGE_COMPRESS_GLZ,
^
In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0:
/usr/include/spice-server/spice.h:481:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_LZ’
SPICE_IMAGE_COMPRESS_LZ = 6,
^
In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0,
from /usr/include/spice-server/spice.h:23,
from /tmp/qemu-conf-25875-31202-17030.c:1:
/usr/include/spice-1/spice/enums.h:191:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_LZ’ was here
SPICE_IMAGE_COMPRESS_LZ,

piwwo commented on 2015-07-10 11:24

@kantras

Unfortunately I don't know which log there are alot config.logs and I am not sure which one belongs to the module:
xen]$ find ./ -name "config.log"
find: `./pkg': Permission denied
./src/xen-4.5.1/config.log
./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/doc/config.log
./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libm/config.log
./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libm/machine/config.log
./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/config.log
./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc/sys/config.log
./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc/config.log
./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc/machine/config.log
./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc/machine/x86_64/config.log
./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/libgloss/doc/config.log
./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/libgloss/libnosys/config.log
./src/xen-4.5.1/stubdom/newlib-x86_64/x86_64-xen-elf/libgloss/config.log
./src/xen-4.5.1/stubdom/newlib-x86_64/etc/config.log
./src/xen-4.5.1/stubdom/newlib-x86_64/config.log
./src/xen-4.5.1/stubdom/config.log
./src/xen-4.5.1/stubdom/newlib-x86_32/config.log
./src/xen-4.5.1/stubdom/gmp-x86_64/config.log
./src/xen-4.5.1/tools/config.log
./src/xen-4.5.1/tools/qemu-xen-dir/config.log

kantras commented on 2015-07-10 07:00

@piwwo: Still trying to reproduce this; do you also have a copy of the config.log file mentioned in the error message?

piwwo commented on 2015-07-07 16:50

Compiling fails for me
make[2]: Leaving directory '/home/xenuser/xen/src/xen-4.5.1/extras/mini-os'
touch mk-headers-x86_32
mkdir -p newlib-x86_32
( cd newlib-x86_32 && \
CC_FOR_TARGET="gcc -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/posix -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/../tools/xenstore/include -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/x86 -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/x86/x86_32 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/../extras/mini-os/include/posix -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/cross-root-i686/i686-xen-elf/include -isystem /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/include -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/lwip-x86_32/src/include -isystem /home/xenuser/xen/src/xen-4.5.1/stubdom/lwip-x86_32/src/include/ipv4 -I/home/xenuser/xen/src/xen-4.5.1/stubdom/include -I/home/xenuser/xen/src/xen-4.5.1/stubdom/../xen/include -fno-caller-saves -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 -fno-omit-frame-pointer -m32 -march=i686 -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -fno-stack-protector -fno-exceptions -D_I386MACH_ALLOW_HW_INTERRUPTS" AR_FOR_TARGET=ar LD_FOR_TARGET=ld RANLIB_FOR_TARGET=ranlib ../newlib-1.16.0/configure --prefix=/home/xenuser/xen/src/xen-4.5.1/stubdom/cross-root-i686 --verbose --target=i686-xen-elf --enable-newlib-io-long-long --disable-multilib && \
make DESTDIR= && \
make DESTDIR= install )
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... i686-xen-elf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for gcc... gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
Makefile:83: recipe for target 'cross-root-i686/i686-xen-elf/lib/libc.a' failed
make[1]: *** [cross-root-i686/i686-xen-elf/lib/libc.a] Error 77
make[1]: Leaving directory '/home/xenuser/xen/src/xen-4.5.1/stubdom'
Makefile:73: recipe for target 'install-stubdom' failed
make: *** [install-stubdom] Error 2

xen]$ uname -a
Linux dom0.xen 4.0.7-2-ARCH #1 SMP PREEMPT Tue Jun 30 07:50:21 UTC 2015 x86_64 GNU/Linux

kantras commented on 2015-07-04 23:47

Updated to 4.5.1 + added some fixes for GCC 5. Note: OVMF is not enabled by default in this build as it still requires some patching before it will support GCC 5.

cyberxndr commented on 2015-06-25 21:22

After a couple of hours I got two successfull builds with different CRC. The first package raises dom0 crush, the second was OK. I don't remember the difference between compilation process. Maybe I forgot to apply patch #6 in first build. Patches #2 #3 #4 didn't work well in the PKGBUILD, so I manualy applied them one by one after each iteration of failed "makepkg -ei". At this moment I able to login into the dom0.

tr0llalert commented on 2015-06-24 09:21

apparently you can't search 'xen' in the new home i.e. aur4.archlinux.org.

any ideas when to expect upstream fix for gcc5 + Xen 4.4/4.5?

thanks

PZB1000 commented on 2015-06-24 05:56

Also just tried to build this package. As the option Werror is used i have got an error in symbols.c

"arrary subscript is above array bounds"

in line 23 from project src/xen-4.5.0/xen/common. gcc Version 5.1 on arch linux 64 bit

pgmillon commented on 2015-06-21 17:40

Just tried to build on a 32bits system:
Version: rel-1.7.5-0-ge51488c-20150621_142420-test-dantooine
Fixed space: 0xe05b-0x10000 total: 8101 slack: 10 Percent slack: 0.1%
16bit size: 35488
32bit segmented size: 2208
32bit flat size: 22048
32bit flat init size: 68896
Lowmem size: 2160
f-segment var size: 1728
Linking out/rom16.o
out/code16.o: In function `kbd_command':
/tmp/yaourt-tmp-ishtanzar/aur-xen/src/xen-4.5.0/tools/firmware/seabios-dir-remote/src/kbd.c:120: undefined reference to `usb_kbd_command'
out/code16.o: In function `mouse_command':
/tmp/yaourt-tmp-ishtanzar/aur-xen/src/xen-4.5.0/tools/firmware/seabios-dir-remote/src/mouse.c:30: undefined reference to `usb_mouse_command'
Makefile:170: recipe for target 'out/rom16.o' failed
make[6]: *** [out/rom16.o] Error 1

Linux test-dantooine 4.0.5-1-ARCH #1 SMP PREEMPT Sat Jun 6 18:52:28 CEST 2015 i686 GNU/Linux

maximevince commented on 2015-06-16 08:23

As posted on the old aur:

I can confirm the -fno-caller-saves is a valid workaround. My xen-4.5 build now actually boots my arch kernel. I thought it was a macbook/efi issue, but it was actually caused by gcc5!
Patch is here: http://pastebin.com/XDpzbLYa

So the full set of patches is:
http://pastebin.com/Z5BnzFwc
http://pastebin.com/19tb2esC
http://pastebin.com/WwxugrRi
http://pastebin.com/7742EHd1
http://pastebin.com/aNWdhEH0
http://pastebin.com/XDpzbLYa

ArthurBorsboom commented on 2015-05-31 08:56

From the same thread, apparently a workaround is setting the following compile flag avoiding the bug.

fno-caller-saves

As long as the bug is present, maybe it is an idea to implement this flag into the PKGBUILD?

jkf commented on 2015-05-30 19:08

After further investigation, it does indeed appear that GCC 5 is mis-compiling Xen.

http://www.gossamer-threads.com/lists/xen/devel/381362#381362

Any one know if GCC 4.9 can co-exist with GCC 5 on the same system? Or would it be easier to roll back to a version of Arch before GCC 5 became the default?

jkf commented on 2015-05-30 19:06

After further investigation, it does indeed appear that GCC 5 is mis-compiling Xen.

http://www.gossamer-threads.com/lists/xen/devel/381362#381362

Any one know if GCC 4.9 can co-exist with GCC 5 on the same system? Or would it be easier to roll back to a version of Arch before GCC 5 because default?

jackb commented on 2015-05-30 05:22

I can add that I believe, based on your description, that I'm experiencing the same issue. After applying the suggested patches I got a clean build, but was unable to boot int the xen dom0. Booting the original Arch kernel worked fine.

jkf commented on 2015-05-29 06:43

Greetings,

Following the comments in this thread, I have successfully built a Xen 4.5.0 package, but it fails during boot when Xen starts the Linux kernel. I have been following the following thread on the xen-devel mailing list which seems to suggest an issue with GCC 5. I have also posted to that thread to get more data to the Xen developers.

http://www.gossamer-threads.com/lists/xen/devel/379916

I am running a system updated just a few days ago, that boots via UEFI and gummiboot. I have a working Xen 4.4.1 package that I built before GCC was upgraded to 5, so I believe this is an issue with Xen itself and not my environment. The system also functions properly when booting the Linux kernel directly. See the link below for the boot log I captured via the serial port.

http://pastebin.com/bBC78306

Thinking my toolchain was the issue, I tried the Xen 4.5.0 EFI binary from Fedora 22, and it failed exactly the same way. It was compiled with GCC 5.0.1. See the below link for the boot log from that binary.

http://pastebin.com/jvg1JazC

Then I found the message linked below and tried the build of 4.5.1-rc1 that a poster did with GCC 4.9.2 on Fedora 21, and it booted successfully. See the boot log below from that.

http://www.gossamer-threads.com/lists/xen/devel/380173#380173

http://pastebin.com/DKxwaU2U

Xen is way lower level in the system that I'm used to digging around, so does anyone else have any thoughts on this issue?

Thanks!

cptG commented on 2015-05-28 10:51

maelask: you'll need to apply the patches posted by djvinz.
Download them and change PKGBUILD to apply them.
The patch called seabios-gcc5.patch won't apply from whithin makepkg since the directory seabios-dir-remote does not exist yet at that moment. Apply this one manually after compilation errors out and issue "makepkg -ei". See my comment below.

maelask commented on 2015-05-27 16:56

Getting this while trying to compile.
symbols.c: In function 'symbols_lookup':
symbols.c:23:61: error: array subscript is above array bounds [-Werror=array-bounds]
#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
^
symbols.c:128:47: note: in expansion of macro 'symbols_address'
while (low && symbols_address(low - 1) == symbols_address(low))
^
symbols.c:23:61: error: array subscript is above array bounds [-Werror=array-bounds]
#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
^
symbols.c:136:13: note: in expansion of macro 'symbols_address'
if (symbols_address(i) > symbols_address(low)) {
^
cc1: all warnings being treated as errors
/tmp/yaourt-tmp-maelask/aur-xen/src/xen-4.5.0/xen/Rules.mk:168: recipe for target 'symbols.o' failed

maelask commented on 2015-05-27 16:51

Getting this error on a new archlinux install

symbols.c: In function 'symbols_lookup':
symbols.c:23:61: error: array subscript is above array bounds [-Werror=array-bounds]
#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
^
symbols.c:128:47: note: in expansion of macro 'symbols_address'
while (low && symbols_address(low - 1) == symbols_address(low))
^
symbols.c:23:61: error: array subscript is above array bounds [-Werror=array-bounds]
#define symbols_address(n) (SYMBOLS_ORIGIN + symbols_offsets[n])
^
symbols.c:136:13: note: in expansion of macro 'symbols_address'
if (symbols_address(i) > symbols_address(low)) {
^
cc1: all warnings being treated as errors

cptG commented on 2015-05-27 10:27

The patch touching seabios-dir-remote can not be applied from within PKGBUILD since that dir does not exist before make is being called. There should be a patch changing ./tools/firmware/Makefile to apply the patch I think.
I just went ahead and patched manually and did "makepkg -ei", still waiting for the build to finish though...

kantras commented on 2015-05-26 04:23

It will be once I've finished testing this, and any other changes that I might want to bring in for the next version

jackb commented on 2015-05-26 04:20

Thank you so much! I built it successfully. I'm assuming the AUR package will be updated? Is there a repo attached to this AUR?

maximevince commented on 2015-05-25 10:31

Yeah, I noticed. Now it finally builds.
Needed these patches as well:
http://pastebin.com/19tb2esC
http://pastebin.com/WwxugrRi
http://pastebin.com/7742EHd1
http://pastebin.com/aNWdhEH0

jackb commented on 2015-05-24 23:31

(sorry, I should have added that I tried the 4.4 AUR package to see if that solved any issues; it didn't. I'm getting the same error in both packages.)

jackb commented on 2015-05-24 23:30

Thanks @djvinz. That successfully resolved the array-bounds issue, but I'm now encountering another:

builds/xen-4.4/src/xen-4.4.2/tools/firmware/seabios-dir-remote/src/kbd.c:117: undefined reference to `usb_kbd_command'
out/code16.o: In function `mouse_command':
builds/xen-4.4/src/xen-4.4.2/tools/firmware/seabios-dir-remote/src/mouse.c:28: undefined reference to `usb_mouse_command'
Makefile:158: recipe for target 'out/rom16.o' failed
make[6]: *** [out/rom16.o] Error 1

Any ideas what's up with that? I'm new to xen, and new-ish to Arch, so I apologize if I'm wasting your time, but I don't understand how everyone's managing to get this stuff going without issues. Lots of searches have yielded me nothing.

maximevince commented on 2015-05-24 16:58

Since gcc5.x you'll need this patch:
http://pastebin.com/Z5BnzFwc

jackb commented on 2015-05-24 07:12

Hey all. I'm having problems running makepkg. I'm getting an error about 'array subscript is above array bounds [-Werror=array-bounds]'. It's being caused by a macro, 'symbols_address'. Is anyone else having this problem?

This is on a fresh install; nothing out of the ordinary.

ArthurBorsboom commented on 2015-05-19 09:02

xen-4.2.0 ?

piwwo commented on 2015-05-19 09:00

Compiling breaks. Downloaded tarball today:

make[5]: Entering directory '/home/xenuser/xen/src/xen-4.2.0/xen/common/compat'
gcc -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -DNDEBUG -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/home/xenuser/xen/src/xen-4.2.0/xen/include -I/home/xenuser/xen/src/xen-4.2.0/xen/include/asm-x86/mach-generic -I/home/xenuser/xen/src/xen-4.2.0/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -mno-red-zone -mno-sse -fpic -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE -nostdinc -g -D__XEN__ -include /home/xenuser/xen/src/xen-4.2.0/xen/include/xen/config.h -DHAS_ACPI -DHAS_GDBSX -DHAS_PASSTHROUGH -MMD -MF .memory.o.d -c memory.c -o memory.o
In file included from /home/xenuser/xen/src/xen-4.2.0/xen/include/public/xen.h:33:0,
from /home/xenuser/xen/src/xen-4.2.0/xen/include/xen/time.h:12,
from /home/xenuser/xen/src/xen-4.2.0/xen/include/xen/hypercall.h:9,
from memory.c:3:
memory.c: In function 'compat_memory_op':
/home/xenuser/xen/src/xen-4.2.0/xen/include/public/arch-x86/xen.h:35:33: error: typedef '__guest_handle_const_compat_memory_exchange_t' locally defined but not used [-Werror=unused-local-typedefs]
typedef struct { type *p; } __guest_handle_ ## name
^
/home/xenuser/xen/src/xen-4.2.0/xen/include/public/arch-x86/xen.h:43:5: note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
^
/home/xenuser/xen/src/xen-4.2.0/xen/include/public/arch-x86/xen.h:44:41: note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
#define DEFINE_XEN_GUEST_HANDLE(name) __DEFINE_XEN_GUEST_HANDLE(name, name)
^
memory.c:255:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
^
cc1: all warnings being treated as errors
/home/xenuser/xen/src/xen-4.2.0/xen/Rules.mk:156: recipe for target 'memory.o' failed
make[5]: *** [memory.o] Error 1
make[5]: Leaving directory '/home/xenuser/xen/src/xen-4.2.0/xen/common/compat'
/home/xenuser/xen/src/xen-4.2.0/xen/Rules.mk:144: recipe for target 'compat/built_in.o' failed
make[4]: *** [compat/built_in.o] Error 2
make[4]: Leaving directory '/home/xenuser/xen/src/xen-4.2.0/xen/common'
/home/xenuser/xen/src/xen-4.2.0/xen/Rules.mk:144: recipe for target '/home/xenuser/xen/src/xen-4.2.0/xen/common/built_in.o' failed
make[3]: *** [/home/xenuser/xen/src/xen-4.2.0/xen/common/built_in.o] Error 2
make[3]: Leaving directory '/home/xenuser/xen/src/xen-4.2.0/xen/arch/x86'
Makefile:92: recipe for target '/home/xenuser/xen/src/xen-4.2.0/xen/xen' failed
make[2]: *** [/home/xenuser/xen/src/xen-4.2.0/xen/xen] Error 2
make[2]: Leaving directory '/home/xenuser/xen/src/xen-4.2.0/xen'
Makefile:25: recipe for target 'install' failed
make[1]: *** [install] Error 2
make[1]: Leaving directory '/home/xenuser/xen/src/xen-4.2.0/xen'
Makefile:65: recipe for target 'install-xen' failed
make: *** [install-xen] Error 2
==> ERROR: A failure occurred in package().
Aborting...

[xenuser@archiso xen]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.9-20150304/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 4.9.2 20150304 (prerelease) (GCC)

uname -a
Linux archiso 4.0.1-1-ARCH #1 SMP PREEMPT Wed Apr 29 12:00:26 CEST 2015 x86_64 GNU/Linux

ArthurBorsboom commented on 2015-05-16 21:52

Confirming 4.5.0-3 works fine for me.

Good work, David!

kantras commented on 2015-05-16 20:56

FYI: the 4.5.0-3 update I pushed a couple of days ago or so does contain the patches for CVE-2015-3456 ( aka the Venom vulnerability )

tr0llalert commented on 2015-05-13 14:17

gnutls 3.4.1-1 works too.

ArthurBorsboom commented on 2015-05-13 14:13

Updated Xen package build works for me with Kernel 4.0 and GNU utils 3.4.0

aneeshusa commented on 2015-05-13 13:58

New XSA just came out today: http://xenbits.xen.org/xsa/advisory-133.html

kantras commented on 2015-05-06 12:48

@pierrec - I disabled building of documentation because of the existance of the xen-docs package and because some people want to run their hypervisors very "light", without optional extras such as documentation. If that package doesn't get updated, and is still not orphaned, what I may have to do is add in the relevant changes into my PKGBUILD and just comment them out, so someone can always enable them if needed.

@AuthurBorsboom - Will be today; I had a small checklist of things that I wanted to cover, which includes the ones you've mentioned, and i'm about ready to push the updated files.

ArthurBorsboom commented on 2015-05-06 09:07

Hi Kantras,

AFAIK the following needs to be updated.

- use of $srcdir
- patch for gnutls

Do you have an estimation of when you are able to publish the new PKGBUILD?

pierrec commented on 2015-05-06 08:48

Thanks for this package.
But why do you --disable-docs? I suppose you do that to avoid extra deps?
xen-docs is 4.4 so not that useful :p

alaricljs commented on 2015-05-05 01:38

Any news on that updated package? For some reason I can't get sheep_42's edits to work.

tr0llalert commented on 2015-05-02 03:15

Thanks guys. Both Xen 4.5 and 4.4.1 were installed successfully with the patch.

kantras commented on 2015-04-30 14:18

Updated package coming later today

sheep_42 commented on 2015-04-30 13:38

sorry writing a patch in a comment was not a good idee ...

The patch is simple, add this two lines at the end of the PKGBUILD:
source+=('gnutls-3.4.0.patch::http://git.alpinelinux.org/cgit/aports/plain/main/xen/gnutls-3.4.0.patch?id=628f27939412a7d6fb67734bd644119a1f49463a')
sha256sums+=('e25d38376e22f6f935d2c0ce1b9d6e6b47ff261b5e6056bc3b47168739d7a992')

And in the prepare() function add this line (just after # Compile Patches):
patch -p1 -i $srcdir/gnutls-3.4.0.patch

tr0llalert commented on 2015-04-30 12:25

Sorry sheep_42, patching fails with malformed error at this line:
'3f0af16958c3e057b9baa5afc47050d9adf7dd553274dd97ae4f35938fefb568'

I could try editing PKGBUILD myself if I knew what goes where. Thanks for helping!

sheep_42 commented on 2015-04-30 10:53

tr0llalert, the gnutls fix patch looks correct (and one similair have been sent upstream) so I would use it instead of disable-qemu-traditional.

To do that, just modify the PKGBUILD with this patch:

--- a/PKGBUILD
+++ b/PKGBUILD
@@ -71,6 +71,9 @@
'3f0af16958c3e057b9baa5afc47050d9adf7dd553274dd97ae4f35938fefb568'
'50a9b7fd19e8beb1dea09755f07318f36be0b7ec53d3c9e74f3266a63e682c0c')

+source+=('gnutls-3.4.0.patch::http://git.alpinelinux.org/cgit/aports/plain/main/xen/gnutls-3.4.0.patch?id=628f27939412a7d6fb67734bd644119a1f49463a')
+sha256sums+=('e25d38376e22f6f935d2c0ce1b9d6e6b47ff261b5e6056bc3b47168739d7a992')
+
prepare() {
cd $pkgname-$pkgver/

@@ -79,6 +82,7 @@ prepare() {
# Security Patches

# Compile Patches
+ patch -p1 -i $srcdir/gnutls-3.4.0.patch

# OVMF Compile support (Pulls from GIT repo, so patching to patch after pull request)
echo "Patching OVMF..."

tr0llalert commented on 2015-04-30 01:41

ps: Any help/procedure in applying libgnutls patch would be great as well. Thanks!

tr0llalert commented on 2015-04-30 00:38

Hi Guys,

I'm fairly new to this but having the same problem as some of you having. I'm unable to start DomUs (PV and HVM) with following error;

/usr/lib/xen/bin/qemu-system-i386: error while loading shared libraries: libgnutls.so.28: cannot open shared object file: No such file or directory.

I have tried upgrading Xen 4.4 to 4.5 but it's failing even with sheep_42's suggestion; 'For that, remove from the ./configure line : "--enable-stubdom --enable-qemu-traditional --enable-rombios" and add "--disable-qemu-traditional".'

rm: cannot remove usr/share/xen/qemu/openbios-*: Not a directory
ERROR: A failure occured in package().
Aborting...

I tried downgrading libgnutls but the package suggested by zir_blazer is not being recognized by pacman as a valid archive.

Any help with either upgrading Xen to 4.5 or making gnutls work with 4.4 would be appreciated. Thanks!

aneeshusa commented on 2015-04-29 20:09

I've only done minimal testing, but I just updated to linux 4.0.1-1 and Xen doesn't appear to be broken as opposed to 3.19, for anyone looking to upgrade from 3.18. (I also have gnutls 3.40 but no HVM domUs.)

zir_blazer commented on 2015-04-28 10:02

Interesing. If I get too anxious I could try building it that way and checking if it works, since I don't use anymore qemu-xen-traditional.

I already did the procedure from the link you provided. The problem is that it just include instructions on how to enable SPICE in a DomU, not how to use it. I posted on xen-users and was later told that I need to use a SPICE client, like virt-viewer:
http://lists.xenproject.org/archives/html/xen-users/2015-04/msg00124.html
...Which is the reason why I broke my Xen install as I had to upgrade gnutls to use it.
I believe the next step would be to do something like executing virt-viewer <DomU name>, which should work according to this:
http://linux.die.net/man/1/virt-viewer

sheep_42 commented on 2015-04-27 17:47

Hi zir_blazer,

To compile Xen with recent gnutls, you could use --disable-qemu-traditional as a workaround if you don't intend to use qemu-traditional or stubdomain.
For that, remove from the ./configure line : "--enable-stubdom --enable-qemu-traditional --enable-rombios" and add "--disable-qemu-traditional".

For the usb redirection feature of SPICE, you can look at http://wiki.xen.org/wiki/SPICE_support_in_Xen, there is an example configuration file.

zir_blazer commented on 2015-04-27 16:05

For anyone that needs instructions on how to downgrade gnutls until the xen package gets updated to work with gnutls 3.4, you need to download and install the older, working package from the Arch Rollback Machine. Don't worry, you can do it in two commands:

curl -O https://seblu.net/a/arm/packages/g/gnutls/gnutls-3.3.14-2-x86_64.pkg.tar.xz
pacman -U gnutls-3.3.14-2-x86_64.pkg.tar.xz

This applies both to build the xen package, and to use xl create to open your DomU. Keep in mind that you can break your working Xen install while it is running, if you update with pacman -Syyu. After the upgrade, xl create will give out errors. This means that you can screw up your working Xen install if you update Arch Linux while Xen it is running (And its possible that you can fix it downgrading without rebooting, too).


Also, did anyone successfully managed to use the SPICE USB Redirect feature? I was told that besides adding a few SPICE-related parameters to my DomU Config File, I also need to use a SPICE client like virt-viewer. virt-viewer is also the very reason why I upgraded gnutls, which broke my Xen install. Since I can't have the latest gnutls, virt-viewer fails, but if I upgrade gnutls xl create fails, so in order to test SPICE I will have to wait for this package to catch up.
If someone has a guide or a link with instructions to get it working, I will be most thankful.

sgowie commented on 2015-04-27 15:24

Compilation fails with gnutls 3.4.0-1, presenting:
undefined reference to `gnutls_kx_set_priority'

Downgrading gnutls corrected the issue.

trixpan commented on 2015-04-25 10:34

has anyone managed to complete makepkg using gcc 5? Seems to be a little bit challenging...

https://bugzilla.suse.com/show_bug.cgi?id=921994

ArthurBorsboom commented on 2015-04-24 09:29

My Xen broke too after updating the gnutls to 3.4.0.

To fix it, I had to:
- edit the PKGBUILD and add a pause command (read -p "wait") at the prepare function (to manually apply the patch)
- edit the PKGBUILD on the fly by replacing ../.. with $srcdir (to fix the source dir assumption)
- At the moment the prepare statement is waiting, applying the gnutls-3.4.0.patch from a second terminal.
- Continue the build in the first terminal.

This repaired my Xen and it is working as before.

kantras commented on 2015-04-23 20:06

Testing and should be releasing update either tonight or tomorrow

lembang commented on 2015-04-23 19:56

@hugleo
The patch works perfect for me.
Thank you.

lembang commented on 2015-04-23 16:45

the gnutls broke couple things in my machine.. First xen, then i Need to downgrade it, then now my samba is broken..hmm..

hugleo commented on 2015-04-22 14:58

Maybe this patch will workout?
http://git.alpinelinux.org/cgit/aports/diff/main/xen/gnutls-3.4.0.patch?id=628f27939412a7d6fb67734bd644119a1f49463a

GeorgeK commented on 2015-04-22 14:29

I recently upgraded gnutls to 3.4.0 and it's broken my HVMs. Logs showed libgnutls.so.28 not being found. General advice for these sorts of problems is to rebuild so I tried.

Rebuilding fails in tools/qemu-xen-traditional/vnc.c with undefined references to gnutls_*_set_priority. AFAICS this set of functions was deprecated some years ago so I suspect they are no longer present.

Downgraded gnutls for now

kantras commented on 2015-04-18 02:16

Already fixed in my local copy, will be uploading once I get back to that machine

daniel_shub commented on 2015-04-17 14:50

I am having the same problem that @ArthurBorsboom is having with makepkg not being able to find tmpfiles.d-xen.conf when I build in a clean chroot. I am pretty sure

install -Dm644 ../../tmpfiles.d-$pkgname.conf usr/lib/tmpfiles.d/$pkgname.conf

is making an assumption about the location of $srcdir relative to $pkgdir. I think it should be

install -Dm644 $srcdir/tmpfiles.d-$pkgname.conf usr/lib/tmpfiles.d/$pkgname.conf

If I am correct, there are a couple of other lines immediately afterwards that also need the change.

I think to be totaly robust, $srcdir should be wrapped in quotes throughout the PKGBUILD.

tritron commented on 2015-04-08 19:07

How is video passing with this xen ? I tried xen efi aur and could not get this working. I had switched to kvm from xen 4.4 and kvm is so much better.

zir_blazer commented on 2015-04-08 18:09

I can confirm the last post. The syntax of the dom0_mem option provided in the efi-xen.cfg file is wrong, the correct one is with a : instead of a = in the max parameter. If you're using UEFI Boot, you will eventually notice it.

Also, an issue popped where if creating an Arch Linux DomU, installing Xorg and a Desktop Manager, the Mouse cursor is invisible. At least some other guy had the same issue:
http://lists.xenproject.org/archives/html/xen-users/2015-04/msg00033.html
I can confirm it. I don't know if its a Xen issue, or any other of the upgraded Arch Linux packages related to it (xorg-server 1.17.1 comes to mind). I'm using the xf86-video-vesa Driver.

Finally, I made public an english installation guide for Arch Linux and Xen, which I suppose some people here may find interesing:
http://lists.xenproject.org/archives/html/xen-devel/2015-04/msg00709.html

JohnTh commented on 2015-04-07 03:15

@kantras I have a very minor adjustment.
In the included example efi-xen.cfg file, could the option dom0_mem=1024M,max=1024M
please be changed to
dom0_mem=1024M,max:1024M
I believe the …,max=... option is incorrect syntax. It did not limit dom0 memory for me with EFI booted xen until changed to max:. Otherwise, everything built (with an --enable-targets=x86_64-pep built binutils to build EFI Xen) and is running without issue. Thank you for maintaining the package.

ArthurBorsboom commented on 2015-04-03 13:23

Some more debugging info, where I added a pwd in the PKGBUILD:

pwd before "cd pkgdir": /tmp/makepkg/xen/src/xen-4.5.0
pwd before "install cmd": /tmp/makepkg/xen/pkg/xen
install: cannot stat ‘../../tmpfiles.d-xen.conf’: No such file or directory

basus commented on 2015-04-02 21:09

I'm trying to build this on an x86_64 system running kernel 3.18.6-1 via yaourt, but I get an error telling me that the dev86 and lib32-glibc targets can't be found. Searching for the via the AUR web interface doesn't turn up anything either. Help?

ArthurBorsboom commented on 2015-04-02 19:32

I did find the symbolic link of the missing file in this directory:

/tmp/makepkg/xen/src

The symbolic link is:

tmpfiles.d-xen.conf -> /tmp/yaourt-tmp-arthur/aur-xen/tmpfiles.d-xen.conf

The file does seem to exist:

[arthur@orion1695 src]$ cat /tmp/yaourt-tmp-arthur/aur-xen/tmpfiles.d-xen.conf
d /run/xen 0755 root root -
d /run/xenstored 0755 root root -

ArthurBorsboom commented on 2015-04-02 19:18

Hi Kantras,

Thanks for updating the package.
Unfortunately, I get a build error:

....
install -m0644 -p mini-os-x86_32-grub/mini-os.gz "/tmp/makepkg/xen/pkg/xen/usr/lib/xen/boot/pv-grub-x86_32.gz"
make[1]: Leaving directory '/tmp/makepkg/xen/src/xen-4.5.0/stubdom'
install: cannot stat ‘../../tmpfiles.d-xen.conf’: No such file or directory
==> ERROR: A failure occurred in package().
Aborting...
==> ERROR: Makepkg was unable to build xen.

Any idea what the cause is and how to prevent it?
Do you need more logging?

zir_blazer commented on 2015-04-02 15:59

Tested all three things. Got news:

At least in my case, the Radeon patch seems to be already redundant. I see the same behaviator on the DomU with and without it (First boot everything works, second boot the Video Card itself works but PowerPlay Power States don't, on third boot everything works again, then repeat the sequence).

I was able to change qemu-xen-traditional to qemu-xen on the DomU config file with no issues. Just by starting again the DomU, everything was working. WXP x64 detected some new Hardware and installed a few Drivers. Just to make sure, I uninstalled the GPLPV Drivers and restarted in Safe Mode, opened cmd, then used:

set DEVMGR_SHOW_NONPRESENT_DEVICES=1
devmgmt.msc

This open Device Manager with an specific flag set, and also by ticking View/Show Hidden devices, allows you to see Devices that aren't present but their Drivers are installed. I uninstalled what I recognized to be emulated QEMU devices or Xen related, then rebooted again, and finally, reinstalled the GPLPV Drivers. Everything seems to be working. This is as clean as I thought I could do the migration.

I also uncommented the --enable-ovmf line in PKGBUILD. It builded properly, and after reinstalling the xen package, now I can create a DomU with UEFI Firmware. I do agree that the more sensible choice is to not have it by default, since download and build times skyrockets with it. Just make sure than it is stated somewhere that OVMF is there and ready to use.

Basically, absolutely everything I tested is working for me in this version. An amazing achievement, considering that 4.4 broke Passthrough in my setup, yet with 4.5 I have all what I had in 4.3 and better, I'm not bound anymore to qemu-xen-traditional, so I don't have to worry about it being dropped in future versions.

What I didn't tried was UEFI Boot (I have to refresh pacman to install Gummiboot, and with 5 months worth of upgrades, if something breaks I will have issues figuring what it was), but since before building I had a binutils with x86_64-pep package installed, it dropped an EFI file in /boot. Since in both 4.3 and 4.4 UEFI Boot worked with Kernel 3.17, I don't see any reason for it not to work.

Anyways, thank you. The delay with your xen package was worth it.

zir_blazer commented on 2015-04-02 12:47

Can confirm that I was able to build, install, and get working, the new Xen 4.5. I'm using Kernel 3.17.1 and BIOS Boot - I don't update Arch Linux since the last time I tinkered with it, that was at the end of October.
The best part is that it worked out of the box with my current Xen 4.3 WXP x64 DomU config file, that is using qemu-xen-traditional, including Video Card and Sound Card passthrough, with no issues (For those that remember me, I couldn't get neither working properly on Xen 4.4). I simply uninstalled Xen 4.3, rebooted, installed Xen 4.5, enabled systemd services, modified the Syslinux config file, rebooted, and voila.

Also, I uncommented the Radeon patch when building, but not sure if it makes a difference or not since its a quite ancient piece of code, will try in a while without using it. I'm also interesed in testing with xen-qemu instead, since xen-qemu-traditional will be gone for Xen 4.6.
What I was NOT able to get working, is creating a VM with OVMF. It opens, then inmediately closes. It seems that according to the PKGBUILD --enable-ovmf is commented out. Will try checking if I can build with OVMF support by uncommenting it. After testing with and without the Radeon Passthrough patch, qemu-xen instead of qemu-xen-traditional, and if I can build with OVMF, I will comment again.


BTW, looking at some recent Threads about KVM VFIO, is amazing the progress that they made. They can currently do Passthrough of GeForces Video Cards, which on Xen was impossible for years without modding them to Quadro, and some other goodies. Xen is getting a bit stagnant for the niche I am in, which is rather sad...

lembang commented on 2015-04-01 17:20

@kantras
Thank you. I just open the xen.install and follow them one by one.
I still have the no LACIP error on the 3.19,
but it run well on 3.18.6
I will try to figure out later on the weekend. Thank you for the help :)

kantras commented on 2015-04-01 07:56

.. although the revision i'm referring to isn't uploaded yet. Until the update: xenconsoled.service, xen-init-dom0.service and xen-qemu-dom0-disk-backend.service
should get you up and running with the basic services

kantras commented on 2015-04-01 05:41

@lembang: make sure you have all the correct services starting - with 4.5.0 they moved over to officially supporting systemd and so we are now using the upstream versions instead of our own locally maintained ones (which also have different names - check out the message on install for the ones you want to have)

I just fired up a hvm domain with my dom0 on 3.19.2

lembang commented on 2015-04-01 03:59

the new one doesnt work with kernel 3.19 and also all my vm doesnt work now
ACPI: no LAPIC found

rolled back to kernel 3.18.6
libxl: error: libxl_create.c:1153:domcreate_launch_dm: unable to add disk devices
libxl: error: libxl_dm.c:1578:kill_device_model: unable to find device model pid in /local/domain/4/image/device-model-pid
libxl: error: libxl.c:1603:libxl__destroy_domid: libxl__destroy_device_model failed for 4
libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to get my domid
libxl: error: libxl.c:1640:devices_destroy_cb: libxl__devices_destroy failed for 4

ArthurBorsboom commented on 2015-03-22 07:18

Which tests do you still have in mind?

Maybe some of us can help out performing those tests?

kantras commented on 2015-03-17 12:55

Sorry, had been out of town for a while due to work; will be back up to speed shortly

mbroemme commented on 2015-03-17 10:09

Hi Kantras,

any news about the updated package or any help which is needed?

ArthurBorsboom commented on 2015-03-05 11:51

Hi Kantras,

Can I help with any testing?

kantras commented on 2015-02-12 17:21

Update coming in the next couple of days; system issues and work commitments delayed me being able to run some final tests but will be happening soon.

ArthurBorsboom commented on 2015-02-11 21:47

Hi Kantras,

Do you have any idea when you will update the Xen package to v4.5?
Do you need help?

tritron commented on 2015-02-01 04:49

I experienced crash with xen and linux 3.18.4 when booting my server crashes and reboots.

ArthurBorsboom commented on 2015-01-22 07:46

Yes, I had the same error and it took me quite some time to fix.

For me it had to do with an fix for another issue in the kernel 3.18, which has this as a side effect. Since a downgrade of the kernel is a bit complicated, I have chosen to install the AUR package linux-mainline (Arch Linux). Kernel 3.19 rc4 gave me issues due to the Xen kernel boot parameters not being accepted. However Kernel 3.19 rc5 seems to have resolved all my issues.

So my solution/advise is to temporary install the kernel 3.19 rc5 and once the regular kernel 3.19 is released, to revert back to the stable kernel 3.19.

tritron commented on 2015-01-22 01:30

Did anyone see this error message with latest kernel 22 feature-rx-notify is mandatory ?

kantras commented on 2015-01-15 18:32

I will look at that patch when I transition this over to become xen-4.4 (as "xen" will be moving over to match the 4.5 release)

Note: I am currently away from my systems so the package update will be delayed until I get back this weekend and can run everything through final tests.

zir_blazer commented on 2015-01-15 13:22

@tritron

Are you sure than that patch is needed at all? As far that I know the RAM limit when using VGA Passthrough was fixed sometime during Xen 4.3, as with the xen-4.3 AUR package, I was able to get it working with > 4 GB RAM on a WXP x64 DomU. See this: http://i.imgur.com/a37aoZF.png

With Xen 4.4, I had regressions with PCI Passthrough (Sound Card makes nasty noises everytime that it reproduces a sound), and VGA Passthrough was a total no go, this was regardless if I was using 2 GB of RAM or more. Did you successfully managed to get VGA Passthrough working with less than 3.5 GB without the patch and more with it? I would be surprised cause this means yet another regression on Xen 4.4 vs 4.3, through if that patch fixes it we're already covered.

tritron commented on 2015-01-15 04:07

Can this patch be added ? http://xenbits.xen.org/gitweb/?p=xen.git;a=patch;h=d06886694328a31369addc1f614cf326728d65a6
It solves memory limit of 3.5gb when assigning vga card. Without this patch I get not enough resources error 12

BeepDog commented on 2015-01-10 18:59

Firstly, thanks for all the work keeping the xen package up to date. I just got it set up and working and it's working great! I thought I'd share this, in case anyone else is interested in booting a grub2 (which is what arch ships with) on a guest VM: https://blog.xenproject.org/2015/01/07/using-grub-2-as-a-bootloader-for-xen-pv-guests/

I haven't done it yet, but it seems .... reasonably straight forward.

ArthurBorsboom commented on 2015-01-03 16:38

Hi Kantras,

I found another way to customize the Xen bootloader.
You need to edit the /etc/xen/grub.conf file, as described in the Grub section here.

https://wiki.archlinux.org/index.php/xen

No need to research any further.

ArthurBorsboom commented on 2014-12-31 10:10

That sounds good to me.
Thanks!

kantras commented on 2014-12-31 10:05

Hi ArthurBorsboom,

The short version is that it never has supported using those options in /etc/default/grub, even before I took maintainership of it; the rewrite I did was keeping with existing functionality, just extending it to also support the lts kernels.

I'm actually working on the PKGBUILD for 4.5 now, so I'll add a task to myself to look into 09_xen vs 20_linux_xen (which is the script which comes packaged with grub that uses that variable) and decide which way is best to go to ensure existing configurations aren't broken by any changes I make either.

ArthurBorsboom commented on 2014-12-31 09:43

Hi Kantras,

While trying to set a fixed amount of memory for Dom0, I noticed that the 09_xen file of grub, does not pick up the "GRUB_CMDLINE_XEN_DEFAULT" variable in /etc/default/grub, as I believe it should be.

See also: http://wiki.xen.org/wiki/Xen_Project_Best_Practices

When I manually modify the "XEN_HYPERVISOR_CMDLINE" variable in 09_xen, it does work. However when 09_xen gets updated, this change will be lost.

Do you know why the GRUB_CMDLINE_XEN_DEFAULT is not being used by 09_xen?

kantras commented on 2014-12-16 07:21

With xen 4.5 arriving soon, I'm planning to do the same as I did with the 4.3->4.4 transition; the current xen package will be renamed to 'xen-4.4' and 'xen' will be for the 4.5 release. My goal is to keep the last last three revisions in sync with the upstream releases (so 4.3, 4.4 and 4.5).

kantras commented on 2014-10-30 07:09

@zir_blazer: Actually xen maintain their own fork of the OVMF source code, and its from that repository that the build system pulls. This is why I made the comment that I did about the method we use; I didn't want to try against a system install of OVMF as I wasn't sure if all the xen specific patches had been upstreamed and this technically should already be known to be working with xen. I actually tried booting up a live cd via OVMF and it worked great.

@ArthurBorsboom: There shouldn't be any impact to existing installs - all that has been done is enabling some support code, that won't be used unless a user enables the specific configuration options (for example, OVMF is a replacement for SeaBIOS, but won't be used unless you add "bios='ovmf'" into the configuration file for the domU. )

ArthurBorsboom commented on 2014-10-29 07:50

What is the impact of these changes on existing Xen installations?

zir_blazer commented on 2014-10-29 03:41

Just tested the new package yesterday, with good results. Using makepkg with the default PKGBUILD automatically downloads OVMF, builds it successfully, and after installing, it is ready to use as I could create an UEFI DomU showing TianoCore splash screen. Amazing work. I think that you're the first one to introduce OVMF support into a Xen package.
I do expect that being default build option, some users may have fun trying to make a UEFI DomU for Windows 7/8 or Linux when they notice that support for OVMF is already included and ready to use. But there are some drawbacks. First, that maybe not everyone likes the 200 MiB download. It goes unnoticed when you have 20-30 mins compile time through, so seems minor. The other drawback is that because you're also downloading code from another repository, if for some reason something breaks on the OVMF side, the package will fail to build. Its potentially more work when that happens (Last time was with GCC 4.9 release). A more safe way could be by including a compiled OVMF Firmware in the package and invoking it with --with-system-ovmf=<path>, through I never managed to get it working that way. For as long as everything works, the current way rocks as you get the latest code.

I didn't tested Xen UEFI Boot using binutils with x86_64-pep. However, I did recently a feature request for that to be included in default binutils: https://bugs.archlinux.org/task/42540


The sad part of all this is that I'm stuck with Xen 4.3 due to my regression issue, because as I use Xen for a gaming Windows VM, passthrough is a must. So besides testing to say that it works, I will not be able to enjoy it.

isiachi commented on 2014-10-28 14:17

I've just modified the 09_xen to add grub support to intel_ucode package.

My version of 09_xen automatic detects the presence of /boot/intel-ucode.img and add it to grub.cfg.

http://downloads.rhyeworld.it/files/static/isiachi/09_xen

kantras commented on 2014-10-28 00:51

@zir_blazer: Ok, was finally able to get the OVMF tree, which is pulled via git during compile, to compile. This new update should have this, along with some more cleanup as well as enabling spice support.

Also, if binutils has been rebuilt with the correct option, it will detect the xen.efi file and will move it into /boot. An example xen.cfg is also included as /etc/xen/efi-xen.cfg - simply copy it over into /boot/xen.cfg and edit it with your options.

kantras commented on 2014-10-13 18:09

@zir_blazer: This is on my todo list (Last night I was actually going over the forum posts you had made previously) however I've not had a lot of spare time recently to sit down and work on this (as well as enabling spice support) I'm about to do a major overhaul on my primary desktop system (which uses the xen hypervisor) so was going to tackle that at the same time.

I've also been watching your posts on xen-users and xen-devel, so am aware of it; i've not personally experienced those issues however my setup is a little different so wouldn't likely be hit by some of that (i.e I use a usb headset to my domU, rather than pass through sound)

zir_blazer commented on 2014-10-13 17:29

I would like to repeat my request for OVMF support, which allows to make DomUs with UEFI Firmware instead of BIOS. The idea is that by adding --enable-ovmf in the ./configure line, it automatically downloads 200 MiB or so from edk2 Source Repository and builds it to get a binary that is included with Xen, so you can later create a DomU with it: http://wiki.xen.org/wiki/OVMF
While I didn't tried building with OVMF recently, the last time I attemped to do so, it fails to build cause the Source Code it downloads from edk2 repository isn't modified to build properly in Arch Linux (It isn't aware that python = Python 3.x and it has to use python2 instead, and it also had some issues with GCC 4.9). The other option for doing so, --with-system-ovmf=<ovmf.bin path> never worked for me either. The only success I had was when I merged the modified Source Code from the ovmf-svn package into the directory where xen downloads the edk2 source.
Also, I repeated that procedure with the xen-4.3 package but I wasn't able to get OVMF working. Nor I tested with 4.4.1 to check if it still works.



In other news, while toying around with Xen 4.4.1 I hit some nasty regressions in PCI and VGA Passthrough. The Sound Card works but produces tons of noise everytime that it reproduces a sound (Workaroundeable), and VGA Passthrough is a total no-go. Both things works fine if I try with the xen-4.3 package. Would like to know if anyone else that tested both 4.3.x and 4.4.1 had issues with Passthrough. More info here: http://lists.xen.org/archives/html/xen-devel/2014-10/msg00549.html
Would like to know if other Passthrough users had issues or not between those two versions.

ArthurBorsboom commented on 2014-10-12 19:32

I hereby confirm that the Xen package on my server has upgraded successfully by my regular updating method using yaourt, from v4.4.0 to v4.4.1.

Just a hint for other users, don't forget to update grub manually afterwards; this can save you a phone call to your service provider. (Whoooops) :D

Thanks Kantras for analyzing and fixing.

kantras commented on 2014-10-12 09:20

Thanks to a log provided by ArthurBorsboom, I've been able to work out why some people were having build issues and the fix is applied in the new version I've just uploaded. As always, the change log should show all that has happen per new upload

hbc2 commented on 2014-10-11 08:51

@kantras I am able to install now. I'm unsure what I did differently this time around (even checked my past bash history). I think I was having mirror issue a couple weeks back. Thanks for your help.

kantras commented on 2014-10-03 21:25

I'm aware of it and will be uploading a new version once I've completed build-testing

clfarron4 commented on 2014-10-03 21:23

This looks like a serious vulnerability that has just emerged: http://xenbits.xen.org/xsa/advisory-108.html

https://xen-orchestra.com/blog/xen-security-and-xsa-108/

daniel_shub commented on 2014-10-01 10:33

@kantras I have no problems building it in a clean chroot: https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot. I am on a 64-bit system and have the multilib repository enabled and only have the base-devel package installed in the chroot.

kantras commented on 2014-10-01 09:19

Update: I still haven't been able to reproduce the compile issue that some of you are reporting. I've created a VM, installed Arch with only a base set of packages (base + base-devel), installed the default dependancies for the xen build, and ran makepkg to build the package; worked as expected. I'm going to roll back to the snapshot I made after the first booting of the VM, and will try some other things to see if I can recreate the issue

3000 commented on 2014-10-01 06:56

yes I was, but I upgraded without deinstalling the one before. So I don't know what would have happened if I started from scratch.

hbc2 commented on 2014-10-01 03:52

@3000 were you able to get this package to build?

3000 commented on 2014-09-30 22:34

hi, will Nvidia work with Xen 4.4? I got the new GTX 970. Still no luck

kantras commented on 2014-09-28 14:47

I've actually just been rebuilding my virtual environment here at home to allow me to better test from scenarios such as that; always a good idea to review after something like hardware failure.

hbc2 commented on 2014-09-28 13:05

ArthurBorsboom's issue is easy to duplicate on a fresh install of arch. (yup, installing arch is easy if you've installed it 50+ times like I have while learning linux. :P )

Seriously, though, on a fresh install with nothing else installed I ran into the same exact problem Mr. Borsboom did. I'm using grub not UEFI.

I'm building right out of the AUR.
cd /root
wget https://aur.archlinux.org/packages/xe/xen/xen.tar.gz
tar -xvf xen.tar.gz
cd xen
makepkg -s --asroot

I'm going to poke around in the make files. Never done that before. This should be fun. :)

ArthurBorsboom commented on 2014-09-17 13:00

When I remove the following two lines from the PKGBUILD, the package is build finishes.

mv etc/default/xencommons etc/conf.d/xencommons
mv etc/default/xendomains etc/conf.d/xendomains

There are these two warnings:

==> WARNING: backup entry file not in package : etc/conf.d/xendomains
==> WARNING: backup entry file not in package : etc/conf.d/xencommons

Probably coming from:

backup=(etc/modules-load.d/$pkgname.conf etc/$pkgname/xl.conf etc/conf.d/xen{stored,consoled,domains,commons} etc/$pkgname/grub.conf)

Maybe this gives a clue?

ArthurBorsboom commented on 2014-09-17 12:36

@Zir_blazer, thanks for the suggestion.

I did exactly what you proposed, unfortunately with the same result.

install -d -m0755 -p "/tmp/makepkg/xen/pkg/xen/usr/lib/xen/boot"
install -m0644 -p mini-os-x86_32-grub/mini-os.gz "/tmp/makepkg/xen/pkg/xen/usr/lib/xen/boot/pv-grub-x86_32.gz"
make[1]: Leaving directory '/tmp/makepkg/xen/src/xen-4.4.1/stubdom'
mv: cannot stat ‘etc/default/xencommons’: No such file or directory
==> ERROR: A failure occurred in package().
Aborting...
[arthur@orion1695 xen]$

Any other ideas?

zir_blazer commented on 2014-09-17 08:59

@ ArthurBorsboom
On my experience, I have seen similar errors when re-building xen package on the same folder than a previous build. Seems like it is not deleting or replacing something. Basically, everytime you want to build, try to start from scratch on a new folder, or delete the previous build. Try this:

mkdir /home/builds
cd /home/builds
curl -O https://aur.archlinux.org/packages/xe/xen/xen.tar.gz
tar -xzf xen.tar.gz
cd xen
makepkg

Should work.

ArthurBorsboom commented on 2014-09-17 06:51

Hi Kantras,

Do you have another guess what might be causing the build problem on my system?
Xen still doesn't upgrade from 4.4.0 to 4.4.1 with the following error.

ld: warning: section `.bss' type changed to PROGBITS
gzip -f -9 -c /tmp/makepkg/xen/src/xen-4.4.1/stubdom/mini-os-x86_32-grub/mini-os >/tmp/makepkg/xen/src/xen-4.4.1/stubdom/mini-os-x86_32-grub/mini-os.gz
make[2]: Leaving directory '/tmp/makepkg/xen/src/xen-4.4.1/extras/mini-os'
install -d -m0755 -p "/tmp/makepkg/xen/pkg/xen/usr/lib/xen/boot"
install -m0644 -p mini-os-x86_32-grub/mini-os.gz "/tmp/makepkg/xen/pkg/xen/usr/lib/xen/boot/pv-grub-x86_32.gz"
make[1]: Leaving directory '/tmp/makepkg/xen/src/xen-4.4.1/stubdom'
mv: cannot stat ‘etc/default/xencommons’: No such file or directory
==> ERROR: A failure occurred in package().
Aborting...
==> ERROR: Makepkg was unable to build xen.
==> Restart building xen ? [y/N]
==> ----------------------------
==>
==> ERROR: unable to update
==> upgrading SVN/CVS/HG/GIT package

zir_blazer commented on 2014-09-16 11:11

Also, regarding using Xen with UEFI, I confirm success, but I'm still unsure about the proper procedure. Recompiling binutils for x86_64-pep, copying the xen.efi file to /boot, making a xen.cfg file for it and modifying the Boot Manager accordingly are well know and distro independent. In my case, the new Linux kernel 3.17 that brings official Dom0 UEFI booting support is absolutely required (Builded it from AUR linux-git package with default config), I have never managed to boot a UEFI Dom0 in my computer in any other fashion, through some others did.
However, for a fresh UEFI install on Arch Linux, is there anything else to do?
I mean, when you install the xen package with pacman, there are a lot of other things that are done like placing some files in the systemd and config directories, that are later used for xen. You can then easily enable the xen related services like xenconsoled and xenstored using systemctl because they're already there. If I do a mere copy of the xen.efi file to /boot, I can get it boot Dom0 in UEFI, but after that, I supposed I wouldn't get very far due to the lack of those supporting services. What I should do?

To organize a bit the questions:
1- What exactly is xen.efi? It is a direct EFI replacement for the classic GZ xen image file that also sits on /boot?
2- To properly do a fresh Xen UEFI install, should I copy the .service files to systemd directories manually, or install xen package as normal then copy the xen.efi to /boot and modify the Boot Manager to use that one?

zir_blazer commented on 2014-09-15 16:53

The folder where the .efi file is at is <xen build directory>/pkg/xen/usr/lib/efi/xen-4.4.1.efi. I tried it yesterday doing a manual build (Downloaded with curl the tarball, decompressed it, then builded it with makepkg) and it worked, after building binutils with x86_64-pep support, obviously.

v1rous commented on 2014-09-15 14:14

Rebuilt binutils with support for x86-64-pep as specified on wiki, then built xen, but there is no EFI binary at /usr/lib/efi/xen-4.4.1.efi.

ArthurBorsboom commented on 2014-09-11 06:33

@kantras,

I build my package by entering "yaourt -Suya" which updates all packages on my system.

AFAIK, I have a normal Arch kernel. Since I don't know what hardware it is, I have created a system overview with inxi.

http://pastebin.com/pFKZaJw6

AFAIK, I have no special packages except Xen.

http://pastebin.com/hS8VvWw3

kantras commented on 2014-09-10 21:15

tritron: Ok, my first instinct is that you have an older version of 09_xen installed in /etc/grub.d; the newer one that I editted doesn't have that particular check in it. Check in case you somehow have multiple copies of 09_xen in the /etc/grub.d folder. The newest verion should also have a 'Modified by' comment in it.

tritron commented on 2014-09-10 20:48

### BEGIN /etc/grub.d/09_xen ###
Cannot find grub config file, exiting.

kantras commented on 2014-09-10 20:44

tritron: Ok, so the file naming looks good - what do you get when you run the following as root: 'grub-mkconfig | grep 09' ?

tritron commented on 2014-09-10 20:09

efi initramfs-linux-fallback.img vmlinuz-linux
grub initramfs-linux.img xen-4.4.1.gz

kantras commented on 2014-09-10 19:53

ArthutBorsboom: I'm still trying to reproduce the errors so I can help resolve them, however I'm currently not able to. How exactly are you trying to make the package? any special changes or packages that you are using? what type of hardware are you trying to build it on? cross compiling?

kantras commented on 2014-09-10 19:51

tritron: It depends on a number of factors; are you using standard or custom-built kernels? what is the contents of your /boot directory?

tritron commented on 2014-09-10 19:41

How do you get grub to create configuration file it seems 09_xen is being ignored there is no xen included

ArthurBorsboom commented on 2014-09-09 12:49

It happens during the build.

See: http://pastebin.com/r8VPcdqY

ArthurBorsboom commented on 2014-09-09 12:20

It was and still is a building error.

However, today I have a different error message than yesterday.

The end of the building process: http://pastebin.com/r8VPcdqY

ArthurBorsboom commented on 2014-09-09 12:14

Ehhh... I just noticed this is a totally different error message than yesterday. :)

ArthurBorsboom commented on 2014-09-09 12:13

The issue appears during the build.

These are the last lines:

...
patch -d newlib-1.16.0 -p1 < newlib-stdint-size_max-fix-from-1.17.0.patch
patching file newlib/libc/include/stdint.h
find newlib-1.16.0 -type f | xargs perl -i.bak \
-pe 's/\b_(tzname|daylight|timezone)\b/$1/g'
touch newlib-1.16.0
make[1]: Leaving directory '/tmp/makepkg/xen/src/xen-4.4.1/stubdom'
Makefile:104: recipe for target 'install-stubdom' failed
make: *** [install-stubdom] Error 2
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build xen.
==> Restart building xen ? [y/N]
==> ----------------------------
==>
==> ERROR: unable to update
==> upgrading SVN/CVS/HG/GIT package
[arthur@orion1695 ~]$

kantras commented on 2014-09-08 17:54

ArthurBorsboom: I just tried downloading and installing xen using yaourt but didn't get any errors; is this happening during the build, install, or at some other point of the process?

ArthurBorsboom commented on 2014-09-08 14:49

Yaourt fails to upgrade Xen with the following error:

mv: cannot stat ‘etc/default/xencommons’: No such file or directory

Looks like somewhere is a slash missing.

moggers commented on 2014-09-07 02:28

Sorry, after redownloading and makepkging the tarball with line 95 uncommented, it seems to be working fine.
So disregard that, sorry again.

kantras commented on 2014-09-06 17:39

Actually one of the compile tests I mentioned in the past does involve building with both ati and stubdom enabled ( and looking over the last build log, when I did this, it built without any issues ) Do you happen to have a log of the build error so I can look at what happened?

moggers commented on 2014-09-06 09:12

I believe stubdom needs to be disabled to build with the ati-passthrough patch
>http://lists.xen.org/archives/html/xen-users/2013-03/msg00147.html
>- due to an insufficiancy in the patch, stubdom would not build
correctly, so you have to disable it
Uncommented the ATI passthrough patch line and failed to build. Ripped out everything I could find in your PKGBUILD related to stubdom and it built successfully. I'm having some difficulty with VGA passthrough itself so far; beyond building I'm not sure what the extent of the patch under 4.4 nor the mangling of the PKGBUILD entails.

Not familiar with this whole xen thing, so if I've made a grevious mistake please forgive me, thanks.

kantras commented on 2014-09-04 00:31

zir_blazer: I'll see if I can get some time to look at this tomorrow - right now I'm working on getting the xen-4.3 package up to date, but have started to read the thread you mentioned.

zir_blazer commented on 2014-09-04 00:05

In order for Xen to be able to make DomU VMs that use UEFI instead of SeaBIOS, it needs to be builded with --enable-ovmf option, but it currently fails to build with that option. I request someone to look at this Thread and figure out if the changes I say can be added so it may successfully build with that option:
https://bbs.archlinux.org/viewtopic.php?id=186591

kantras commented on 2014-09-03 09:02

New update is a simple release, with unnecessary patches removed. I've confirmed that the ATI patch still compiles however, as always, its untested beyond that.

kantras commented on 2014-09-03 09:00

Naruni: This pkgbuild only contains the hypervisor and supporting utilities. Its responsible for loading which ever kernel you've specified.

Naruni commented on 2014-09-01 17:08

When booting from UEFI, kernel cannot mount root partition due to "unknown filesystem vfat"

Where are the kernel config options in this pkgbuild?

3.16.1-1-ARCH #1 SMP PREEMPT

Lastebil commented on 2014-08-22 13:37

ryad0m: autoconf is part of base-devel. This is assumed to be installed when using the AUR - see here:
https://wiki.archlinux.org/index.php/Arch_User_Repository

The base-devel group, for reference:
https://www.archlinux.org/groups/x86_64/base-devel/

So no, it should _NOT_ be added to makedepends.

ryad0m commented on 2014-08-22 12:58

Please, add core/autoconf in makedepends

isiachi commented on 2014-08-13 15:24

I think that with the last update of libiscsi (1.7.0-2 -> 1.12.0-1), xen should be recompiled.

kantras commented on 2014-08-10 05:37

Actually the patch, which is different to that one, went in a few weeks later - the current kernels haven't been giving me any issues on the dev machine

zman0900 commented on 2014-08-10 04:27

I think I found something: http://lists.xen.org/archives/html/xen-devel/2014-03/msg02923.html

Looks like a new patch was applied at the same time the old one was reverted. I'm about to upgrade for the first time in about 4 months, so I guess I'll find out if it works...

zman0900 commented on 2014-08-10 02:57

"Just a quick FYI - They've reverted a patch in the recent kernel releases, which may cause instabilities with applications (such as Firefox) running under PV domains (also dom0, which is technically a PV domain). The patch worked for this use case, but broke other things, so the patch was reverted and a new one is being worked on."


Any news on this? Anyone know if a new fix has been merged?

smakovits commented on 2014-07-17 12:10

Traced the issue to the lvm2 hook. Had a working system, added it and things did not boot again. removed the hook and once again the system booted fine. My original installation was on a lv so I needed it there. This time I used linux (83) for rootfs so it was not needed.

I thought i needed it to load a vm when it didnt boot originally, but then the system didnt boot. Removed it and now things are happy again.

hugleo commented on 2014-07-13 15:10

Maybe it can be a video problem. Maybe xen booted but is not showing anything. Try press a key like Num Lock. Dou you notice that the led is blinking? If the answser is true maybe you can set a vesa driver or small resolution on grub boot parameter for xen kernel.

smakovits commented on 2014-07-12 04:12

ever since 4.4.0-3 and Kernel 3.15 my screen goes black upon booting xen. I tried syslinux and Grub with the same results. I re-installed arch at least times, keeping with the beginners guide and then xen install instructions. I have no idea what and why, but the screen just goes black and things require a hard reset.

The normal arch kernel is fine, but nothing I do helps get me going. I even tried using downgrader to try older kernels, but those too had the same result.

trixpan commented on 2014-07-08 13:06

Kantras,

Thanks for the update. Working like a charm.

Any chances of adding Spice support to the PKG?

Cheers

fatal-error commented on 2014-07-06 07:28

Errors when building @kantras:

make[2]: Leaving directory '/[...]/AUR/xen/src/xen-4.4.0/xen'
make[1]: Leaving directory '/[...]/AUR/xen/src/xen-4.4.0/xen'
fatal: unable to connect to xenbits.xen.org:
xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out

Makefile:25: recipe for target 'seabios-dir' failed
make[3]: *** [seabios-dir] Error 128
make[3]: Leaving directory '/[...]/AUR/xen/src/xen-4.4.0/tools/firmware'
/[...]/AUR/xen/src/xen-4.4.0/tools/../tools/Rules.mk:105: recipe for target 'subdir-install-firmware' failed
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory '/[...]/AUR/xen/src/xen-4.4.0/tools'
/[...]/AUR/xen/src/xen-4.4.0/tools/../tools/Rules.mk:100: recipe for target 'subdirs-install' failed
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory '/[...]/AUR/xen/src/xen-4.4.0/tools'
Makefile:96: recipe for target 'install-tools' failed
make: *** [install-tools] Error 2
==> ERROR: A failure occurred in build().
Aborting...

tritron commented on 2014-07-02 15:01

Did anyone compile efi xen and set EFI VENDOR ?

isiachi commented on 2014-07-02 14:59

Hello!

If you try to create an HVM guest with usb=1 you get this message:
libxl: error: libxl_dm.c:1371:device_model_spawn_outcome: domain 1 device model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1186:domcreate_devmodel_started: device model did not start: -3
libxl: error: libxl_dm.c:1475:kill_device_model: Device Model already exited

I solved installing usbredir. It's not a dependecy but an optional one for sure!

isiachi commented on 2014-07-02 14:57

Hello!

If you try to create an HVM guest with usb support you get this message:
libxl: error: libxl_dm.c:1371:device_model_spawn_outcome: domain 1 device model: spawn failed (rc=-3)
libxl: error: libxl_create.c:1186:domcreate_devmodel_started: device model did not start: -3
libxl: error: libxl_dm.c:1475:kill_device_model: Device Model already exited

I solved installing usbredir. It's not a dependecy but an optional one for sure!

kantras commented on 2014-06-20 16:21

Uploading an update - key changes are the addition of two security patches and some initial work to clean up the PKGBUILD and the compiling process.

kantras commented on 2014-06-18 00:15

@ironicbadger: unfortunately I've not been able to reproduce this error yet - can you try building it again, capturing all output to a file, then send me a copy of that file, please? "makepkg >& build.log" should work if you're using a bash shell. Also, have you made any other changes to the PKGBUILD file? Added any other patches? are you up to date with all recent package updates?

I will be uploading a new package sometime soon, but its only cleanup of the PKGBUILD and one of the patches at this point

ironicbadger commented on 2014-06-17 10:41

Having some errors when building @kantras.

Makefile:74: recipe for target 'newlib-1.16.0' failed
make[1]: *** [newlib-1.16.0] Error 1
make[1]: Leaving directory '/root/xen/src/xen-4.4.0/stubdom'
Makefile:104: recipe for target 'install-stubdom' failed
make: *** [install-stubdom] Error 2
==> ERROR: A failure occurred in package().
Aborting...

kantras commented on 2014-06-14 20:35

@atondwal: I just tried rebuilding the package on my build machine and am unable to reproduce the issue you saw. Have you made any other changes to the source (such as adding additional patches)? Have you tried rebuilding from scratch (make sure to delete the src and pkg directories from where you are building the PKGBUILD file)? I'll continue to try some things but without being able to reproduce, its harder to fix.

atondwal commented on 2014-06-14 20:02

I'm getting some problems with the vhd libs during compilation...

https://gist.github.com/atondwal/53dd5fe2bc954c2642b8

lucaoli commented on 2014-06-12 21:52

I've solved KVM issue patching xen-4.4.0/stubdom/Makefile:

*** xen-4.4.0/stubdom/Makefile Mon Mar 10 11:43:57 2014
--- xen-4.4.0/stubdom/Makefile Thu Jun 5 20:10:11 2014
*************** gmp-$(XEN_TARGET_ARCH): gmp-$(GMP_VERSIO
*** 165,171 ****
rm $@ -rf || :
mv gmp-$(GMP_VERSION) $@
#patch -d $@ -p0 < gmp.patch
! cd $@; CPPFLAGS="-isystem $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include $(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" CC=$(CC) $(GMPEXT) ./configure --disable-shared --enable-static --disable-fft --without-readline --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf
sed -i 's/#define HAVE_OBSTACK_VPRINTF 1/\/\/#define HAVE_OBSTACK_VPRINTF 1/' $@/config.h
touch $@

--- 165,171 ----
rm $@ -rf || :
mv gmp-$(GMP_VERSION) $@
#patch -d $@ -p0 < gmp.patch
! cd $@; CPPFLAGS="-isystem $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include $(TARGET_CPPFLAGS)" CFLAGS="$(TARGET_CFLAGS)" CC=$(CC) $(GMPEXT) ./configure --disable-shared --enable-static --disable-fft --without-readline --prefix=$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf --host $(XEN_TARGET_ARCH)
sed -i 's/#define HAVE_OBSTACK_VPRINTF 1/\/\/#define HAVE_OBSTACK_VPRINTF 1/' $@/config.h
touch $@

lucaoli commented on 2014-06-03 21:55

I'm trying to compile xen on a KVM Host, but I receive the following error:

checking compiler gcc -mno-red-zone -O1 -fno-omit-frame-pointer -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-error=maybe-uninitialized -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -fno-stack-protector -fno-exceptions has sizeof(long)==4... no
configure: error: could not find a working compiler, see config.log for details
Makefile:164: recipe for target 'gmp-x86_64' failed
make[1]: *** [gmp-x86_64] Error 1
make[1]: Leaving directory '/home/lucaoli/xen/src/xen-4.4.0/stubdom'
Makefile:104: recipe for target 'install-stubdom' failed
make: *** [install-stubdom] Error 2

In xen-4.4.0/stubdom/gmp-x86_64/config.log I've found:

configure:5631: gcc -mno-red-zone -O1 -fno-omit-frame-pointer -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-str
ict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-error=maybe-uninitialized -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unuse
d-local-typedefs -fno-stack-protector -fno-exceptions -c conftest.c >&5
conftest.c:2:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
main ()
^
conftest.c: In function 'main':
conftest.c:4:14: error: size of array 'test_array' is negative
static int test_array [1 - 2 * (long) (sizeof (long) != 4)];
^

What does mean "could not find a working compiler"?
I think it's normal that on a x86_64 architecture sizeof(long) is 8 and than not 4.

kantras commented on 2014-05-20 00:22

trixpan, I probably will but haven't had a chance to play with it too much yet so want to do that first.

kantras commented on 2014-05-17 16:16

I found out about this patch a couple of days ago - it should be a part of the next release; I'm just checking in case theres anything else to go in, and will upload a new version later today once I've done my usual build-testing

isiachi commented on 2014-05-17 12:00

This patch came from the stable-4.4 branch of xen.

I made this package:
http://downloads.rhyeworld.it/static/xen-4.4.0-3.src.tar.gz
I've already applied the patch.

chetwisniewski commented on 2014-05-17 00:08

I have had the shutdown issue as well. Is this a patch that will be integrated upstream or more of a personal hack?

isiachi commented on 2014-05-16 19:39

Hi! This is a very good package!

I've got only one problem when try to restart or shutdown pvh guests.
The entire xen system stuck and I have to manually reboot the entire system.

I've solved adding this patch:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=3a148e0a7ee0ae56a498be5ba973314ec50cd999

trixpan commented on 2014-05-09 11:11

Kantras,

Not sure what your opinion is about this but it may be a good idea to add a patch to enable SPICE on QEMU upstream (as documented on http://wiki.xenproject.org/wiki/SPICE_support_in_Xen#QEMU_Upstream)

Please note that this would also require adding the following dependencies:

- spice (https://www.archlinux.org/packages/extra/i686/spice/)
- spice-protocol (https://www.archlinux.org/packages/extra/any/spice-protocol/)
- usbredir

Modified PKGBUILD => http://pastebin.com/eiJmLFfe
Patch to enable SPICE => http://pastebin.com/msDz41yT

Cheers

mbroemme commented on 2014-05-09 00:27

Regarding the ATI passthrough patch. It doesn't work anymore with Xen 4.4. I've tried it with two different Radeon cards (7870 GHz and R9 290X).

kantras commented on 2014-05-04 23:51

Updated packages (for xen and xen-4.3) have been uploaded - key changes are the inclusion of the gcc 4.9.0 compile patch (Thanks to the Fedora project), another security patch and a new 09_xen file (uses 10_archlinux as a base, adding in the xen specifics)

kantras commented on 2014-05-03 17:28

methril: Thanks - I had actually spotted that patch already and was adjusting my build environment to make sure I was testing this (and a few other things) before releasing another update later today.

methril commented on 2014-05-03 13:55

Hi all,

I have fixed the xen compilation with gcc 4.9.0
patch (from fedora bugtracking) http://pastebin.com/sGWTSU2s
and PKGBUILD changes http://pastebin.com/rgNsPFhw
(I have enabled ati passthrough)

dante82 commented on 2014-05-02 16:15

Thanks for the package.

When installing I get an error related to the blktap2 drivers in the install-tools package (the same error in the xen-4.3 package):

gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -D__XEN_TOOLS__ -MMD -MF .block-qcow.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -g -Wno-unused -fno-strict-aliasing -I../include -I../drivers -I/home/sneaker15/xen/src/xen-4.4.0/tools/blktap2/drivers/../../../tools/libxc -I/home/sneaker15/xen/src/xen-4.4.0/tools/blktap2/drivers/../../../tools/include -D_GNU_SOURCE -DUSE_NFS_LOCKS -fPIC -c -o block-qcow.o block-qcow.c
block-qcow.c: In function 'get_cluster_offset':
block-qcow.c:431:3: error: 'tmp_ptr' may be used uninitialized in this function [-Werror=maybe-uninitialized]
memcpy(tmp_ptr, l1_ptr, 4096);
^
block-qcow.c:606:7: error: 'tmp_ptr2' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (write(s->fd, tmp_ptr2, 4096) != 4096) {
^
cc1: all warnings being treated as errors


Can someone help?

fmarchand commented on 2014-05-01 19:25

Hi,thanks for the package.
It seems that the "09_xen" grub file does not take into account Btrfs/ZFS FS such as it is done in "10_linux" for example (no "ZFS=" neither "rootflags=" options added in the "module" line).

kantras commented on 2014-04-15 06:46

Just a quick FYI - They've reverted a patch in the recent kernel releases, which may cause instabilities with applications (such as Firefox) running under PV domains (also dom0, which is technically a PV domain). The patch worked for this use case, but broke other things, so the patch was reverted and a new one is being worked on.

trixpan commented on 2014-03-28 13:21

kantras, thank you for the fix.

Being a migrant from debian to arch+xen I it took me a while to pinpoint the grub issue was not some sort of chair <-> keyboard interface on this side of the screen... :-)

I managed to get and Haswell GPU passed through a Linux domU without major issues

kantras commented on 2014-03-27 23:24

@daniel_shub: I had it fixed in my local copy, but was just waiting for something else to include with it - the new 4.4.0-2 that I'm uploading should have a security patch as well as the grub fix (also updating xen-4.3 with the same patch)

daniel_shub commented on 2014-03-27 11:10

Thank you for the great package and keeping it up to date. I had no problem building and installing the package and seems to work great. The only issue I am having is with my GRUB boot menu. Have you gotten a chance to fix the issue with xen-syms? Is it as simple as adding something like

mv boot/$pkgname-syms-* etc/xen/scripts/

after

# Compress syms file
gzip boot/$pkgname-syms-*

although I am not sure why the syms kernel should go in the scripts directory, but I don't know where else to put it.

Oimelchen commented on 2014-03-22 18:05

@ironicbadger: Hi, I saw your blog entry before, but for me, it didn't work with Windows 7. After a reboot of the VM, the Host system did not crash, but I was not able to get the GFX adapter back to life! However, when I reboot the Linux VM (Linux Mint 16), the host system crashed every time! So far, I have not found any solution. If you have an idea, I would be glad to hear about it. :-)

Only the switch to the XM toolkit helped!

ironicbadger commented on 2014-03-22 08:52

@Olmelcehn

All you need do is eject the card from the VM before reboot. I wrote about doing this automatically on Win 8 (I had no joy with 7) here. http://blog.ktz.me/?p=219

Oimelchen commented on 2014-03-22 08:04

Hi, thanks a lot for this package. It builds without any problem (even with the ati-passthrough patch enabled). I was able to passthrough two Radeon 5670 gfx cards to two separate VMs (one to Win7 VM and the other one to a Mint VM, both in secondary passthrough). Unfortunatly when using the xl tool stack, I am not able to restart the VMs, the dom0 totally crashes. So I tried to rebuild this package with enabled xm toolset. When using the same Vms with the xm toolset, every seems to work like charm! This might be a useful hint for those, who try to get to do similar things. :-)

So, as a recommendation, could you add the xm toolset to the PKGBUILD by adding the flag --enable-xend to the configure command? I know, it is deprecated, but at least it is a working alternative (at least for me).

kantras commented on 2014-03-18 13:20

Glad to hear its working - I had suspected it being something like a mismatch between the kernel and the toolset, hence the suggestion to run xl info to confirm. The other command I mentioned was to check that a certain value had been set up correctly in xenstored (its the same one that tritron was referring to) as this is a requirement for xen 4.4. It is in the package but it doesn't hurt to make sure all the basics are covered - often the most simplest issue can be the most annoying, so always check the basics first and build up from there.

3000 commented on 2014-03-18 08:40

wow, when I tried xl info I realized that I copied an earlier Version of xen.efi to my boot Directory. Now the problem is fixed! thanks a lot for your help guys!

tritron commented on 2014-03-17 19:51

I wonder if anyone is interested in getting ovirt running under arch linux since libvirt and xen 4.4 work together now.

kantras commented on 2014-03-17 13:53

you may also find some more details if you turn on more verbose logging when you start the domain, something like: xl -vvvvv create <path to config file>

kantras commented on 2014-03-17 13:48

@3000: to help start to debug this - whats the output from the following commands (run as root):

xl info
xenstore-read /local/domain/0/domid

also, what do you have as the config file for the windows domU and for your grub.cfg file? (can send to me directly if you don't want to post those details)

tritron commented on 2014-03-17 13:36

Does your xenstored.service has a line ExecStartPost=/usr/bin/xenstore-write "/local/domain/0/domid" 0 after
ExecStartPost=/usr/bin/xenstore-write "/local/domain/0/name" "Domain-0"

3000 commented on 2014-03-17 12:59

nope, that doesn't work either :(

thanks anyway!

hugleo commented on 2014-03-17 12:37

The following config works for me:

kernel = "/usr/lib/xen/boot/hvmloader"

builder='hvm'

memory = 1024

device_model='/usr/lib/xen/bin/qemu-dm'

shadow_memory = 8

name = "winxxx"

vif = [ 'mac=00:16:3e:11:11:11,bridge=xenbr0', ]

disk = [ 'phy:/vms/winxx.img,hda,w' ]

boot = "dc"

usb = 1
usbdevice = 'tablet'

vnc = 1
sdl = 0

vncdisplay=1

#keymap='en'

on_xend_stop = 'shutdown'

3000 commented on 2014-03-17 12:15

Hi, just wanted to upgrade. It built fine, without any Problems whatsoever, so great Job kantras! But when I try to start Windows I get this error:

libxl: error: libxl_dom.c:281:libxl__build_post: Failed to set event channel limit to 1023 (-1)
libxl: error: libxl_create.c:1022:domcreate_rebuild_done: cannot (re-)build domain: -3
libxl: error: libxl_dm.c:1467:kill_device_model: unable to find device model pid in /local/domain/3/image/device-model-pid
libxl: error: libxl.c:1421:libxl__destroy_domid: libxl__destroy_device_model failed for 3

what can I do to fix this? thanks a lot!

3000 commented on 2014-03-17 12:12

Hi, just wanted to upgrade. It built fine, without any Problems whatsoever, so great Job kantras! But when I try to start Windows I get this error:

libxl: error: libxl_dom.c:281:libxl__build_post: Failed to set event channel limit to 1023 (-1)
libxl: error: libxl_create.c:1022:domcreate_rebuild_done: cannot (re-)build domain: -3
libxl: error: libxl_dm.c:1467:kill_device_model: unable to find device model pid in /local/domain/3/image/device-model-pid
libxl: error: libxl.c:1421:libxl__destroy_domid: libxl__destroy_device_model failed for 3

kantras commented on 2014-03-11 21:37

So, it should be being ran, the problem would be that the script was modified more than just the default kernel (for example, LTS kernels) and it seems to think that the xen-syms file is another kernel.

I'll update the package (following the old 4.3.2 package by moving syms to a different location) and upload an updated version

hugleo commented on 2014-03-11 21:03

If I generate the grub.cfg are the 09_xen script being executed?
The boot order must be xen-4.4.0.gz kernel to the first place instead of xen-syms

kantras commented on 2014-03-11 16:55

I had two source tarballs prepared - one for whilst I was debugging across multiple systems and one for release - guess which one I uploaded ..

Reuploaded with exit removed.

panda commented on 2014-03-11 13:58

There is a mistake in the PKGBUILD file.

Just before the ATI patch, in the prepare statement, an exit is breaking makepkg.
If this is intentional, please advise.

Tx for the package however.

kantras commented on 2014-03-11 05:03

Since I don't really have the setup/time currently to test it properly (I'm using a hardware modified NVidia card for passthrough) I've included the patch but left it commented out; when uncommented it did build, but is untested.

evilsephiroth commented on 2014-03-10 21:26

do we have to enable the patch in the building process?

kantras commented on 2014-03-10 21:15

Ok, resolved - driver issue within the VM; once I reloaded the drivers, it came up without an issue. Tested loading a game as well as re-evaluating the Windows Experience Index. Uploading the update now.

kantras commented on 2014-03-10 20:24

OK, build tests completed. I've uploaded the new package xen-4.3 for anyone who doesn't want to upgrade to 4.4 yet.

Unfortunately, i'm currently trying out 4.4 on a devel workstation and GPU passthrough isn't working for me. I've started to look into it, as well as research options to resolve; theres been a major rework of qemu-xen which completely breaks the patch we previously used to get this to work better. At this stage, I can upload what I have so far, but be warned that I can't confirm whether gpu passthrough will work for you (as I can't personally do it right now)

kantras commented on 2014-03-10 17:31

@BeepDog: Yes, currently in build-testing
@kingd: am aware, currently in build-testing
@evilsephiroth: I would suspect so; theres not been too much recent changes on that front, from what I've been following on the change log

evilsephiroth commented on 2014-03-10 16:18

xen 4.4 suffers from ati passtrough problems? or the patch has been included?

kingd commented on 2014-03-10 16:15

Xen 4.4 has just been released.
http://blog.xen.org/index.php/2014/03/10/xen-4-4-released

BeepDog commented on 2014-03-10 15:59

We going to have a xen-4.3 aur package? Or not so much? Just curious

Phlogiston commented on 2014-02-28 16:16

Dependency for patch is missing... ;) yes, fresh install.

kantras commented on 2014-02-24 05:00

Good to hear. FYI, I've actually grabbed a copy of the latest xen RC (4.4.0-rc5) and will be testing building it over the next few days, partly to make sure we're ready when its finally released and to see if theres any more optimizations which can be made. The bios patch (which works around buggy IVRS tables) will be retired as the new version allows you to override the IOAPIC and HPET entries via command line options.

zman0900 commented on 2014-02-24 04:32

Thanks. Running 3.13.5 right now (still xen 4.3.1) and the bug appears to be gone :-)

kantras commented on 2014-02-24 04:28

http://lists.xen.org/archives/html/xen-devel/2014-02/msg00199.html - its also on the kernel mailing list as well; I tested it on an earlier kernel in the 3.13 branch and the kernel bug went away.

zman0900 commented on 2014-02-24 04:05

That's great, I'll try that new kernel out right away. Do you happen to have a link to that patch? I'm curious but Google isn't being helpful.

kantras commented on 2014-02-24 03:55

Actually it looks like 3.13.5 just left testing and now is in core, so should find firefox more stable once you've upgraded.

kantras commented on 2014-02-24 03:48

The "firefox" issue is actually a kernel issue - changes were made to how NUMA pages are handled, which causes random crashs within dom0 and/or PV domU's (HVM domUs are not affected) I've been tracking the fix and its been included in the 3.14 RC's as well as the latest 3.13.5 (which you can download from the testing repository.) I have a copy of the patch if you want to recompile your own older kernel (Patch is also available on the xen-devel list archives)

zman0900 commented on 2014-02-24 02:23

@discord, @hugleo: I too have been having the issues with firefox. I'm still running xen 4.3.1, but building 4.3.2 right now to test. Anything after kernel 3.12.6 causes random crashes quickly after starting firefox. After a crash, X is frozen but I can still connect with ssh. No amount of killing or restarting programs will bring it back though. I can see numerous stack traces in dmesg about "bad page map in process firefox". Sometimes "bad page state" instead. Starting firefox in safe mode works, so I deleted and resynced my profile then started re-enabling addons one by one, but I can't seem to isolate the problem so I've also switched to Chrome for now. At first I though it was graphics related, but the crash still happens if I start firefox over ssh X forwarding to another machine. Doesn't seem to be hardware related either since I've recently switched motherboard and gpu (from using nouveau to radeonsi).

Let us know here if anyone has any luck with this problem, I'm quite partial to Firefox. I'll post my results of testing 4.3.2 soon.

kantras commented on 2014-02-20 06:51

4.3.2-1 has just been uploaded after build-testing on a couple of boxes. Apart from the version bump, this build attempts to download several of the source tarballs ahead of time - this means that we can ensure they are not corrupted/changed before they are used during compile.

ironicbadger commented on 2014-02-15 23:36

if it helps...

http://unraidrepo.ktz.me/xen-4.3.1-2-x86_64.pkg.tar.xz

k1.hedayati commented on 2014-02-15 19:32

install -m0755 -p mini-os-x86_32-vtpmmgr/mini-os.gz "~/Downloads/xen/pkg/xen/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
make[1]: Leaving directory '~/Downloads/xen/src/xen-4.3.1/stubdom'
gzip: boot/xen-syms-4.3.1: No such file or directory
==> ERROR: A failure occurred in package().
Aborting...

:((

ironicbadger commented on 2014-02-01 19:53

gets my vote.

kantras commented on 2014-02-01 19:52

Just wanted to give a heads up on my thoughts; With upcoming releases of xen 4.3.2 and 4.4.0 coming soon, what I may do is rename this package to 'xen-4.3' and then update the PKGBUILD to 4.4.0 and release that as xen.

hugleo commented on 2014-01-27 18:42

Crashed again, a little more stable however.

hugleo commented on 2014-01-27 15:09

I think the upgrade do the trick.
discord, try to upgrade your system.

hugleo commented on 2014-01-27 11:18

I've experienced that problem too.
Everytime I open firefox browser I notice cpu racing and I must restart my system due a unresponsive system. I'm using chrome browser for now.
That problem comes about tree weeks ago after a bunches of arch updates.
Today I'll upgrade to the new kernel linux-3.12.9-1 and I'll let you know if that solve the problem.

kantras commented on 2014-01-25 21:13

@discord - I've personally not experienced that issue on any of the deployments that I've performed with xen, or had anyone else report that issue recently (either on here or via the xen-users mailing list) What I would suggest doing is posting a question on the xen-users email group, including information which would be useful in helping to find out what exactly the issue you are experiencing is; details like hardware specs, configuration options, results from log files, etc - like any kind of mystery, you need to be gathering all the clues to be able to solve a problem.

discord commented on 2014-01-25 19:39

My system has been crashing frequently after installing the xen package. Even without running any domU's. I look at top when the cpu is racing. I've seen kworker hogging the cpu. I've seen mplayer hogging the cpu. Sometimes when I run htop I see 30 firefox processes but only one in regular top. Haven't had any stability issues without xen, or with the grub option without xen.

ironicbadger commented on 2014-01-13 18:57

compiles great, but i have no HDMI audio when booted from the xen kernel. am i alone with intel graphics on a xeon 1245 with this issue? as i say stock kernel fine, xen kernel no audio.

3000 commented on 2014-01-13 18:41

wow, thanks a lot @ zman0900, that did the trick indeed!

Working quite nicely

michaelharwood commented on 2013-12-30 03:02

@malinas - I had the same issue and it appears it is a problem with git://xenbits.xen.org/seabios.git. I manually cloned the seabios folder using git clone http://xenbits.xen.org/git-http/seabios.git in the correct folder and restarted the Arch package build process and it's running fine now.

zman0900 commented on 2013-12-27 16:24

@3000: You need to recompile binutils from ABS with the required options. Details are farther down in the comments.

3000 commented on 2013-12-27 16:21

hi, I gotta question: I am trying Xen on a new archlinux system and it compiled just fine. BUT it didn't create a xen.efi.

do you guys know why?

kantras commented on 2013-12-25 21:30

@malinas Hmm, will try again in a little while - my primary dev machine was down for a couple of days, but is back so can do some more testing.

malinas commented on 2013-12-25 13:47

@kantras.. ye.. well, indeed something has happened. I could compile some days ago, but somehow have not had the package saved.. Now when I try to compile, it seems to fail on the seabios (patch?) recipe in makefile.

malinas commented on 2013-12-21 19:30

@kantras.. np. I have to say I also built in the end fine, just 3 days ago or so.

Just want to add, thanks for keeping this updated and man is Xen awesome!!! :)

kantras commented on 2013-12-19 20:21

@meltfund: That looks like one of the dependancies might not have downloaded correctly (during compile, the Makefiles pull down a number of additional sources, patch and compile against them) - I'm currently modifying the PKGBUILD to download those before compile, confirm they downloaded correctly, then copy them into place so the build scripts can make use of them) - should have a new version uploaded later today (after I've finished a couple of build tests - both on bare metal and under a virtual environment)

meltfund commented on 2013-12-19 19:15

Similar build problem on this system today

http://pastebin.com/nHgDssf2

meltfund commented on 2013-12-19 19:14

Built fine on this system last week

http://pastebin.com/AfKiQLrt

meltfund commented on 2013-12-19 19:10

Builds fine on this system

OS: ArchBang x86_64
/\ Hostname: laptop
.;#. Kernel: 3.12.1-1-ARCH
/####\ Uptime: 1
;## #; Window Manager: openbox
+### .## Packages: 600
+#### ;### RAM: 623 / 3777 MB
###### #####; CPU: Intel(R) Core(TM) i5-3317U CPU
####### ###### Shell: bash
######## ######## Root: 11G / 14G (ext4)
.########;;########;
.########; ;#######
#########. .########;
######' '######
;#### ####;
##' '##
#' '#

[robin@laptop ~]$ pacman -Qi xen
Name : xen
Version : 4.3.1-2
Description : Virtual Machine Hypervisor & Tools
Architecture : x86_64
URL : http://www.xenproject.org/
Licences : GPL2
Groups : None
Provides : None
Depends On : bin86 bluez bridge-utils curl e2fsprogs gnutls iproute2
libaio libcap-ng libiscsi libjpeg-turbo libpng lzo2 nss
pixman pciutils python python2 sdl wget vde2 yajl
lib32-glibc
Optional Deps : xen-docs: Official Xen Documentation [installed]
openvswitch: Optional Networking support
Required By : None
Optional For : None
Conflicts With : xen-4.2 xen-4.2-testing-hg xen-gdbsx xen-hg-unstable xen-rc
xen-git xen-4.3 xen-4.3-testing-hg
Replaces : None
Installed Size : 52598.00 KiB
Packager : Unknown Packager
Build Date : Sun 15 Dec 2013 18:14:42 GMT
Install Date : Sun 15 Dec 2013 18:15:27 GMT
Install Reason : Explicitly installed
Install Script : Yes
Validated By : None

meltfund commented on 2013-12-19 19:02


OS: ArchBang x86_64
/\ Hostname: desktop
.;#. Kernel: 3.12.5-1-ARCH
/####\ Uptime: 28
;## #; Window Manager: openbox
+### .## Packages: 591
+#### ;### RAM: 560 / 3516 MB
###### #####; CPU: Intel(R) Pentium(R) D CPU 2.80GHz
####### ###### Shell: bash
######## ######## Root: 13G / 29G (ext4)

Worked fine a few days ago on a Core i5 laptop.

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Makefile:148: recipe for target 'lwip-x86_64' failed
make[1]: *** [lwip-x86_64] Error 2
make[1]: Leaving directory '/home/robin/builds/xen/src/xen-4.3.1/stubdom'
Makefile:86: recipe for target 'install-stubdom' failed
make: *** [install-stubdom] Error 2
==> ERROR: A failure occurred in package().
Aborting...

thouveng commented on 2013-12-19 16:17

@kantras: In fact it is a little bit strange because I've two laptops and both have archlinux 64bits installed. The problem occurs only on one of them. It is a Dell latitude E5520 and I'm trying to build xen directly on the baremetal, I mean I'm not inside a VM or a container.

kantras commented on 2013-12-19 06:27

I've been trying to reproduce both the compile issues listed and still am unable to; all rebuild attempts have been successful. I'm going to continue to try and reproduce the issues, but if people could share more details on the hardware that they are trying to build on, that may help narrow things down

amber commented on 2013-12-19 03:43

ld -nostdlib -L/tmp/yaourt-tmp-root/aur-xen/src/xen-4.3.1/stubdom/cross-root-i686/i686-xen-elf/lib -m elf_i386 -T arch/x86/minios-x86_32.lds /tmp/yaourt-tmp-root/aur-xen/src/xen-4.3.1/stubdom/mini-os-x86_32-vtpmmgr/mini-os.o -o /tmp/yaourt-tmp-root/aur-xen/src/xen-4.3.1/stubdom/mini-os-x86_32-vtpmmgr/mini-os
ld: warning: section `.bss' type changed to PROGBITS
gzip -f -9 -c /tmp/yaourt-tmp-root/aur-xen/src/xen-4.3.1/stubdom/mini-os-x86_32-vtpmmgr/mini-os >/tmp/yaourt-tmp-root/aur-xen/src/xen-4.3.1/stubdom/mini-os-x86_32-vtpmmgr/mini-os.gz
make[2]: Leaving directory '/tmp/yaourt-tmp-root/aur-xen/src/xen-4.3.1/extras/mini-os'
install -d -m0755 -p "/tmp/yaourt-tmp-root/aur-xen/pkg/xen/usr/lib/xen/boot"
install -m0755 -p mini-os-x86_32-vtpmmgr/mini-os.gz "/tmp/yaourt-tmp-root/aur-xen/pkg/xen/usr/lib/xen/boot/vtpmmgr-stubdom.gz"
make[1]: Leaving directory '/tmp/yaourt-tmp-root/aur-xen/src/xen-4.3.1/stubdom'
gzip: boot/xen-syms-4.3.1: No such file or directory
==> ERROR: A failure occurred in package().
Aborting...
==> ERROR: Makepkg was unable to build xen.

I have builded xen twice.
xen is 4.3.1

kantras commented on 2013-12-18 14:24

@malinas: Thanks, will get that added in

@thouveng: I'm retesting building right now to try and reproduce - the file in question is the defaults for the xendomains script (used when you want to auto-start domUs on startup) so isn't critical if not using it

malinas commented on 2013-12-18 13:15

libseccomp is missing as a dependency, which makes launching domU's a no go.

thouveng commented on 2013-12-17 18:13

I still have the same problem.
To fix it I commented the following line in function package() in PKGBUILD:

mv etc/default/xendomains etc/conf.d/xendomains

Now it seems OK but I didn't know what is the impact of this comment? At the end of the log there are two warnings about backup entry file that is not in package.

make[1]: Leaving directory '/home/thouveng/builds/xen/src/xen-4.3.1/stubdom'
==> Tidying install...
-> Purging unwanted files...
-> Removing libtool files...
-> Removing static library files...
==> WARNING: backup entry file not in package : etc/conf.d/xendomains
==> WARNING: backup entry file not in package : etc/default/xencommons
-> Compressing man and info pages...
==> Creating package "xen"...
-> Generating .PKGINFO file...
-> Adding changelog file...
-> Adding install file...
-> Generating .MTREE file...
-> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: xen 4.3.1-2 (Tue Dec 17 19:08:40 CET 2013)

Refutationalist commented on 2013-12-12 18:12

Sorry, replace "Xen" with "KVM" in that last comment. I use xen on servers, kvm on desktops.

Refutationalist commented on 2013-12-10 21:36

Got it. I was compiling it under Xen, and without a specific CPU definition configured, gmp assumes that you're in 32bit, and compilation fails. Defined a CPU and it compiled fine.

Refutationalist commented on 2013-12-09 20:23

Having the same issue, but higher up in the log there's a thrown error about gmp:

test -z "/usr/local/share/info" || mkdir -p -- . "/usr/local/share/info"
mkdir: cannot create directory '/usr/local/share/info': Permission denied
Makefile:482: recipe for target 'install-info-am' failed
make[5]: *** [install-info-am] Error 1
make[5]: Leaving directory '/home/sam/xen/src/xen-4.3.1/stubdom/gmp-x86_64/doc'
Makefile:437: recipe for target 'install-am' failed
make[4]: *** [install-am] Error 2
make[4]: Leaving directory '/home/sam/xen/src/xen-4.3.1/stubdom/gmp-x86_64/doc'
Makefile:925: recipe for target 'install-recursive' failed
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory '/home/sam/xen/src/xen-4.3.1/stubdom/gmp-x86_64'
Makefile:1191: recipe for target 'install' failed
make[2]: *** [install] Error 2
make[2]: Leaving directory '/home/sam/xen/src/xen-4.3.1/stubdom/gmp-x86_64'
Makefile:175: recipe for target 'cross-root-x86_64/x86_64-xen-elf/lib/libgmp.a' failed
make[1]: *** [cross-root-x86_64/x86_64-xen-elf/lib/libgmp.a] Error 2
make[1]: *** Waiting for unfinished jobs....

thouveng commented on 2013-12-08 17:43

It seems that compilation goes well but an error occurs during packaging.

[thouveng:~/builds/xen] $ tail xen-4.3.1-2-x86_64-package.log
ld -nostdlib -L/home/thouveng/builds/xen/src/xen-4.3.1/stubdom/cross-root-i686/i686-xen-elf/lib -m elf_i386 -T arch/x86/minios-x86_32.lds /home/thouveng/builds/xen/src/xen-4.3.1/stubdom/mini-os-x86_32-grub/mini-os.o -o /home/thouveng/builds/xen/src/xen-4.3.1/stubdom/mini-os-x86_32-grub/mini-os
ld: warning: section `.bss' type changed to PROGBITS
gzip -f -9 -c /home/thouveng/builds/xen/src/xen-4.3.1/stubdom/mini-os-x86_32-grub/mini-os >/home/thouveng/builds/xen/src/xen-4.3.1/stubdom/mini-os-x86_32-grub/mini-os.gz
make[2]: Leaving directory '/home/thouveng/builds/xen/src/xen-4.3.1/extras/mini-os'
install -d -m0755 -p "/home/thouveng/builds/xen/pkg/xen/usr/lib/xen/boot"
install -m0644 -p mini-os-x86_32-grub/mini-os.gz "/home/thouveng/builds/xen/pkg/xen/usr/lib/xen/boot/pv-grub-x86_32.gz"
make[1]: Leaving directory '/home/thouveng/builds/xen/src/xen-4.3.1/stubdom'
mv: cannot stat ‘etc/default/xendomains’: No such file or directory
==> ERROR: A failure occurred in package().
Aborting...

kantras commented on 2013-11-25 10:28

AUR packages updated, also included the three latest security patches

Sydney6 commented on 2013-11-25 03:53

Yes, you can.

j-lap commented on 2013-11-25 03:50

@zman0900 - Already installed "bluez", no dice. Build fails because it is looking for dependency "bluez4".

Can I simply edit "bluez4" to "bluez" in the PKGBUILD?

zman0900 commented on 2013-11-25 03:40

@j-lap: Just change to bluez. Either version will work.

j-lap commented on 2013-11-25 03:00

Package dependency "bluez4" isn't available in repos or AUR.

Can't build.

Fidelix commented on 2013-11-09 00:27

Never mind, I managed to do that by editing the Makefile.
Thanks!

Fidelix commented on 2013-11-08 23:06

@Kantras, thank you very much.
Do you know how to configure qemu to use the compile options --audio-drv-list="pa alsa" ? I'm needing this

kantras commented on 2013-11-07 21:37

@Fidelix: I've not tried to do this recently, however the last time I tried I noticed that one of the requirements is not currently available in Arch Linux - the issue being that binutils isn't built with support for the specific target needed (x86_64-pep). I just checked the bug reporting tool and it appears that this is still the case - https://bugs.archlinux.org/task/36713 - so, if you want to do this, you'll have to rebuild binutils-multilib with support for that target added.

Fidelix commented on 2013-11-07 20:55

How do I build xen with UEFI support?

devnull_1337 commented on 2013-11-03 11:38

this fixed/stabilized intel hd 2500 (i5-3470) vga passthrough for me. thanks a lot.

kantras commented on 2013-10-31 22:28

v4.3.1 is released - I had to rebuild the ATI and bios patches, as the sources changed, but have tested compile with both patches enabled and disabled.

Sydney6 commented on 2013-10-23 16:00

Hello Kantras,

after your previous post i looked into the file-list for the ocaml-package and indeed your were right, libasmrun.a is listed but not packaged. But you were that quick in return, i couldn’t even answer.. Anyhow, thank you very much for your help and for maintaining this package.

kantras commented on 2013-10-23 15:54

I confirmed the issue was with missing libraries in the ocaml package, so went ahead and reported the issue. They released ocaml 4.01.0-3 in response. I've updated to that package and verified that compile issue was resolved.

kantras commented on 2013-10-23 08:05

I suspect that the recent update to ocaml is broken - the file listed in that error used to be in that package

Sydney6 commented on 2013-10-22 23:57

Hello Everybody,

the 4.3.0-7 build seems to fail with following output.

File "caml_startup", line 1:
Error: Cannot find file libasmrun.a
/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/ocaml/xenstored/../Makefile.rules:94: recipe for target 'oxenstored' failed
make[5]: *** [oxenstored] Error 2
make[5]: Leaving directory '/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/ocaml/xenstored'
/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/ocaml/../../tools/Rules.mk:105: recipe for target 'subdir-install-xenstored' failed
make[4]: *** [subdir-install-xenstored] Error 2
make[4]: Leaving directory '/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/ocaml'
/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/ocaml/../../tools/Rules.mk:100: recipe for target 'subdirs-install' failed
make[3]: *** [subdirs-install] Error 2
make[3]: Leaving directory '/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/ocaml'
/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/../tools/Rules.mk:105: recipe for target 'subdir-install-ocaml' failed
make[2]: *** [subdir-install-ocaml] Error 2
make[2]: Leaving directory '/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools'
/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/../tools/Rules.mk:100: recipe for target 'subdirs-install' failed
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory '/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools'
Makefile:74: recipe for target 'install-tools' failed
make: *** [install-tools] Error 2

Any suggestions?

kantras commented on 2013-10-04 07:44

Ok, just released an update - quick changes: added a pre_remove section to handle stopping and disabling systemd services before the package is removed. Also added the latest XSA patches (security advisories)

Note: for anyone who was looking into gfx passthrough with a plain nvidia gtx card, I'd suggest checking out the archives at http://www.davidgis.fr/blog/

BenderIsGreat34 commented on 2013-10-03 15:07

It looks like xenstored (and the other services, too) isnt getting disabled when you uninstall xen. It produces log outputs since the service isnt available anymore.

kantras commented on 2013-09-29 05:39

I personally haven't tried recently - when I first started to play with gfx passthrough some initial research showed that GeForce cards & drivers didn't really like to be virtualized, so I picked up the Radeon 6770, used the GeForce 550 Ti for my dom0 and passed the 6770 through to Windows. This was several months ago now, and I ended up switching out the 550 because the Nvidia binary drivers didn't like to be run under dom0 either. My lab server doesn't currently support IOMMU so can't test easily if thats changed. I have been watching some developments of people modifying their GeForce cards to pretend to be Quadro cards (Quadros have much better virtualization support) and their stories appear to be mostly successful - examples would be http://www.davidgis.fr/blog/index.php?2013/09/18/969-xen-430-vga-passthrough-gtx-480-soft-moded-to-quadro-6000 and http://www.altechnative.net/2013/09/17/virtualized-gaming-nvidia-cards-part-2-geforce-quadro-and-geforce-modified-into-a-quadro-higher-end-fermi-models/ (note: newer GeForce mods require hardware changes, earlier can be done by flashing a modified bios)

ido commented on 2013-09-29 00:30

kantras: thank you for taking this on!

I tried to get gfx passthrough (PCIe passthrough of a NVidia GeForce 660 card) working a few months ago and failed. Do you have pass-through working for an NVidia GeForce card currently or recently? (This is off-topic so if you want to take it to email, please feel free to email me.)

kantras commented on 2013-09-29 00:13

Ok, the latest v4.3.0-5 version has been uploaded. If anyone needs the 4.2 version, that should be still available via the previous link (and I can backport fixes if still needed)

kantras commented on 2013-09-28 23:28

@ironicbadger: This is a known issue when dealing with passing through ATI graphics cards - the graphics card isn't reset and the graphics drivers don't do it either. There has been success when using an Nvidia Quadro card (or a GeForce which has been modified to look like a Quadro - the Nvidia Quadro drivers are better designed for handling virtualized environments) I'm also watching some discussion on the xen-devel list about other ways this could be tackled but nothing available there yet.

kantras commented on 2013-09-28 23:22

I had offered, we just hadn't been around at the same time to be able to transfer :)

shanmu commented on 2013-09-28 21:05

Kantras, please take ownership :)

karol_007 commented on 2013-09-28 11:45

shanmu isn't very active with this package, kantras, have you thought about maintaining it?
Your PKGBUILD fixes at least some bluez v. bluez4 issues: https://bbs.archlinux.org/viewtopic.php?pid=1330200#p1330200

ironicbadger commented on 2013-09-05 19:24

Comment by zman0900
2013-08-25 23:29
4.3.0-4 with the ATI Passthrough patch works for me for my Windows 8 + ATI HD7850 HVM setup. I had to add 'device_model_version="qemu-xen-traditional"' to my config, but no other changes were necessary.


This worked for me too in so far as getting the VGA passthrough working, with the ATI patch applied to 4.3.0-4, with a 7970. It works great until I reboot the domU at which point the GPU is not reinitialized and only VNC access is available. If I reboot the dom0 then all is well. Is there a script I can run that will trick the GPU into resetting once the domU has shutdown?

kantras commented on 2013-08-30 22:44

@zootboy, @zman0900: Thanks for the feedback. I've updated my local staged copy with fixes for 09_xen and will be testing the other reported issue as well. If no-one has any other issues/etc, should be uploading a new copy over the weekend (also need to go through the xen-user and xen-devel lists to get back up to speed on any other fixes, etc)

zman0900 commented on 2013-08-28 22:14

I put in a feature request with binutils-multilib to get the necessary feature enabled for xen.efi to build. If you have UEFI and would like to not have to rebuild binutils after updates, consider voting for this: https://bugs.archlinux.org/task/36713

zootboy commented on 2013-08-27 15:15

The 09_xen GRUB file does not properly handle detecting the linux-lts kernel files. Here's a patch to fix it (and also the ro/rw thing):
http://www.zootboy.com/storage/09_xen.patch

zootboy commented on 2013-08-27 15:13

The 09_xen GRUB file does not properly handle detecting the linux-lts kernel files. Here's a patch to fix it (and also the ro/rw thing):

--- a/09_xen 2013-04-10 21:25:09.000000000 -0400
+++ b/09_xen 2013-08-27 11:05:01.540000926 -0400
@@ -55,7 +55,7 @@
echo '$(printf "Loading Xen %s ..." ${xen_version})'
multiboot ${rel_dirname}/${xen_basename} ${rel_dirname}/${xen_basename} ${xen_args}
echo $(printf "$(gettext "Loading Linux %s ...")" ${version})
- module ${rel_dirname}/${basename} ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}
+ module ${rel_dirname}/${basename} ${rel_dirname}/${basename} root=${linux_root_device_thisversion} rw ${args}
EOF
if test -n "${initrd}" ; then
cat << EOF
@@ -82,7 +82,9 @@
xen_version=`echo $xen_basename | sed -e "s,^[^0-9]*-,,g" | sed -e "s,.gz,,g"`
alt_xen_version=`echo $xen_version | sed -e "s,\.old$,,g"`

- list="/boot/vmlinuz-linux";
+ list=$(for i in /boot/vmlinuz* ; do
+ if grub_file_is_not_garbage "$i" ; then echo -n "$i "; fi
+done)

while [ "x$list" != "x" ] ; do
linux=`version_find_latest $list`

zman0900 commented on 2013-08-25 23:29

4.3.0-4 with the ATI Passthrough patch works for me for my Windows 8 + ATI HD7850 HVM setup. I had to add 'device_model_version="qemu-xen-traditional"' to my config, but no other changes were necessary.

zman0900 commented on 2013-08-25 22:11

@kantras: Package fails for 4.3.0-4 in the 'sanitize library path' section. It does `cd usr/` causing the next gzip command to not find the expected files. You should add `cd ..` right after `rm -rf lib64`

zman0900 commented on 2013-08-25 21:49

@kantras: The default for Arch now seems to be passing rw instead of ro on the kernel commandline, based on the 10_linux file from grub2. When I boot with ro systemd gives a warning about not being able to fsck. You should probably change the 09_xen file.

kantras commented on 2013-08-14 07:20

Ok, the new build is up on my website: http://www.kantras.info/xen/xen-4.3.0-4.tgz - it has the TOM register patch (the one which helps with the >3Gb memory assignment) as well as a little more cleanup (more to come) I've also included the ATI Passthrough patch, although its not enabled by default and so far I've only made sure that it would still compile if enabled

evilsephiroth commented on 2013-08-14 06:22

ok.
With qemu-xen-traditional the domU seems pretty stable so I'm not in a hurry.

kantras commented on 2013-08-14 04:40

@tritron I've not tried opennebula yet - not had a need to.

kantras commented on 2013-08-14 04:38

OK, having been playing with that patch I mentioned, I found out it requires additional code which doesn't exist yet (and the PCI Passthrough issue is still listed as outstanding for 4.4, so no sign of an official patch yet) but found other references to the one you've mentioned so am going to clean it up a touch, add, test, and then will upload.

tritron commented on 2013-08-12 01:39

Did anyone compiled this package with qemu git? This could solve the issue?
Is anyone using opennebula with xen ?

kantras commented on 2013-08-12 00:33

I'm also using qemu-xen-traditional, which is why I guess I wasn't affected. I've just spent an hour or so going back through the history on that patch; it was rejected for multiple reasons, including the mechanism used as well as the change occuring too late in the boot up sequence. A workaround patch was sent to the qemu-devel list but I don't know that it was included in time (my build sources show no sign on the patch http://marc.info/?l=qemu-devel&m=137043414711228&q=raw )

I'm going to work on getting this newer patch into place in my AUR package, and will post here when the new version is uploaded into my web space. I'm also looking into becoming the maintainer of this package, so I can help keep it up to date.

evilsephiroth commented on 2013-08-11 21:59

radeon 6570 to windows 7 hvm domu but the limit persists also with discrete card...

Strange but true :D

evilsephiroth commented on 2013-08-11 21:52

Thanks.
At the moment,I solved the memory issue adding device_model_version = 'qemu-xen-traditional' to the hvm win7 domu conf file...

Doing this, I lost completely vnc capabiliities for domU, so the patch would be greatly appreciated...

Thanks again...

kantras commented on 2013-08-11 20:31

I've not included that patch yet, since I'm not currently affected (have gfx passthrough of a radeon 6770 to a window 7 HVM domU, with 6Gb of RAM). I remember seeing that patch around on the mailing list ; let me recheck the context and I can add it in (the file paths listed in the patch don't mention which subsection it'srelated to)

evilsephiroth commented on 2013-08-11 10:42

Hi kantras, I've successfully installed your xen package for 4.3.0 but I'm suffering the 3gb memory limitation when passing gpu to hvm domU(win7).

Have you included this patch in the package?
http://marc.info/?l=qemu-devel&m=136177475215360&q=raw
If not, how can I patch the source and reinstall the package?

Thanks a lot for your efforts...

evilsephiroth commented on 2013-08-11 10:42

Hi kantras, I've successfully installed your xen package for 4.3.0 but I'm suffering the 3gb memory limitation when passing gpu to hvm domU(win7).

Have you included this patch in the package?
http://marc.info/?l=qemu-devel&m=136177475215360&q=raw
If not, how can I patch the source and reinstall the package?

Thanks a lot for your efforts...

evilsephiroth commented on 2013-08-11 09:09

Hi kantras, I've successfully installed your xen package for 4.3.0 but I'm suffering the 3gb memory limitation when passing gpu to hvm domU(win7).

Have you included this patch in the package?
http://marc.info/?l=qemu-devel&m=136177475215360&q=raw
If not, how can I patch the source and reinstall the package?

Thanks a lot for your efforts...

kantras commented on 2013-08-11 05:12

I have a patch for that error - I believe its at http://www.kantras.info/xen/aur-xen-4.2.2-2/texi2html.patch . You can also download updated versions of this package from http://www.kantras.info/xen/ - I have two there right now, one for 4.2.2 and one for 4.3.0

Anonymous comment on 2013-08-11 04:59

Hi, I have an error today,
...
pod2man --section=1 --center=" " --release=" " qemu.pod > qemu.1
qemu.pod around line 91: Non-ASCII character seen before =encoding in 'Sch�tz.'. Assuming UTF-8
POD document had syntax errors at /usr/bin/core_perl/pod2man line 71.
make[3]: *** [qemu.1] Error 255
...

kantras commented on 2013-08-08 05:59

I've not come across that one yet - I'll try to get something set up on a test machine and test

hugleo commented on 2013-07-31 15:06

I've been noticing a litle problem. If I shutdown my xen host machine the xendomains service take care of the situation and save the state of the guests machines. However If reboot my xen host machine the xendomains job service stay running and never stop.

kantras commented on 2013-07-31 07:33

I've spent a little time cleaning up the PKGBUILD, so now have a new version available: http://www.kantras.info/xen/xen-4.3.0-3.tar.gz The new release also now includes a Change Log, so you can see what changes were made between releases.

zootboy commented on 2013-07-25 13:45

@mryanbrown
You need to enable the multilib repository to use the Xen package.

Anonymous comment on 2013-07-25 09:16

I tried to install this with:

packer -S xen

and received:

Dependency 'dev86' of 'xen' does not exist.

kantras commented on 2013-07-19 21:02

Ok, I've just updated and released a new version: http://www.kantras.info/xen/xen-4.3.0-2.tar.gz . It contains fixes for the xenstored config file, as well as to xendomains. I've also added in some patches to xendomains which mean you don't have to set the output_format - for xl, it uses the json output (which is the default)

hugleo commented on 2013-07-19 19:25

Just change the XENDOM0_NAME="Phoenix" to XENDOM0_NAME="Domain-0" in the file ./conf.d-xenstored

kantras commented on 2013-07-19 15:44

I'll look into that one - the xendomains script is supposed to be checking whether /etc/conf.d exists, and then using it for the config file. I'll fix it and upload a new version a little later today (not at my workstation right now). Anything else you noticed?

Also, if you are using xendomains and xl, make sure you read the note when installing/upgrading about the change needed to /etc/xen/xl.conf; you have to add the following line (otherwise the script won't understand the format correctly):

output_format="sxp"

hugleo commented on 2013-07-19 14:50

It's working perfectly here.
Just to note that for the xendomains.service is causing a error due the lack of the file /etc/default/xendomains

-- Unit xendomains.service has begun starting up.
Jul 19 11:33:15 radiolinux xendomains[1108]: /etc/default/xendomains not existing
Jul 19 11:33:15 radiolinux systemd[1]: xendomains.service: main process exited, code=exited, status=6/NOTCONFIGURED
Jul 19 11:33:15 radiolinux systemd[1]: Failed to start Xendomains - start and stop guests on boot and shutdown.
-- Subject: Unit xendomains.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/be02cf6855d2428ba40df7e9d022f03d
--
-- Unit xendomains.service has failed.

kantras commented on 2013-07-18 21:41

Ok, I've posted an updated version of this package to my website, and it now is using xen-4.3.0 - http://www.kantras.info/xen/xen-4.3.0-1.tar.gz

Fixes (highlights) :
* No longer conflicts with qemu
* Added in template configuration files for xenconsoled and xenstored

kantras commented on 2013-07-18 00:15

I'm going to try and update my build to support xen-4.3 this evening; Just been waiting for a little time after the release for any show stopping bugs to be reported

hugleo commented on 2013-07-11 13:19

For the future of this package I think is better to accept the last kantras suggestions: http://www.kantras.info/xen/xen-4.2.2-2.tgz and rename this package to xen-4.2

Anonymous comment on 2013-07-10 06:58

@revellion I have solve the problem.
I export LC_ALL=C and export LANG=C, and it works

Anonymous comment on 2013-07-10 06:49

@revellion, I have the same problem with @deviousway.

Traceback (most recent call last):
File "./tools/layoutrom.py", line 583, in <module>
main()
File "./tools/layoutrom.py", line 564, in main
info16 = parseObjDump(infile16, '16')
File "./tools/layoutrom.py", line 501, in parseObjDump
relocsection = sectionmap[sectionname]
KeyError: '.text.asm.src/smp.c.68'
make[6]: *** [out/romlayout16.lds] 错误 1

I have try export LANG=C
And I also export LC_ALL=en_US.UTF-8, but it still can't work.

tritron commented on 2013-06-17 12:55

Well nice think about Linux is that you can exclude stuff you don't need. So if you don't want to have a bluez then you should disable it --disable-bluez on config line. When package requires blues libs it means that you included bluez dev files when you compiled Xen.

Lastebil commented on 2013-06-17 12:39

I'd agree to that as well - and I'll see if I can't cover a few things on the wiki clearly that are wrong (sdl is an option instead of vnc, for example; SPICE, and links to the various options such as Viridian, OVMF ...)

That said, I'm not using SPICE - is anyone?

Anonymous comment on 2013-06-17 12:06

@Lastebil, my HVM config is essentially the one on the Arch Wiki (https://wiki.archlinux.org/index.php/Xen#Configuring_a_hardware_virtualized_.28HVM.29_Arch_domU).

I would propose that the package build only require the packages to get a dom0 setup. Packages only required for running either a PV and/or HVM should be _optional_. One could then create xen-pv and xen-hvm dummy packages to load the required packages or we could list these optional packages on the wiki.

Lastebil commented on 2013-06-17 07:49

I am, but I haven't on that machine. I'll build another later and see what the issue is. Can you post your hvm config?

I would propose that the packagebuild be set up to put bluez as _optional_ if you need HVM, as it isn't needed for PVM.

Anonymous comment on 2013-06-14 13:18

@Lastebil I was unable to create a HVM domU without the bluez-libs package. Are you using any HVM domUs?

tritron commented on 2013-06-12 12:29

At www.thexenguy.com/forums i posted my package sources xen-api xen-api-libs

Lastebil commented on 2013-06-12 10:06

It builds perfectly fine without bluez (or bluez4) and if you don't care to have bluetooth, it's not needed.

(In my case, I'm a good 8km from the machines with xen - fully remote, serial consoles, etc - so I definately don't need bluetooth. It's range isn't anywhere near 8km (: )

I also am very interested in the xen-api stuff, if we end up setting up a mailing list or whatever, ping me, please.

kantras commented on 2013-06-08 04:46

You can simply change 'bluez' to 'bluez4' in the PKGBUILD and it will work. Having said that, I wonder if its even really needed - I know qemu references it, but I don't see why it would need it. Something to test

hugleo commented on 2013-06-07 12:09

Or xen can compile selecting bluez version 5

hugleo commented on 2013-06-07 12:02

Now is needed to replace the bluez dependence with bluez4.

kantras commented on 2013-06-05 15:37

Actually I was already intending to look into what it would take to do that; I'm wanting to rebuild one of my main systems and this sounded like an interesting thing to add

kantras commented on 2013-06-05 15:37

Actually I was already intending to look into what that would take; I'm wanting to rebuild one of my main systems and this sounded like an interesting thing to add

tritron commented on 2013-06-05 15:30

We should start working on xen-api for arch linux.

kantras commented on 2013-06-05 15:29

Looking back over my notes, the other thing which was added was the ability to change the 'name'of the dom0 automatically on startup. Simply add a line 'XENDOM0_NAME=<new name>' into /etc/conf.d/xenstored and you'll be able to see the change when the xenstored service is next restarted ( "xl top" will show the new name, for example )

kantras commented on 2013-06-05 15:25

The pod2man "fix" was added to the texi2html.patch file; pod2man is returning an error code when parsing qemu.pod, due to using non-ascii characters when no '=encoding' parameter has been set. The file would still be created, which is why rebuilding the package a second time would work (since it would skip running pod2man as the file already existed)

Two ways to fix, either a) add in "=encoding utf8' at the top of the qemu.pod file before you run it through pod2man or b) add the option '--errors=none' into the command line calling pod2man. I opted for the second as it was easier.

tritron commented on 2013-06-05 14:57

That is nice way of moving stuff into /usr/bin
I wonder how did you fix pod2man error ?

kantras commented on 2013-06-05 05:59

Ok, I've just uploaded a tarball to http://www.kantras.info/xen/xen-4.2.2-2.tgz - this has all the binaries moved from /usr/sbin to /usr/bin and also fixes the pod2man error. There is also a patch I'm testing in there, for working around a broken BIOS implementation, but its commented out by default.

zootboy commented on 2013-06-04 18:20

Whoops, jumped the gun on that one. Forgot sbin was being merged, too. There seems to be an sbindir variable hiding out in tools/configure. Can anyone figure out how to correctly set that in the PKGBUILD?

kantras commented on 2013-06-04 16:44

Actually it does. Its making use of the /usr/sbin directory, which is being merged into /usr/bin

zootboy commented on 2013-06-04 15:35

pacman -Ql xen | grep /bin

says no.

hugleo commented on 2013-06-04 14:25

Does the last Arch Linux notification https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/ about merges all binaries into a unified /usr/bin directory needs to apply on this xen package?

Anonymous comment on 2013-06-03 17:06

I needed to install mesa-libgl in order to create an HVM domU and I think it should probably be listed as a dependency. Potentially nvidia-libgl would also work but I haven't tried it.

tritron commented on 2013-05-30 00:50

I had spoken too soon it compiled once. It is two step process the first time i get the error i posted second time it compiles fine

tritron commented on 2013-05-30 00:19

It is fixed i don't know how xen 4.2.2 was fixed but xen 4.3 unstable was not

hugleo commented on 2013-05-29 20:40

Here is building totally normal. No need edit anything. Have it already fixed? Or this error is caused on only some systems...

I've founded the files:

grep -ilr 'Schütz.' ./* 2>/dev/null
./yaourt-tmp-ths/aur-xen/src/xen-4.2.2/tools/qemu-xen-traditional/Changelog
./yaourt-tmp-ths/aur-xen/src/xen-4.2.2/tools/qemu-xen-traditional/qemu-doc.texi
./yaourt-tmp-ths/aur-xen/src/xen-4.2.2/tools/qemu-xen/Changelog
./yaourt-tmp-ths/aur-xen/src/xen-4.2.2/tools/qemu-xen/qemu-doc.texi


While is compiling you can try edit the files qemu-xen-traditional/qemu-doc.texi and qemu-xen/qemu-doc.texi

3000 commented on 2013-05-29 19:23

that's great info, thanks!
where is qemu.pod?

hugleo commented on 2013-05-28 23:54

To solve temporally I think you can edit the qemu.pod file and change the name Schütz to Schutz.

tritron commented on 2013-05-28 23:32

Well looks like the latest upgrades perl 5.18 breaks xen I get this error.
pod2man --section=1 --center=" " --release=" " qemu.pod > qemu.1
qemu.pod around line 91: Non-ASCII character seen before =encoding in 'Schütz.'. Assuming UTF-8
POD document had syntax errors at /usr/bin/core_perl/pod2man line 71

kantras commented on 2013-05-28 18:27

Sorry, I've been offline a few days - once I get a chance, I'll retest on my lab machine.

3000 commented on 2013-05-28 17:36

@ Kantras:

is your solution still working for you?

thanks

3000 commented on 2013-05-25 13:56

I also tried xen-git, also not working (yet). Thanks also for the xen-users mailing list idea. I will post my Problem over there shortly.

I have to correct myself though regarding my last post: I said I was able to install xen only in legacy boot. Well to be more precise, I was able to boot INTO xen with legacy boot.

With UEFI boot, I was still able to successfully install xen, BUT once I tried to boot into Arch Xen, the system would constantly just reboot. That's my real Problem. And once I tried to apply Kantras solution (modifying binutils-multilib before installing xen), installation broke down. I know it's not arch related, I still thought it's worth mentioning. There is a decisive difference to my last post.

tritron commented on 2013-05-25 00:23

3000 try xen-git package users had been able to compile xen.efi and it is working

zootboy commented on 2013-05-24 23:20

@3000 I would suggest posting your problem in the xen-users mailing list. You're much more likely to get help there, as this isn't an Archlinux-specific problem. Just make sure to mention the fact that you're using Arch.

3000 commented on 2013-05-24 22:31

I am really sorry, I totally forgot to mention that I CAN actually build xen - but only with legacy boot. However it won't build with UEFI boot. I already tried the solution posted below by Kantras. He used a modified binutils-multilib. He posted his solution in late 2012. So I am not sure it's still relevant. I tried, but it doesn't work for me.

hugleo commented on 2013-05-23 21:35

Here I've compiled perfectly using yaourt.

You can try re generate the locales:

cat /etc/locale.conf
LANG="en_US.UTF8"

locale-gen
Generating locales...
en_US.UTF-8... done
en_US.ISO-8859-1... done

You can also try on a fresh arch "systemd" installation.

uname -a (64 bits)
Linux archlocal 3.9.3-1-ARCH #1 SMP PREEMPT Sun May 19 22:50:29 CEST 2013 x86_64 GNU/Linux

zootboy commented on 2013-05-23 21:31

@3000 That's the line. And no, unfortunately, I don't have any UEFI motherboards to test on. Though I find it strange that UEFI would make the difference on that line in particular, I won't rule it out as a possibility. You should definitely try removing that line, as trying can't hurt at this point.

Also, there's been some chat on the xen-users mailing list about UEFI stuff recently. Are you trying to compile on a 32-bit kernel?

3000 commented on 2013-05-23 21:03

I tried installing it with packer - but I get the same error message

3000 commented on 2013-05-23 21:01

I tried installing it with packer - but I get the same error message

3000 commented on 2013-05-23 20:59

I tried installing it with packer - but I get the same error message

3000 commented on 2013-05-23 18:59

I can't find that line, I just had a look in the "View PKGBUILD" from this page. I can only find this one: "mv etc/{init,rc}.d" Is that the one?

@zootboy: are you also having a uefi boot?

I will try to download packer and install it with that command of yours.

3000 commented on 2013-05-23 18:59

I can't find that line, I just had a look in the "View PKGBUILD" from this page. I can only find this one: "mv etc/{init,rc}.d" Is that the one?

@zootboy: are you also having a uefi boot?

I will try to download packer and install it with that command of yours.

3000 commented on 2013-05-23 18:57

I can't find that line, only this one: "mv etc/{init,rc}.d"

@zootboy: are you also having a uefi boot?

I will try to download packer and install it with that command of yours.

3000 commented on 2013-05-23 18:53

I can't find that line, only this one: "mv etc/{init,rc}.d"

@zootboy: are you also having a uefi boot?

I will try to download packer and install it with that command of yours.

3000 commented on 2013-05-23 18:38

thanks for the responses. I won't use root again for building packages, thanks!

I had already installed base-devel.

And in my Xen PKGBUILD there is no line that starts with mv /etc/init.d

so I don't know what to do now ...

zootboy commented on 2013-05-23 18:00

The line is there, but you should probably just clean out your package and re-download it fresh from the AUR. As it stands now, packer can build xen on my machine with no modifications to the PKGBUILD (packer -S xen)

3000 commented on 2013-05-23 17:53

thanks for the responses. I won't use root again for building packages, thanks!

I had already installed base-devel.

And in my Xen PKGBUILD there is no line that starts with mv /etc/init.d

so I don't know what to do now ...

zootboy commented on 2013-05-23 13:22

This PKGBUILD works as-is for me, so I don't think it's that. @3000, make sure you have the entire base-devel group installed ("pacman -S base-devel") because if you were missing patch, you may be missing other important tools. Also, why are you using the --asroot flag? You should not be building packages as root. Use an unprivileged user to make the package, then use root to install the package.

tritron commented on 2013-05-23 13:15

Edit PKGBUILD and remove offending line that starts with MV /etc/init.d/

3000 commented on 2013-05-23 10:51

i am having the same error message as SeraphZA
any help is hugely appreciated, for me this is the last hurdle to finally build my System for good. this is the Output of the error:

make[2]: Leaving directory `/root/xen/src/xen-4.2.2/extras/mini-os'
install -d -m0755 -p "/root/xen/pkg/xen/usr/lib/xen/boot"
install -m0644 -p mini-os-x86_32-grub/mini-os.gz "/root/xen/pkg/xen/usr/lib/xen/boot/pv-grub-x86_32.gz"
make[1]: Leaving directory `/root/xen/src/xen-4.2.2/stubdom'
mv: cannot stat âetc/init.dâ: No such file or directory
==> ERROR: A failure occurred in package().
Aborting...

3000 commented on 2013-05-20 17:51

thanks for the fast response! That was it, I was just executing "makepkg --asroot"

it's installing right now :)

tritron commented on 2013-05-20 17:40

From your error message looks like you are missing patch so you want to install it did you run makepkg -s ?

3000 commented on 2013-05-20 17:34

so I have downloaded latest tarball and tried to install it, but it's not building. I must stress, I have been able to use uefi boot, so I don't know, if that's hindering the Installation, anyways I got this error:

...
xen.conf ... Passed
==> Extracting sources...
-> Extracting xen-4.2.2.tar.gz with bsdtar
==> Starting prepare()...
/root/xen/PKGBUILD: line 38: patch: command not found
==> ERROR: A failure occurred in prepare().
Aborting...

Anonymous comment on 2013-05-17 10:38

I have an EFI motherboard and am running Arch 2013_05 x86_64. I am trying to build xen.efi and I have applied the Python workaround and rebuilt binutils-multilib with --enable-targets=X86_64-pep.

The output of ld -V is:
GNU ld (GNU Binutils) 2.23.2
Supported emulations:
elf_x86_64
elf32_x86_64
elf_i386
i386linux
elf_l1om
elf_k1om
i386pep
i386pe

However when I build xen i get:
mv: cannot stat âetc/init.dâ: No such file or directory
==> ERROR: A failure occurred in package().
Aborting...

Build logs here:

https://dl.dropboxusercontent.com/u/66245999/xen-4.2.2-1-x86_64-prepare.log

https://dl.dropboxusercontent.com/u/66245999/xen-4.2.2-1-x86_64-build.log

https://dl.dropboxusercontent.com/u/66245999/xen-4.2.2-1-x86_64-package.log

Can someone please assist?

zootboy commented on 2013-05-12 20:02

Can it be an optional dependency? I'd really rather not have bluetooth stuff installed on my server, and it would get much more annoying to strip out if it became a rolled-in dep in a community package.

kantras commented on 2013-05-12 18:37

A quick grep over the source tree shows that the qemu pieces have config options for bluez

zootboy commented on 2013-05-12 17:50

Is there a reason why bluez is a dependency? I don't use it at all, and I have yet to see any issues with my install where I removed it.

tritron commented on 2013-05-12 17:06

It sounds like great idea why not wait for 4.3 to be final

kantras commented on 2013-05-12 17:04

@gtmanfred - No objection from me

gtmanfred commented on 2013-05-12 07:07

also, python 2.7.5 was just tagged, it should fix the pyargs parsetuple bug

gtmanfred commented on 2013-05-12 06:40

I would like to move this into community along with xe-guest-utilities, any objections?

Thanks

kantras commented on 2013-04-30 05:25

Ok, installed and is working. One thing of note for anyone using VT-d and AMD processors - There has been some work done on the IOMMU code, due to security issues. This means that the code is much less forgiving if you have a BIOS with bugs and/or bad entries. There are some flags that you can add to the grub line, which may help re-enable VT-d support, but not in all cases (The BIOS in my test machine is missing IOAPIC entries from the IVRS table, and the grub config options won't work for that type of issue. I've opened a support request with the vendor but i've not had much success in the past with support tickets)

kantras commented on 2013-04-29 08:03

I noticed that v4.2.2 has been released. I've just done a quick compile test (Updated the version numbers, commented out the 'gcc-4.8-typedefs.patch' patch as is appears not to be needed, then recreated the hashes) and made sure that the existing PKGBUILD was able to build the new 4.2.2 package. It built without issue and will be installing it on my test server tomorrow to make sure its working correctly.

gtmanfred commented on 2013-04-29 02:59

instead of commenting it out (if you really want to do it) you can rebuild python2 with this patch for configure http://ix.io/5oM which should be applied to the configure.ac stuff for the next release of python.

http://bugs.python.org/issue17547

3000 commented on 2013-04-27 11:56

thanks a lot for the instructions! And thanks a lot for the new build.
It builds without any problem :-)

shanmu commented on 2013-04-27 09:50

Thanks for the patch, tycho! Released a new version with the patch.

If the build fails with the error:

/usr/include/python2.7/modsupport.h:27:1: error: 'PyArg_ParseTuple' is an unrecognized format function type [-Werror=format=]
PyAPI_FUNC(int) PyArg_ParseTuple(PyObject *, const char *, ...) Py_FORMAT_PARSETUPLE(PyArg_ParseTuple, 2, 3);
^
cc1: all warnings being treated as errors
error: command 'gcc' failed with exit status 1
make[3]: *** [build] Error 1

The workaround is to comment line#72 in /usr/include/python2.7/pyconfig.h

//#define HAVE_ATTRIBUTE_FORMAT_PARSETUPLE 1

I need to log a new bug against the python package to get it fixed.

zootboy commented on 2013-04-26 13:39

@3000
Add the patch file to the package directory, then add it to the sources list in the package. Delete the sums array in the PKGBUILD, optionally rebuilding it with "makepkg -G >> PKGBUILD". Duplicate any of the patch lines in the build function and change the file name to the new patch. Build.

fatmike commented on 2013-04-26 13:03

After applying the patch, the build fails with:

running build_ext
building 'xc' extension
creating build/temp.linux-x86_64-2.7
creating build/temp.linux-x86_64-2.7/xen
creating build/temp.linux-x86_64-2.7/xen/lowlevel
creating build/temp.linux-x86_64-2.7/xen/lowlevel/xc
gcc -DNDEBUG -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -Wno-sizeof-pointer-memaccess -Wformat -D__XEN_TOOLS__ -MMD -MF .build.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fPIC -I../../tools/include -I../../tools/libxc -Ixen/lowlevel/xc -I/usr/include/python2.7 -c xen/lowlevel/xc/xc.c -o build/temp.linux-x86_64-2.7/xen/lowlevel/xc/xc.o -fno-strict-aliasing -Werror
In file included from /usr/include/python2.7/Python.h:126:0,
from xen/lowlevel/xc/xc.c:7:
/usr/include/python2.7/modsupport.h:27:1: error: 'PyArg_ParseTuple' is an unrecognized format function type [-Werror=format=]
PyAPI_FUNC(int) PyArg_ParseTuple(PyObject *, const char *, ...) Py_FORMAT_PARSETUPLE(PyArg_ParseTuple, 2, 3);
^
cc1: all warnings being treated as errors
error: command 'gcc' failed with exit status 1
make[3]: *** [build] Error 1


Any suggestions?

3000 commented on 2013-04-26 08:52

Can you explain how to use the patch? I need to compile this again. Thanks a lot!

3000 commented on 2013-04-26 08:46

Can you explain how to use the patch? I need to compile this again. Thanks a lot!

tycho commented on 2013-04-25 14:23

I've added this patch locally to fix that issue.:

--- a/tools/qemu-xen/Makefile.target 2013-04-05 23:39:54.000000000 +0000
+++ b/tools/qemu-xen/Makefile.target 2013-04-25 13:54:59.360000000 +0000
@@ -206,6 +206,7 @@
obj-$(CONFIG_NO_KVM) += kvm-stub.o
obj-y += memory.o
LIBS+=-lz
+LIBS+=-lrt

QEMU_CFLAGS += $(VNC_TLS_CFLAGS)
QEMU_CFLAGS += $(VNC_SASL_CFLAGS)

fatmike commented on 2013-04-25 10:24

Same for me here. Any solution?

Anonymous comment on 2013-04-24 06:06

Hello everyone, I install ArchLinux today, and xen from this package. I got the following error, I know someone posted before, am I missing something? thanks.

LINK i386-softmmu/qemu-system-i386
../slirp/misc.o: In function `memset':
/usr/include/bits/string3.h:81: warning: memset used with constant zero length parameter; this could be due to transposed parameters
/usr/bin/ld: ../qemu-timer.o: undefined reference to symbol 'timer_settime@@GLIBC_2.3.3'
/usr/bin/ld: note: 'timer_settime@@GLIBC_2.3.3' is defined in DSO /usr/lib/librt.so.1 so try adding it to the linker command line
/usr/lib/librt.so.1: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[4]: *** [qemu-system-i386] Error 1
make[3]: *** [subdir-i386-softmmu] Error 2
make[3]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools/qemu-xen-dir'
make[2]: *** [subdir-all-qemu-xen-dir] Error 2
make[2]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools'
make: *** [install-tools] Error 2

zootboy commented on 2013-04-24 01:52

I believe python2 should be added as a dependency.

3000 commented on 2013-04-14 13:23

exactly, I can confirm, working quite nicely.

Thanks a lot. You guys rock. :)

Anonymous comment on 2013-04-14 09:05

Dear shanmu,
now everything is fine.
Thanks for your work!

shanmu commented on 2013-04-13 19:21

Hi jamm, as posted earlier, The error is because of Arch bug FS#34658.

The Workaround till it is fixed is to comment line#72 in /usr/include/python2.7/pyconfig.h

//#define HAVE_ATTRIBUTE_FORMAT_PARSETUPLE 1

Anonymous comment on 2013-04-13 14:20

Hi shanmu,

make[3]: Entering directory `/home/jamm/build/xen-4.2.1-5/src/xen-4.2.1/tools/python'
rm -f "xen/util/path.py".tmp; echo "SBINDIR=\"/usr/sbin\"" >>"xen/util/path.py".tmp; echo "BINDIR=\"/usr/bin\"" >>"xen/util/path.py".tmp; echo "LIBEXEC=\"/usr/lib/xen/bin\"" >>"xen/util/path.py".tmp; echo "LIBDIR=\"/usr/lib\"" >>"xen/util/path.py".tmp; echo "SHAREDIR=\"/usr/share\"" >>"xen/util/path.py".tmp; echo "PRIVATE_BINDIR=\"/usr/lib/xen/bin\"" >>"xen/util/path.py".tmp; echo "XENFIRMWAREDIR=\"/usr/lib/xen/boot\"" >>"xen/util/path.py".tmp; echo "XEN_CONFIG_DIR=\"/etc/xen\"" >>"xen/util/path.py".tmp; echo "XEN_SCRIPT_DIR=\"/etc/xen/scripts\"" >>"xen/util/path.py".tmp; echo "XEN_LOCK_DIR=\"/var/lock\"" >>"xen/util/path.py".tmp; echo "XEN_RUN_DIR=\"/var/run/xen\"" >>"xen/util/path.py".tmp; echo "XEN_PAGING_DIR=\"/var/lib/xen/xenpaging\"" >>"xen/util/path.py".tmp; if ! cmp -s "xen/util/path.py".tmp "xen/util/path.py"; then mv -f "xen/util/path.py".tmp "xen/util/path.py"; else rm -f "xen/util/path.py".tmp; fi
PYTHONPATH=/home/jamm/build/xen-4.2.1-5/src/xen-4.2.1/tools/python/../../tools/libxl python2 genwrap.py \
/home/jamm/build/xen-4.2.1-5/src/xen-4.2.1/tools/python/../../tools/libxl/libxl_types.idl \
xen/lowlevel/xl/_pyxl_types.h \
xen/lowlevel/xl/_pyxl_types.c
Parsing /home/jamm/build/xen-4.2.1-5/src/xen-4.2.1/tools/python/../../tools/libxl/libxl_types.idl
CC="gcc" CFLAGS="-O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -Wno-sizeof-pointer-memaccess -Wformat -D__XEN_TOOLS__ -MMD -MF .build.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls " python2 setup.py build
running build
running build_py
running build_ext
building 'xc' extension
gcc -DNDEBUG -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -Wno-sizeof-pointer-memaccess -Wformat -D__XEN_TOOLS__ -MMD -MF .build.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fPIC -I../../tools/include -I../../tools/libxc -Ixen/lowlevel/xc -I/usr/include/python2.7 -c xen/lowlevel/xc/xc.c -o build/temp.linux-x86_64-2.7/xen/lowlevel/xc/xc.o -fno-strict-aliasing -Werror
In file included from /usr/include/python2.7/Python.h:126:0,
from xen/lowlevel/xc/xc.c:7:
/usr/include/python2.7/modsupport.h:27:1: error: 'PyArg_ParseTuple' is an unrecognized format function type [-Werror=format=]
PyAPI_FUNC(int) PyArg_ParseTuple(PyObject *, const char *, ...) Py_FORMAT_PARSETUPLE(PyArg_ParseTuple, 2, 3);
^
cc1: all warnings being treated as errors
error: command 'gcc' failed with exit status 1
make[3]: *** [build] Error 1


There are packages installed in the system:

kbproto-1.0.6-1 libtasn1-3.2-1 libx11-1.5.0-2 libxau-1.0.7-1 libxcb-1.9-3 libxdmcp-1.1.1-1 libxext-1.3.1-1 libxrender-0.9.7-1 nettle-2.6-1 ocaml-4.00.1-3 p11-kit-0.13-1
perl-error-0.17019-1 python2-2.7.4-1 renderproto-0.11.1-2 sqlite-3.7.16.2-1 xcb-proto-1.8-1 xextproto-7.2.1-1 xproto-7.0.24-1 bin86-0.16.19-1 bluez-4.101-1 dev86-0.16.19-1 git-1.8.2.1-1
gnutls-3.1.10-1 iasl-20130328-1 lib32-glibc-2.17-5 libaio-0.3.109-6 libjpeg-turbo-1.2.1-1 libpng-1.5.15-1 markdown-1.0.1-5 ocaml-findlib-1.3.3-2 sdl-1.2.15-3 vde2-2.3.2-2 yajl-2.0.4-1
fontconfig-2.10.2-1 libxft-2.3.1-1 libxss-1.2.2-1 scrnsaverproto-1.2.2-1 tcl-8.6.0-3 tk-8.6.0-1

What I can do for solve issue?

virtuemood commented on 2013-04-13 13:52

Thanks for update !!

Sydney6 commented on 2013-04-12 23:23

Hi shanmu,

1. Man, you're quick.
2. Please don't apologize. It is (obviously) my bad. Don't know where yet (probably cached pyconfig.h), but my bad. PKG off course BUILDS CORRECTLY.
3. Sorry for getting your name wrong, shanmu.
4. Thanks. Again.

shanmu commented on 2013-04-12 23:10

Sydney6, Apologies! they were not completely right so took them out. Can you please try a new install again (I have updated the gcc-4.8 patch) + the python pyconfig.h workaround, it should build fine.

Sydney6 commented on 2013-04-12 23:00

Hi shanmuha,

tried your suggestions to patch pkgbuild (which have suddely disappeared), build with gcc 4.8 failed with:

In file included from /root/xen/src/xen-4.2.1/tools/qemu-xen/fpu/softfloat.c:60:0:
/root/xen/src/xen-4.2.1/tools/qemu-xen/fpu/softfloat-specialize.h:92:1: error: initializer element is not constant
const floatx80 floatx80_default_nan = make_floatx80(floatx80_default_nan_high,
^
/root/xen/src/xen-4.2.1/tools/qemu-xen/fpu/softfloat-specialize.h:107:1: error: initializer element is not constant
const float128 float128_default_nan = make_float128(float128_default_nan_high,
^
make[4]: *** [fpu/softfloat.o] Error 1
make[3]: *** [subdir-i386-softmmu] Error 2
make[3]: Leaving directory `/root/xen/src/xen-4.2.1/tools/qemu-xen-dir'
make[2]: *** [subdir-all-qemu-xen-dir] Error 2
make[2]: Leaving directory `/root/xen/src/xen-4.2.1/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/root/xen/src/xen-4.2.1/tools'
make: *** [install-tools] Error 2


Now tried your suggestion for the python bindings and the build failed with:

In file included from /root/xen/src/xen-4.2.1/xen/include/public/xen.h:33:0,
from /root/xen/src/xen-4.2.1/xen/include/xen/time.h:12,
from /root/xen/src/xen-4.2.1/xen/include/xen/hypercall.h:9,
from memory.c:3:
memory.c: In function 'compat_memory_op':
/root/xen/src/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33: error: typedef '__guest_handle_const_compat_memory_exchange_t' locally defined but not used [-Werror=unused-local-typedefs]
typedef struct { type *p; } __guest_handle_ ## name
^
/root/xen/src/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5: note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE'
___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
^
/root/xen/src/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41: note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE'
#define DEFINE_XEN_GUEST_HANDLE(name) __DEFINE_XEN_GUEST_HANDLE(name, name)
^
memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE'
DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
^
cc1: all warnings being treated as errors
make[5]: *** [memory.o] Error 1
make[5]: Leaving directory `/root/xen/src/xen-4.2.1/xen/common/compat'
make[4]: *** [compat/built_in.o] Error 2
make[4]: Leaving directory `/root/xen/src/xen-4.2.1/xen/common'
make[3]: *** [/root/xen/src/xen-4.2.1/xen/common/built_in.o] Error 2
make[3]: Leaving directory `/root/xen/src/xen-4.2.1/xen/arch/x86'
make[2]: *** [/root/xen/src/xen-4.2.1/xen/xen] Error 2
make[2]: Leaving directory `/root/xen/src/xen-4.2.1/xen'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/root/xen/src/xen-4.2.1/xen'
make: *** [install-xen] Error 2

Any more suggestions,
Cheers,
S.

shanmu commented on 2013-04-12 22:50

The latest version compiles with gcc4.8.

Arch bug FS#34658 needs to be fixed for building python bindings, workaround till then is to comment line#72 in /usr/include/python2.7/pyconfig.h
//#define HAVE_ATTRIBUTE_FORMAT_PARSETUPLE 1

luolimao commented on 2013-04-12 22:23

Fixed, thanks

shanmu commented on 2013-04-12 21:52

Modifying PKGBUILD as follows helped build with gcc4.8:
@@ -70,6 +70,7 @@
}

build() {
+ export CFLAGS+='-Wall -Wstrict-prototypes -Wno-unused-local-typedefs -Wno-sizeof-pointer-memaccess'
cd $pkgname-$pkgver/
./autogen.sh
./configure PYTHON=/usr/bin/python2
@@ -78,7 +79,7 @@
package() {
cd $pkgname-$pkgver/

- export CFLAGS+='-Wall -Wstrict-prototypes -Wno-unused-local-typedefs'
+ export CFLAGS+='-Wall -Wstrict-prototypes -Wno-unused-local-typedefs -Wno-sizeof-pointer-memaccess'
make DESTDIR="$pkgdir" LANG=C PYTHON=python2 install-{xen,tools,stubdom}

cd ../

luolimao commented on 2013-04-12 21:40

@3000 @evanlec Added @tritron's patch and a prepare() function. Build still fails, though. This is actually a bit too much of a monolith for me to handle atm. Orphaning.

luolimao commented on 2013-04-12 21:39

@3000 @evanlec Added @tritron's patch. Build still fails, though. This is actually a bit too much of a monolith for me to handle atm. Orphaning.

3000 commented on 2013-04-12 11:16

Thanks for the help. I am not an expert. Therefore I don't know how to edit the necessary files. Do you have some instructions please?

tritron commented on 2013-04-08 18:28

Well git version of 4.2 has this fix 4.8 gcc that was pushed to arch. I don't know guys if that is the issue.
Removing -Werror in Makefiles would solve the problem also.
I hope this helps I have no issues compiling unstable xen.
--- a/Config.mk Tue Feb 19 15:25:18 2013 +0000
+++ b/Config.mk Fri Feb 22 13:41:09 2013 +0100
@@ -166,6 +166,7 @@ CFLAGS-$(clang) += -Wno-parentheses -Wno
$(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
$(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
$(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
+$(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)

LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
CFLAGS += $(foreach i, $(EXTRA_INCLUDES), -I$(i))

evanlec commented on 2013-04-08 11:06

Yep I'm getting the same error as 3000


/home/el/aur/xen/src/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33: error: typedef ‘__guest_handle_const_compat_memory_exchange_t’ locally defined but not used [-Werror=unused-local-typedefs]
typedef struct { type *p; } __guest_handle_ ## name
^
/home/el/aur/xen/src/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5: note: in expansion of macro ‘___DEFINE_XEN_GUEST_HANDLE’
___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
^
/home/el/aur/xen/src/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41: note: in expansion of macro ‘__DEFINE_XEN_GUEST_HANDLE’
#define DEFINE_XEN_GUEST_HANDLE(name) __DEFINE_XEN_GUEST_HANDLE(name, name)
^
memory.c:261:13: note: in expansion of macro ‘DEFINE_XEN_GUEST_HANDLE’
DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t);
^
cc1: all warnings being treated as errors
make[5]: *** [memory.o] Error 1
make[5]: Leaving directory `/home/el/aur/xen/src/xen-4.2.1/xen/common/compat'
make[4]: *** [compat/built_in.o] Error 2
make[4]: Leaving directory `/home/el/aur/xen/src/xen-4.2.1/xen/common'
make[3]: *** [/home/el/aur/xen/src/xen-4.2.1/xen/common/built_in.o] Error 2
make[3]: Leaving directory `/home/el/aur/xen/src/xen-4.2.1/xen/arch/x86'
make[2]: *** [/home/el/aur/xen/src/xen-4.2.1/xen/xen] Error 2
make[2]: Leaving directory `/home/el/aur/xen/src/xen-4.2.1/xen'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/el/aur/xen/src/xen-4.2.1/xen'
make: *** [install-xen] Error 2
==> ERROR: A failure occurred in package().
Aborting...

3000 commented on 2013-04-07 10:35

Hi, I can't compile. I get this error message:

cc1: all warnings being treated as errors
make[5]: *** [memory.o] Error 1
make[5]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen/common/compat'
make[4]: *** [compat/built_in.o] Error 2
make[4]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen/common'
make[3]: *** [/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen/common/built_in.o] Error 2
make[3]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen/arch/x86'
make[2]: *** [/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen/xen] Error 2
make[2]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen'
make: *** [install-xen] Error 2


Do I miss something or is there a mistake in PKGBUILD?

Thanks, 3000

tritron commented on 2013-03-03 20:48

DId anyone had compiled this package with spice and spice-protocol?

thunderforce commented on 2013-03-01 18:16

@luolimao
many thanks!
I was able to install the new package version
now, on to setting up Xorg

luolimao commented on 2013-03-01 05:47

I'll check out the patch that @Anty posted earlier and see if that actually fixes it, but I'm just disabling the qemu docs in the meantime.

luolimao commented on 2013-03-01 05:45

Qemu-doc generation is disabled.

luolimao commented on 2013-03-01 05:34

@tritron thanks for the tip
@thunderforce I'm adding it to the PKGBUILD and I'll upload as soon as I test it out.

thunderforce commented on 2013-03-01 00:34

@triton
sorry for the dummy question, but how exactly do I add "--disable-docs" to the Makefile. When I edit it, it keeps getting overwritten.

tritron commented on 2013-02-26 05:16

Couple does this package creates /etc/xen/conf/%i.cfg ? My config files are in /etc/xen I don't see config anywere.
I also have strange error with 4.3
libxl: error: libxl_dom.c:612:libxl__build_hvm: hvm building failed
libxl: error: libxl_create.c:885:domcreate_rebuild_done: cannot (re-)build domai n: -3
libxl: error: libxl_dm.c:1238:libxl__destroy_device_model: could not find device -model's pid for dom 7
libxl: error: libxl.c:1414:libxl__destroy_domid: libxl__destroy_device_model fai led for 7
I get this does anyone knows what is causing it ?

Anty commented on 2013-02-25 19:39

@tritron

Hi,

Thanks, disable qemu-doc works perflectly.

Regards,
anty

tritron commented on 2013-02-25 14:49

Couple does this package creates /etc/xen/conf/%i.cfg ? My config files are in /etc/xen I don't see config anywere.
I also have strange error with 4.3
libxl: error: libxl_dom.c:612:libxl__build_hvm: hvm building failed
libxl: error: libxl_create.c:885:domcreate_rebuild_done: cannot (re-)build domai n: -3
libxl: error: libxl_dm.c:1238:libxl__destroy_device_model: could not find device -model's pid for dom 7
libxl: error: libxl.c:1414:libxl__destroy_domid: libxl__destroy_device_model fai led for 7
I get this does anyone knows what is causing it ?

tritron commented on 2013-02-25 14:45

The easiest way to work around this issue is to disable docs creation under Makefile in tools
So if we add this we can work around the issue.
--datadir=$(SHAREDIR)/qemu-xen \
--disable-kvm \
+ --disable-docs \

Anty commented on 2013-02-24 02:27

hi,

when compiling an error occurs :

./qemu-options.texi:1294: unknown command `list'
./qemu-options.texi:1294: table requires an argument: the formatter for @item
./qemu-options.texi:1294: warning: @table has text but no @item
make[3]: *** [qemu-doc.html] Error 1

I think this patch should solve the problem, but i'm not trying.

http://patchwork.ozlabs.org/patch/222131/

Thanks.

luolimao commented on 2013-02-17 06:45

That's not xen's fault; that's the fault of whatever package put those files there. However, if you were installing xen and iasl at the same time, then this error would appear, even though it has to do with iasl, not xen. Can you post the output of
yaourt -Qo /usr/bin/iasl
?

Anonymous comment on 2013-02-15 17:57

hi,

xen failure report,

(10/10) checking package integrity [##########################] 100%
(10/10) loading package files [##########################] 100%
(10/10) checking for file conflicts [##########################] 100%
error: failed to commit transaction (conflicting files)
iasl: /usr/bin/acpibin exists in filesystem
iasl: /usr/bin/acpiexec exists in filesystem
iasl: /usr/bin/acpihelp exists in filesystem
iasl: /usr/bin/acpinames exists in filesystem
iasl: /usr/bin/acpisrc exists in filesystem
iasl: /usr/bin/acpixtract exists in filesystem
iasl: /usr/bin/iasl exists in filesystem
Errors occurred, no packages were upgraded.
Installation failed.

luolimao commented on 2013-02-09 18:06

Updated.

revellion commented on 2013-02-04 09:15

@deviousway,

After googling around and sourcing some info from gentoo's bug i've managed to find the problem or atleast a workaround/solution to compiling Xen.

Just like you i have a non-english system locale. sv_SE.UTF-8 to be exact.

but by doing LANG=C makepkg

I'm able to compile it successfully. Maybe the maintainer of this PKGBUILD should add LANG=C to the package() part that initiates the build to avoid this problem.

The big problem however seems to reside in python2 which pukes on non-english locales. But python2 afaik is not maintained anymore with python3 being the replacement, so might be hard to get it fixed.

fernando_ccs17 commented on 2013-01-25 20:28

Me too. I need manually create the folder

luolimao commented on 2013-01-12 22:58

I thought the var-lib-xenstored.mount was supposed to fix this issue...? Or does this issue still occur for anyone else?

zootboy commented on 2013-01-12 22:00

It seems that, at least on my system, the package does not create the /var/lib/xen folder. This causes some nasty errors (a la https://bugs.launchpad.net/ubuntu/+source/xen/+bug/949974). Simply creating the empty directory fixes the issue, though.

sudo mkdir /var/lib/xen

luolimao commented on 2013-01-11 11:52

Sorry, forgot to post the new patch. Anyway, fixed.

kantras commented on 2013-01-11 07:26

Download the tarball (or use yaourt to download the files then press Ctrl-C to break out of it - the files will be under something like /tmp/yaourt-tmp-<username>/aur-xen/) If you download the tarball, extract the files into a directory.

Go into the directory and download the two files I mentioned into the directory, overwriting the old PKGBUILD file. You can then run "makepkg -i" to build and install

Anonymous comment on 2013-01-11 06:35

Can you suggest how to put your patch please. I use "yaourt"

Anonymous comment on 2013-01-11 06:26

i7-3770
8gb RAM
64bit OS

Linux localhost 3.6.11-1-ARCH #1 SMP PREEMPT Tue Dec 18 08:57:15 CET 2012 x86_64 GNU/Linux

kantras commented on 2013-01-11 05:54

Ahh, ok - when I built it last time, glibc hadn't been upgraded to 2.17, which is why I didn't see this issue at first when I build that PKGBUILD; glibc 2.17 makes some key changes to things such as not implicitly loading the rt lib (hence why you have to load it explicitly.) It built fine once I also included the patch mentioned by nbhs below (also at http://lists.xen.org/archives/html/xen-devel/2012-12/msg00429.html )

I uploaded the gdbsx-glibc-2.17.patch and PKGBUILD files I used to http://www.kantras.info/xen/

kantras commented on 2013-01-11 04:51

Hmm, its been building fine for me, even before the last added patch. Are you using 32 bit or 64 bit? What type of CPU? Any custom flags set? How much memory? I might be able to help if I can reproduce the issue on one of my test machines.

Anonymous comment on 2013-01-11 03:52

Xen 4.1 compiled fine, 4.2 does not work. It would be better returned to the repository version 4.1 :-(

fernando_ccs17 commented on 2013-01-10 17:41

gcc -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -D__XEN_TOOLS__ -MMD -MF .xg_main.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -Werror -Wmissing-prototypes -I/home/fernando/Desktop/xen/src/xen-4.2.1/tools/debugger/gdbsx/xg/../../../../tools/include -c -o xg_main.o xg_main.c
xg_main.c: In function ‘_domctl_hcall’:
xg_main.c:181:52: error: ‘ulong’ undeclared (first use in this function)
xg_main.c:181:52: note: each undeclared identifier is reported only once for each function it appears in
xg_main.c: In function ‘_check_hyp’:
xg_main.c:221:52: error: ‘ulong’ undeclared (first use in this function)
make[4]: ** [xg_main.o] Erro 1
make[4]: Saindo do diretório `/home/fernando/Desktop/xen/src/xen-4.2.1/tools/debugger/gdbsx/xg'
make[3]: ** [all] Erro 2
make[3]: Saindo do diretório `/home/fernando/Desktop/xen/src/xen-4.2.1/tools/debugger/gdbsx'
make[2]: ** [subdir-install-debugger/gdbsx] Erro 2
make[2]: Saindo do diretório `/home/fernando/Desktop/xen/src/xen-4.2.1/tools'
make[1]: ** [subdirs-install] Erro 2
make[1]: Saindo do diretório `/home/fernando/Desktop/xen/src/xen-4.2.1/tools'
make: ** [install-tools] Erro 2

Anonymous comment on 2013-01-10 02:01

--- a/tools/debugger/gdbsx/xg/xg_main.c
+++ b/tools/debugger/gdbsx/xg/xg_main.c
@@ -34,6 +34,7 @@
* XGTRC(): generic trace utility
*/

+#include <sys/types.h>
#include <stdio.h>
#include <stddef.h>
#include <stdarg.h>

luolimao commented on 2013-01-10 00:23

There's a new error [1] now, but I added the patch at least.
[1] https://gist.github.com/4498279

Anonymous comment on 2013-01-09 18:06

this patch works for me https://github.com/slacks42/alpine-apk/blob/master/xen-git/timer-add-lrt-lm.patch

mkzero commented on 2013-01-08 13:30

I've tried every combination I could think of, CFLAGS, LIBS, PREPEND_* with librt and lrt, with and without the dash before the word. And it seems I can't get it running. Please someone with more experience with gcc/ld fix this..

luolimao commented on 2013-01-08 10:46

There seems to be some info here http://fedoraproject.org/wiki/UnderstandingDSOLinkChange

luolimao commented on 2013-01-08 10:37

Hmm, yeah. I tried using export, and xen's configure told me to use PREPEND_LIB, PREPEND_INCLUDES, etc. but none of those worked with += -librt or += -lrt. I don't really understand gcc's build process at all (even post-googling), so unless someone else has a solution...

luolimao commented on 2013-01-08 10:33

Hmm, yeah. I tried using export, and it told me to use PREPEND_LIB, PREPEND_INCLUDES, etc. but none of those worked with += -librt or += -lrt. I don't really understand gcc's build process at all (even post-googling), so unless someone else has a solution...

Anonymous comment on 2013-01-08 02:58

Still no luck.

==> Starting build()...
patching file tools/Makefile
configure: error: invalid variable name: `LIBS+'
==> ERROR: A failure occurred in build().
Aborting...

luolimao commented on 2013-01-07 22:13

Don't use spaces after LIBS, i.e. try
./configure LIBS+="-librt" PYTHON=/usr/bin/python2

Anonymous comment on 2013-01-07 16:04

Now it gives the error:

==> Starting build()...
patching file tools/Makefile
/tmp/xen/PKGBUILD: line 61: LIBS: command not found
==> ERROR: A failure occurred in build().
Aborting...

fernando_ccs17 commented on 2013-01-07 11:21

kurokuon and 3000:

In PKGBUILD file, the line where have:
"./configure PYTHON=/usr/bin/python2"

try replacing with:
"LIBS += "-librt" ./configure PYTHON=/usr/bin/python2"

without quotes.

Please give feedback if it works.

Anonymous comment on 2013-01-07 06:01

I cant complete the build process. I get the following errors:

=== PCI passthrough capability has been enabled ===
=== PCI passthrough capability has been enabled ===
make[4]: Entering directory `/tmp/xen/src/xen-4.2.1/tools/qemu-xen-traditional-dir/i386-dm'
LINK i386-dm/qemu-dm
/usr/bin/ld: vl.o: undefined reference to symbol 'timer_settime@@GLIBC_2.3.3'
/usr/bin/ld: note: 'timer_settime@@GLIBC_2.3.3' is defined in DSO /usr/lib/librt.so.1 so try adding it to the linker command line
/usr/lib/librt.so.1: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[4]: *** [qemu-dm] Error 1
make[4]: Leaving directory `/tmp/xen/src/xen-4.2.1/tools/qemu-xen-traditional-dir/i386-dm'
make[3]: *** [subdir-i386-dm] Error 2
make[3]: Leaving directory `/tmp/xen/src/xen-4.2.1/tools/qemu-xen-traditional-dir'
make[2]: *** [subdir-install-qemu-xen-traditional-dir] Error 2
make[2]: Leaving directory `/tmp/xen/src/xen-4.2.1/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/tmp/xen/src/xen-4.2.1/tools'
make: *** [install-tools] Error 2
==> ERROR: A failure occurred in package().
Aborting...

Is there a fix to this?

Thanks!

deviousway commented on 2013-01-03 23:15

Compiling whole program out/code32seg.o
Building ld scripts (version "1.6.3.2-20130104_061020-Acelot")
Traceback (most recent call last):
File "./tools/layoutrom.py", line 583, in <module>
main()
File "./tools/layoutrom.py", line 564, in main
info16 = parseObjDump(infile16, '16')
File "./tools/layoutrom.py", line 501, in parseObjDump
relocsection = sectionmap[sectionname]
KeyError: '.text.asm.out/../src/smp.c.68'
make[6]: *** [out/romlayout16.lds] Ошибка 1
make[6]: Выход из каталога `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools/firmware/seabios-dir-remote'
make[5]: *** [subdir-all-seabios-dir] Ошибка 2
make[5]: Выход из каталога `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools/firmware'
make[4]: *** [subdirs-all] Ошибка 2
make[4]: Выход из каталога `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools/firmware'
make[3]: *** [all] Ошибка 2
make[3]: Выход из каталога `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools/firmware'
make[2]: *** [subdir-install-firmware] Ошибка 2
make[2]: Выход из каталога `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools'
make[1]: *** [subdirs-install] Ошибка 2
make[1]: Выход из каталога `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools'
make: *** [install-tools] Ошибка 2
==> ОШИБКА: Произошел сбой в package().
Преждевременный выход...
==> ERROR: Makepkg was unable to build xen.
==> Restart building xen ? [y/N]

3000 commented on 2013-01-03 09:17

hi, I somehow can't build this. I already have xen installed on another harddrive with Xen 4.2, but here I get this error message:

/usr/bin/ld: vl.o: undefined reference to symbol 'timer_settime@@GLIBC_2.3.3'
/usr/bin/ld: note: 'timer_settime@@GLIBC_2.3.3' is defined in DSO /usr/lib/librt .so.1 so try adding it to the linker command line
/usr/lib/librt.so.1: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[4]: *** [qemu-dm] Error 1
make[4]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools/qem u-xen-traditional-dir/i386-dm'
make[3]: *** [subdir-i386-dm] Error 2
make[3]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools/qem u-xen-traditional-dir'
make[2]: *** [subdir-install-qemu-xen-traditional-dir] Error 2
make[2]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools'
make: *** [install-tools] Error 2
==> ERROR: A failure occurred in package().
Aborting...
==> ERROR: Makepkg was unable to build xen.
==> Restart building xen ? [y/N]

I get the same error display when I try to build from source.

how can I fix this??

3000 commented on 2013-01-03 08:29

hi, I somehow can't build this. I already have xen installed on another harddrive with Xen 4.2, but here I get this error message:

/usr/bin/ld: vl.o: undefined reference to symbol 'timer_settime@@GLIBC_2.3.3'
/usr/bin/ld: note: 'timer_settime@@GLIBC_2.3.3' is defined in DSO /usr/lib/librt .so.1 so try adding it to the linker command line
/usr/lib/librt.so.1: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[4]: *** [qemu-dm] Error 1
make[4]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools/qem u-xen-traditional-dir/i386-dm'
make[3]: *** [subdir-i386-dm] Error 2
make[3]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools/qem u-xen-traditional-dir'
make[2]: *** [subdir-install-qemu-xen-traditional-dir] Error 2
make[2]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools'
make: *** [install-tools] Error 2
==> ERROR: A failure occurred in package().
Aborting...
==> ERROR: Makepkg was unable to build xen.
==> Restart building xen ? [y/N]

I get the same error display when I try to build from source.

how can I fix this??

luolimao commented on 2012-12-19 03:58

Thanks, kantras; updated.

kantras commented on 2012-12-18 16:39

4.2.1 has been released. The exist PKGBUILD can be used (once the shasum's are updated) or I just uploaded a modified copy to http://www.kantras.info/xen/PKGBUILD (It also has a fix so that updates won't clobber the /etc/xen/xl.conf file.) I've just built the new version and have it running on a workstation.

Anonymous comment on 2012-12-16 10:19

Custom backend network device name seems not working. When I tried vif = ['ip=192.168.1,2, vifname=vif1.0, backend=networkvm'] in the client domU config file, the backend device in driver domain (networkvm) was named according to default vifDOMID.DEVID and not vif1.0 as specified in the script - resulting in different names every time I restarted the client domU.
Any idea what could cause this strange behaviour?

kantras commented on 2012-11-25 21:03

You will also want to add "etc/$pkgname/xl.conf" to the backup section in the PKGBUILD file to avoid changes (such as to the ballooning settings) being clobbered during an upgrade. I also have a couple of template files for /etc/conf.d/xen{console,store}d if needed.

Also, wondering it's worth making the name for dom0 to be definable via the conf file, defaulting to Domain-0 if nothing is explicitly set.

luolimao commented on 2012-11-22 18:16

Used tmpfiles method, and added the tmpfiles service to requires/after of xenstored.service

paleo9 commented on 2012-11-22 15:14

'thinking aloud'
You have demonstrated that the existence of /run/xen allows the module and its successors to load in your guest, which then runs successfully.
kantras' tmpfiles.d/xen.conf will create that file, tmpfiles.d is usually used for temporary files created in /tmp or /run - fits the bill.

Possible alternative: I have found in the old xencommons script 'mkdir -p /var/run/xen'. It is located before just before xenstored is started. So an equivalent ought to be the same line in ExecStartPre of xenstored.service. Could you try that?

There exists systemd-tmpfiles but seems overkill for our purposes.
tmpfiles is an established method used specifically for our purpose of creating '/run/xen'.
The systemd service file method mimics the old xencommons way, attempting to create '/var/run/xen'

@everybody: Any thoughts?

Refutationalist commented on 2012-11-22 13:06

@paleo9

What you are looking at *is* the initramfs loading up the xen_blkfront module in order to find its root. It can't find it's root because the socket which allows the PV to talk xen, which is supposed to exist in /run/xen. If you'll read the rest of the dump, I create said directory, and the PV loads instantly and without problems.

Again: kantras' tmpfiles.d solution would appear to be the way to go and should be included.

paleo9 commented on 2012-11-22 12:42

@WaxyMouthfeel

Welcome to Finnix!
[*] Total memory: 2004MiB, shared ramdisk: 1591MiB
[*] Setting up ramdisk... done
[*] Loading probed module:
[*] Loading probed module: xen_blkfront
/* and here it freezes until I destroy the domain */

Xen is starting your pv, but the pv fails on startup when attempting to load xen_blkfront. Arch (for example) as a pv guest needs extra modules in its initramfs. The pv guest needs its initramfs image rebuilt with MODULES = "xen-blkfront xen-fbfront xen-netfront xen-kbdfront" in its /etc/mkinitramfs.
Debian doesn't need this additional step to run as a pv guest.

See https://wiki.archlinux.org/index.php/Xen#Installation_notes_for_domU_Paravirtualized_guests and 'Common Errors'.



kantras commented on 2012-11-22 04:34

I have a Windows 7 domU with an ATI 6770 passed through as a secondary adaptor, along with a USB 2.0 root hub and USB 3.0 root hub. Its been working well, except that I can't install the PV drivers without the ATI driver appearing to cause a blue screen on bootup. Still runs well without them. This is on a ASUS Sabertooth 990FX motherboard with an AMD Phenom II x4 965 processor and a total of 12Gb on board (6Gb assigned to the Windows domU)

aaronfitz commented on 2012-11-22 04:12

Just tried the new package and things seem to go much smoother. I had to create the folder /var/lib/xen/ by hand in order to create a HVM though.

Based on the processor usage pattern after I start the HVM Windows 7 is starting, but I'm not getting any display through the video adapter I pass through to the HVM. I never got the dedicated graphics passthrough capability working on 4.1, the graphics was just passed through as a PCI device. Not sure what's going on with the PCI passthrough but I'll keep fiddling with my setup. Anyone here using this for PCI or GFX passthrough yet?

Refutationalist commented on 2012-11-22 01:54

Sorry to insist, but in some supported configurations /run/xen *is* needed: http://pastebin.com/QaqS2Krt

kantras' tmpfiles.d solution would appear to be the way to go and should be included.

luolimao commented on 2012-11-21 22:54

fixed.

paleo9 commented on 2012-11-21 22:46

Just tried the modified xenstored.service, doesn't like it. This is the one: tested, works

ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
ExecStartPost=/usr/bin/xenstore-write "/local/domain/0/name" "Domain-0"

Result:
Name ID Mem VCPUs State Time(s)
Domain-0 0 1024 2 r----- 24.9

paleo9 commented on 2012-11-21 22:41

This is the one: tested, works

ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
ExecStartPost=/usr/bin/xenstore-write "/local/domain/0/name" "Domain-0"

luolimao commented on 2012-11-21 21:50

Removed archinit.patch and added xenstore-write cmd to xenstored service file.

paleo9 commented on 2012-11-21 20:30

Package built with archinit.patch - fail
Package built without archinit.patch - successfully created, logged into and
shut down a pv of Debian wheezy.

created: /run/xenstored /run/xenstored.pid /var/run/xenstored /var/run/xenstored.pid
not created (not needed), /run/xen /var/run/xen

Using journalctl on the failed build showed xendomains failed at three points,
each of which were lines added to xendomains by archinit.patch.

The patch adds to xendomains function calls from rc.d/functions, which no longer exists.
Previously no effect, but now causes xendomains.service to fail. Also all to do
with xend.

Conclusion: previously the patch was useless, now it is a liability.

kantras commented on 2012-11-20 20:04

Actually, I have a file for creating the /run/xen directory as well, on http://www.kantras.info/xen, called tmpfiles.d.xen.conf. In the test PKGBUILD file I was using, I copied it to /usr/lib/tmpfiles.d/xen.conf

paleo9 commented on 2012-11-20 18:09

/var/run/xen is being created on my system, but it is built from the official tarball, with the service files as existed in the 4.2.0-3 arch release. i.e archinit.patch was not used, but otherwise the same as 4.2.0-3.

I 'll take a look tomorrow and do a full aur install of the current version.

Refutationalist commented on 2012-11-20 16:58

* Exactly so. /run/xen needs to exist, isn't (apparently) created by anything, and /run is a ramdisk.

* Every new machine I've installed this package on won't run pv dom0's until /run/xen (or rather, /var/run/xen) exists. Going through what documentation I can find, this is the expected behavior. It could be differences in what we're using on PVs.

* I don't particularly care where it happens, just that it does. :) I initially used && rather than a semi-colon, but it didn't work and systemd documentation said to use a semi-colon, so that's what I did. I am new to systemd.

* I've also built it without archinit.patch and xendomains works without a lot of trouble, at least on startup. Haven't tested shutdown yet. I'm pretty sure the patch was originally one I submitted, and it doesn't appear to have much added to it. All it did was make xen's init files work with our sysvinit.


I think it's also worth noting that I generally have to compile this package on a clean install with base, base-devel and the packages required by the PKGBUILD only, as the xen build process will link to other packages that I have installed on my build machine, but not on the ones I use the package on.

Refutationalist commented on 2012-11-20 16:55

* Exactly so. /run/xen needs to exist, /run is a ramdisk and isn't (apparently) created by anything.

* Every new machine I've installed this package on won't run pv dom0's until /run/xen (or rather, /var/run/xen) exists. Going through what documentation I can find, this is the expected behavior. It could be differences in what we're using on PVs.

* I don't particularly care where it happens, just that it does. :) I initially used && rather than a semi-colon, but it didn't work and systemd documentation said to use a semi-colon, so that's what I did. If && does work, I would also prefer it.

* I've also built it without archinit.patch and xendomains works without a lot of trouble, at least on startup. Haven't tested shutdown yet. I'm pretty sure the patch was originally one I submitted, and it doesn't appear to have much added to it. All it did was make xen's init files work with sysvinit.

paleo9 commented on 2012-11-20 16:36

* This will attempt to create '/run/xen' every time Xen is started.

* I am not sure what you mean by 'which is necessary for pv domains to run with the XL stack', pv domains run fine under xl.

* '/usr/bin/xenstore-write "/local/domain/0/name" "Domain-0"' belongs better in xenstored.service, something like

ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS; /usr/bin/xenstore-write "/local/domain/0/name" "Domain-0"

or preferably use && instead of semicolon if that is allowed.

* I agree with you about the archinit.patch, not sure it's going to break anything but certainly, the first half no longer affects anything and the second half deals with xendomains and probably no longer affects anything (I haven't had a look at things for a week). Either way, I didn't need it to build the official tarball and, if memory serves, I was able to build the Arch package without it too.

Refutationalist commented on 2012-11-20 13:52

Another version of the service file, this time it creates /run/xen, which is necessary for pv domains to run with the XL stack. This was the kind of thing originally handled by xend.

It's a simple change, but I've renamed it xen-dom0-env.service:
--------

[Unit]
Description=Name the Xen Domain0 for use with XL
Requires=xenstored.service
ConditionPathExists=/proc/xen

[Service]
Type=oneshot
ExecStart=/usr/bin/mkdir /run/xen ; /usr/bin/xenstore-write "/local/domain/0/name" "Domain-0"

[Install]
WantedBy=multi-user.target

Refutationalist commented on 2012-11-20 11:12

xendomains.service will break on pure systemd dom0s because of archinit.patch. The patch's original purpose was to make the xen rc files work with Arch's sysvinit better, so it should be fairly painless to remove it.

Also, I think the xen-dom0-name.service file should have it's type set to oneshot rather than simple.

Refutationalist commented on 2012-11-20 11:10

xendomains.service will break on pure systemd dom0s because of archinit.patch. The patch's original purpose was to make the xen rc files work with Arch's sysvinit better, so it should be fairly painless to remove it.

Also, I think the service file should have it's type set to oneshot rather than simple.

Refutationalist commented on 2012-11-20 10:50

Here's a service file to rename the dom0.


xen-dom0-name.service
----
[Unit]
Description=Name the Xen Domain0 for use with XL
Requires=xenstored.service
ConditionPathExists=/proc/xen

[Service]
Type=simple
ExecStart=/usr/bin/xenstore-write "/local/domain/0/name" "Domain-0"

[Install]
WantedBy=multi-user.target

Refutationalist commented on 2012-11-20 10:40

Here's a service file to rename the dom0.

----
[Unit]
Description=Name the Xen Domain0 for use with XL
Requires=xenstored.service
ConditionPathExists=/proc/xen

[Service]
Type=simple
ExecStart=/usr/bin/xenstore-write "/local/domain/0/name" "Domain-0"

[Install]
WantedBy=multi-user.target

Xaseron commented on 2012-11-19 01:55

Typo, .service files won't be copied.

for f in ${source[@]}; do
[[ $f =~ .mount || $f =~ .fice ]] && install -Dm644 $f "$pkgdir"/usr/lib/systemd/system/$f

Xaseron commented on 2012-11-19 01:39

Remove the instruction of addin xenfs to fstab from xen.install. This is not needed because proc-xen.mount does that and it disables the possibility to boot the system without hypervisior.

tritron commented on 2012-11-18 19:48

It seems that sendomains script does not work with system. my xendomains.services status is always failed and my instances are always stopped.
The script does not stop instances at all on shutdown. I had found that open suse xendomains script works fine along with copy of rc.status in /etc/
instances are started at boot time and shutdown and saved at shutdown.

luolimao commented on 2012-11-17 17:19

@xaseron fixed

luolimao commented on 2012-11-17 17:19

Fixed

Xaseron commented on 2012-11-16 13:33

> xen-acpi-processor # This module may not work on all machines; try removing this first if it causes issues.

Of course this module does not load, because you can't write a comment right after a module. This space is reserved for options.

Refutationalist commented on 2012-11-16 07:03

Update on that score, running 3.6.6 and Xen 4.1.3 on Fedora garners the same problem! But running the XCP beta did not. Interesting!

Refutationalist commented on 2012-11-15 15:44

Also, I've compiled and run this on a clean install. The xl toolset doesn't seem to hand proper devices to PV domains, and HVM domains reset the computer without printing anything meaningful beyond:

(XEN) HVM8: int13_harddisk: function 02, unmapped device for ELDL=87
(XEN) HVM8: int13_harddisk: function 41, ELDL out of range 88
(XEN) HVM8: int13_harddisk: function 02, ELDL out of range 88
(XEN) irq.c:375: Dom8 callback via changed to Direct Vector 0xf3

To the serial console.

This is for a machine that I'm deploying soon, I'll keep Arch on it for as long as I can if someone wants me to try things, otherwise I'm going to have to put something else on it and ship it.

kantras commented on 2012-11-15 07:05

FYI - I just uploaded a modified xenstored.service file and var-lib-xenstored.mount (which mounts /var/lib/xenstored as a tmpfs, since it doesn't need to be persistent between boots) to my temp site.

As for libvirt support, I've been tracking xen-devel and its very early stages; see http://lists.xen.org/archives/html/xen-devel/2012-10/msg01853.html for the start of the thread discussing this

luolimao commented on 2012-11-15 06:31

@fernando Added back such useful dirs, and added dependencies.

Refutationalist commented on 2012-11-15 04:00

fernando_ccs17: You have to create /var/lib/xen as a directory.

I've been working on that and some other build-time things.

fernando_ccs17 commented on 2012-11-15 02:26

[root@localhost fernando]# xl create xlexample.hvm
Parsing config from xlexample.hvm
xc: info: VIRTUAL MEMORY ARRANGEMENT:
Loader: 0000000000100000->000000000019dec8
TOTAL: 0000000000000000->0000000007800000
ENTRY ADDRESS: 0000000000100000
xc: info: PHYSICAL MEMORY ALLOCATION:
4KB PAGES: 0x0000000000000200
2MB PAGES: 0x000000000000003b
1GB PAGES: 0x0000000000000000
libxl: error: libxl_dom.c:1535:libxl_userdata_store: cannot write /var/lib/xen/userdata-n.3.77ea2db4-871e-4688-8d7e-f68c1a754b04.xl for /var/lib/xen/userdata-d.3.77ea2db4-871e-4688-8d7e-f68c1a754b04.xl: No such file or directory
cannot save config file: No such file or directory
libxl: error: libxl_dom.c:1462:libxl__userdata_destroyall: glob failed for /var/lib/xen/userdata-?.3.77ea2db4-871e-4688-8d7e-f68c1a754b04.*: No such file or directory


*** the "xen" folder in /var/lib/ does not exist. only "xenstored" exist there.
*** content of xlexample.hvm:
builder = "hvm"
name = "example.hvm"
memory = 128
vcpus = 1
vnc = 1

paleo9 commented on 2012-11-12 18:34

I have never used libvirt, and I do not have a hardware-virtual processor (nor any need for one), so anything I can do will be limited to pv. I have just downloaded v1.0.0 and made an initial attempt to build it. I am also checking out the abs build. However, even if it builds, it may not have all features.

http://wiki.xen.org/wiki/Fedora_Host_Installation
"Starting from Xen 4.2, the default toolstack is libxl. libvirt has a libxl driver, but it (at the time of writing) still lacks many important features... ...There is an on-going effort to fill the gap and render the libvirt libxl driver feature complete and fully functional, although it is yet unclear when that will happen (in particular, whether or not it will make it in time for Fedora 18."

On the other hand, the tarball that I downloaded (stable libvirt 1.0.0) has News November 2 2012 at least mentions xen 4.2. So there may be hope. http://libvirt.org/news.html
"various improvement and fixes when using QMP QEmu interface Support for Xen 4.2 (Jim Fehlig)"

If I have anything more useful to say, I shall put it on some libvirt page and leave a comment here.

loper commented on 2012-11-11 23:09

@ paleo9: thanks, running # xenstore-write "/local/domain/0/name" "Domain-0" manually changed the (null) value.

Is there any way to get libvirt for xen to build without error?

loper commented on 2012-11-11 23:09

@ paleo9: thank's, running # xenstore-write "/local/domain/0/name" "Domain-0" manually changed the (null) value.

Is there any way to get libvirt for xen to build without error?

kantras commented on 2012-11-11 19:13

Writing something to add the name into xenstore (amongst other things, such as using xl to update my assignable pci devices) is on my todo list; right now I just kick off script on bootup, but that won't work for me once I start using xendomains to auto-start.

@fernando_ccs17, my desktop has both an ATI and a Nvidia graphics card in it, and I spend a few hours trying to get the official Nvidia drivers working, only to have to give up for now. The problem is that Nvidia have already stated that they will only support the Quadro series when it comes to virtualization, so i'm waiting for nouveau support to improve. The ATI card, which is passed through to a Windows domU, works much better (although still with quirks at times)

paleo9 commented on 2012-11-11 15:04

Re "Domain-0" and (null), the relevant lines in xencommons are:

echo Setting domain 0 name...
xenstore-write "/local/domain/0/name" "Domain-0"

My thoughts:
It appears to be using "xenstore-write" to place an entry "Domain-0" into the 'name' field of its database. There is only one dom0, so there should not be a "/local/domain/1/name" or "Domain-1" etc. It is unlikely that there will be anything to be gained by checking the value of "/local/domain/0/name/", so unless errors happen it was not a high priority for getting the service file to work.



paleo9 commented on 2012-11-11 14:15

Nothing to worry about. In the old xencommons script, which has been replaced by systemd service files, there was a line which gave the name Domain-0. Can't remember off hand, maybe printed a line into the pid file? Anyway, this line wasn't included in the service file. It's not used by anything, just a label for human eyes.



loper commented on 2012-11-11 14:04

any idea why am I having (null) instead of Domain-0?

luolimao commented on 2012-11-11 13:19

@paleo9 Removed the file from the package.

fernando_ccs17 commented on 2012-11-11 13:17

Hmm... So it works only with nouveau. I Need 3D support for my 9800GT. You know...

paleo9 commented on 2012-11-11 13:03

Just for info: My card is nvidia, I have no problems with the nouveau driver.

fernando_ccs17 commented on 2012-11-11 12:59

Ok thanks.

I'm also having issues with Nvidia drivers with Xen, but it looks that the problem is with the drivers, not Xen. I'm reporting a bug right now. It appears to be a known issue...
http://linuxers.org/howto/how-install-nvidia-driver-xen-kernel-centos-55final

paleo9 commented on 2012-11-11 12:56

Error messages about "'failed to execute /usr/lib/.... xend/udev_event':No such file or directory" (lots of them) are caused by /etc/udev/rules.d/xend.rules

xend is (a) deprecated and (b) not used, it is safe to remove xend.rules

fernando_ccs17 commented on 2012-11-11 12:43

failed to execute '/usr/lib/udev/socket:/org/xen/xend/udev_event' 'socket:/org/xen/xend/udev_event': No such file or directory

I get dozens of this message on boot and on journalctl.
Why's that?

Anonymous comment on 2012-11-11 11:54

thanks luolimao, it's working now.

luolimao commented on 2012-11-10 20:55

It was a typo. My bad, fixed.

Anonymous comment on 2012-11-10 19:35

I got an error during build:
install: cannot stat 'xendomU.service': no such file or directory.

luolimao commented on 2012-11-08 22:32

No objection, I'll do the same.

paleo9 commented on 2012-11-08 22:30

Just done another install from cd. Community *is* enabled.

Sorry for wasting your time, my virgins are obviously not as pure as I thought.

@luolimao To avoid clutter, any objections if I remove my comments?

fernando_ccs17 commented on 2012-11-08 22:23

I never had [community] commented in none of my installations, but [multilib].

luolimao commented on 2012-11-08 22:20

I see; added. Thanks :]

kantras commented on 2012-11-08 22:10

@luolimao: the existing 20_linux_xen file won't pick up the kernel as archlinux deploys it, and puts it after the normal boot config so you have to explicitly select the xen boot option whenever you boot up. The 09_xen version can see the archlinux kernel and also puts it above the normal boot option so that booting into xen + dom0 is the default.

luolimao commented on 2012-11-08 21:41

Either way, the onus is on the user to know about and enabled said repos; nothing I can do about that.

paleo9 commented on 2012-11-08 21:31

The wiki is incorrect or misleading. I have just checked my 'virgin' installations for October and November, both have [community] commented out. Only core and extra are enabled.

luolimao commented on 2012-11-08 21:16

Regarding [community], the Wiki states that it IS enabled by default:
https://wiki.archlinux.org/index.php/Arch_User_Repository#.5Bcommunity.5D

As for [multilib], that will have to be enabled manually, ofc.

luolimao commented on 2012-11-08 21:13

No, you can't list repos as dependencies. Also, dev86 actually is included as a build dependency (see makedepends), because it's only required to build the package.

paleo9 commented on 2012-11-08 21:12

This page lists 12 dependencies, but dev86 is not one of them. It requires the community repo. No user has this enabled by default.

I don't know what information you are able to put here, nor how it's done, but it would be disappointing for someone to find the installation has failed due to a dependency that is not mentioned, and cannot be found using pacman -Syu.

Can repos be listed as dependencies?

paleo9 commented on 2012-11-08 21:08

This page lists 12 dependencies, but dev86 is not one of them.

I don't know what information you are able to put here, nor how it's done, but it would be disappointing for someone to find the installation has failed due to a dependency that is not mentioned, and cannot be found using pacman -Syu.

Can repos be listed as dependencies?

luolimao commented on 2012-11-08 20:44

@kantras
I'll add the texi2html patch, and the updated service files. Why do we need 09_xen, though? Isn't grub-commons' /etc/grub.d/20_linux_xen enough?

@paleo9
I realize not all users have these repos enabled by default, but I'm not sure what you're asking me to do.

paleo9 commented on 2012-11-08 12:06

@luolimao
Does this page have provision for make-depends? I think dev86 in particular needs to be mentioned as it is not available under the repos provided in a default installation - 'community' needs to to be enabled in etc/pacman.conf. ('multilib' also for x86_6).

kantras commented on 2012-11-08 06:37

Please include the texi2html.patch file from the website I mentioned in the previous comment; it allows xen to be compiled if you have extra/texi2html 5.0-2 installed. I also uploaded 09_xen, a tweaked grub2 configration file to be dropped into /etc/grub.d so that grub-mkconfig will detect and add config to support booting the xen kernel image.

If you want the EFI boot image for xen to be built, you have to use a slightly modified version of binutils; I grabbed the PKGBUILD and binutils.install for the latest stable version of binutils-multilib, then edited the PKGBUILD file to add "--enable-targets=x86_64-pep" into the list of options being passed to configure. Once I had built and installed the modified binutils-multilib, the xen.efi image was compiled when I built xen.

luolimao commented on 2012-11-08 00:53

@paleo9
I must have asleep when I edited the PKGBUILD yesterday, my bad. Anyway, fixed.

fernando_ccs17 commented on 2012-11-07 22:02

Thanks. Testing...

kantras commented on 2012-11-07 21:45

I just uploaded the work I had started for systemd service files for xen, into a temporary directory at http://www.kantras.info/xen/ - The key differences are that the xenstored and xenconsoled services will only start on a dom0 which has /proc/xen mounted and has the right capabilities. I also include a patch which allows newer versions of texi2html to be installed. The xendomU service is just one that I'm starting to play with, when you only want to start individual domains.

I'm currently comparing the PKGBUILD against the one I'm using locally. I'm running mainly HVM domU's (linux and windows) on a test server.

paleo9 commented on 2012-11-07 14:38

Not working just yet, but nearly there.

* xendomains is in etc/rc.d but xendomains.service looks in etc/xen/scripts
n.b just something to be aware of: etc/rc.d/xendomains is a script but
/etc/defaults/xendomains is a config file.

* xen.conf is not copied to /etc/modules-load.d

With these issues corrected, the package installs and, after configuration, I could create paravirtualised vms. I don't have a hardware virtual capable processor so cannot comment on hardware virtual etc, but have no reason for any doubt. All the best to you luolimao.
==================
Other considerations:

* package creates a directory in /usr/local (not allowed?)

* package creates man files in /usr/share/man/{man1 man8} that are missing from xen-docs. xen-docs provides files missing from xen 4.2.0-04. The two packages combined create all man files from upstream.

luolimao commented on 2012-11-07 00:42

Updated to work with systemd. Much thanks to paleo9 :D

paleo9 commented on 2012-11-06 12:54

Systemd service files and information given in the github link below, are now in the Xen page of Archwiki.

The wiki page has been completely revised for Xen 4.2, xenstored and the xl toolstack; it includes bootloader and networking configuration.

https://wiki.archlinux.org/index.php/Xen

fernando_ccs17 commented on 2012-11-05 15:01

God bless you, paleo9. I will test it ASAP.

paleo9 commented on 2012-11-03 17:16

I created a set of systemd service files and notes to integrate with Xen 4.2.
They were tested with a virgin install of Arch + Xen4.2 AUR (base, base-devel, xen AUR
tarball and dependencies). Hope you find them useful.
Full details https://gist.github.com/a2b71e4a17fdf7bbcfc0

fernando_ccs17 commented on 2012-10-29 12:00

Thanks. And how can I start xend or xenstored?

luolimao commented on 2012-10-28 23:58

Done.

fernando_ccs17 commented on 2012-10-28 21:19

Please add wget as dep.

luolimao commented on 2012-10-21 15:39

Added your fixes. Btw, the symlinking issue can be fixed by adding PYTHON=/usr/bin/python2 to the configure line (which I have done, obviously). The service file is a bit iffy, b/c it depends on the rc.d script. Will release a service file that's more "systemd-ish" soon.

Anonymous comment on 2012-10-13 21:35

Wow what a pain to build. I needed it running...I don't have the time to do it right but I had to:

remove the dom0 compression patch (looks like it was merged)
remove the xen patch (i'm not convinced that made a difference or not, but saved me going through rejects)
corrected the arch init patch (hopefully I didn't break the init script...it still seems to work correctly)

symlinked python2-config and python2 to python-config and python, respectively. Yikes. Build wouldn't find python2 libs otherwise, and doesn't work with python 3. This needs a better fix.

installed yajl, git, and wget (building required them beyond dependencies in PKGBUILD)

I put up a github repo so I could share a fixed PKGBUILD and archinit patch if anyone needs to build this
https://github.com/iamb/arch-xen

aaronfitz commented on 2012-10-12 11:21

Looks like someone made an attempt to update the PKGBUILD to 4.2. I gave it a quick go and the patching fails. I don't have time to look into it today but wanted to let people know what's going on

==> Starting build()...
patching file tools/hotplug/Linux/init.d/xencommons
Hunk #2 succeeded at 29 with fuzz 1.
Hunk #3 FAILED at 54.
Hunk #4 FAILED at 63.
2 out of 4 hunks FAILED -- saving rejects to file tools/hotplug/Linux/init.d/xencommons.rej
patching file tools/hotplug/Linux/init.d/xend
patching file tools/hotplug/Linux/init.d/xendomains
Hunk #4 succeeded at 200 (offset 5 lines).
Hunk #5 succeeded at 266 (offset 5 lines).
Hunk #6 succeeded at 320 (offset 5 lines).
Hunk #7 succeeded at 433 (offset 5 lines).
patching file tools/hotplug/Linux/init.d/xen-watchdog
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build xen.

fernando_ccs17 commented on 2012-10-06 17:25

So... nothing yet?

franciscod commented on 2012-10-03 02:27

Please add wget and python2 as deps, the build fails without them.

franciscod commented on 2012-10-03 02:26

Please add wget and python2 as deps, the build fails without them.

franciscod commented on 2012-10-03 02:26

Please add wget and python2 as deps, the build fails without them.

Anonymous comment on 2012-09-29 09:35

Have disowned the package. Life's too busy to get this done and don't want to keep people waiting on 4.2.

kantras commented on 2012-09-29 04:17

I'm about 85% complete on a 4.2 PKGBUILD - have systemd inits + texi2html working, just have to finish cleaning up the other init scripts

Anonymous comment on 2012-09-26 19:43

If someone wants to write a PKGBUILD for 4.2, I can orphan this package for them. Not sure when I will get time.

fernando_ccs17 commented on 2012-09-26 17:13

when do you plan to update to 4.2?

Anonymous comment on 2012-09-01 13:17

The error was resolved after installing texi2html version 1.82, as stated by Xaseron. Otherwise there was no problem.

Anonymous comment on 2012-09-01 10:31

The build process error: *** No rule to make target 'unxz.o', needed by 'built_in.o'. Stop. ***
Any ideas about where could be the problem?
Thanks

Anonymous comment on 2012-08-30 19:48

I can only get xen to detect my full memory with this patch. This seems to be a problem of certain UEFI mainboards, see https://bugzilla.redhat.com/show_bug.cgi?id=819235#c3 and http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-should-be-8gb-uefi-boot:
This seems to work fine on my machine, however I can not say anthing about potential side-effects.

-----------snip-----------------

diff -Naur xen-4.1.3.org/xen/arch/x86/setup.c xen-4.1.3/xen/arch/x86/setup.c
--- xen-4.1.3.org/xen/arch/x86/setup.c 2012-08-30 21:15:37.414593798 +0200
+++ xen-4.1.3/xen/arch/x86/setup.c 2012-08-30 21:24:41.801533785 +0200
@@ -661,6 +661,8 @@
if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 )
EARLY_FAIL("Misaligned CPU0 stack.\n");

+#if 0
+ /* disable raw e801 and e820 for now in favor of multiboot provided maps */
if ( e820_raw_nr != 0 )
{
memmap_type = "Xen-e820";
@@ -676,7 +678,9 @@
e820_raw[1].type = E820_RAM;
e820_raw_nr = 2;
}
- else if ( mbi->flags & MBI_MEMMAP )
+ else
+#endif
+ if ( mbi->flags & MBI_MEMMAP )
{
memmap_type = "Multiboot-e820";
while ( (bytes < mbi->mmap_length) && (e820_raw_nr < E820MAX) )

Anonymous comment on 2012-08-13 09:35

Have updated for 4.1.3.

Not sure what causes stubdom to break for you guys. Works for me (I need it for pv-grub).

If you work out a fix let me know.

Xaseron commented on 2012-08-13 08:49

In order to compile my PKGBUILD of 4.1.3 you need an old version of texi2html, below 5.0.
Stubdom still breaks, but i don't need it ;-)

#Mantainer: Luceo
#Contributor: Revellion
#Contributor: Sergej
pkgname=xen
pkgver=4.1.3
pkgrel=1
pkgdesc="Xen 4 (hypervisor and tools)"
arch=(i686 x86_64)
url="http://xen.org/"
license="GPL"
depends=('bin86' 'xz' 'bzip2' 'iproute' 'bridge-utils' 'python2' 'sdl' 'zlib' 'e2fsprogs' 'pkgconfig' 'gnutls' 'lzo2' 'glibc')
[ "$CARCH" == "x86_64" ] && depends=(${depends} 'lib32-glibc')
optdepends=('xen-docs: Xen Official Documentation')
makedepends=('dev86' 'ocaml-findlib' 'iasl')
conflicts=('xen-4.2' 'xen-hg-unstable' 'xen-gdbsx' 'xen4-hg' 'xen4' 'xen3' 'xen-hv-tools' 'libxen4')
provides=('xen')
backup=('etc/xen/xend-config.sxp' 'etc/xen/xend-pci-permissive.sxp' 'etc/xen/xend-pci-quirks.sxp')
options=(!strip)
optional=('xen-docs: documentation for xen')
install=xen.install
source=(
http://bits.xensource.com/oss-xen/release/${pkgver}/xen-${pkgver}.tar.gz
09_xen
archinit.patch
dom0_xz_decompression.patch
)

build() {

cd $srcdir/xen-${pkgver}

patch -p1 -i ../archinit.patch
patch -p1 -i ../dom0_xz_decompression.patch

unset CFLAGS LDFLAGS

make PYTHON=python2 DESTDIR=$pkgdir install-xen
make PYTHON=python2 DESTDIR=$pkgdir install-tools
#make PYTHON=python2 DESTDIR=$pkgdir install-stubdom

sed -i 's#XENDOM_CONFIG=/etc/sysconfig/xendomains#XENDOM_CONFIG=/etc/conf.d/xendomains#' $pkgdir/etc/init.d/xendomains
sed -i "s#touch /var/lock/subsys/xend#mkdir -p /var/lock/subsys\n touch /var/lock/subsys/xend#" $pkgdir/etc/init.d/xend

[ -d $pkgdir/usr/lib64 ] && ( cd $pkgdir/usr && cp -R lib64/* lib/ && rm -R lib64 )
( cd $pkgdir/etc && mv init.d rc.d ) || return 1
rm -f $pkgdir/usr/share/man/man1/qemu-img.1* \
$pkgdir/usr/share/man/man1/qemu.1*

## First experiment to generate grub2.cfg entry
#mkdir -p $pkgdir/etc/grub.d
#chmod +x $srcdir/09_xen
#cp $srcdir/09_xen $pkgdir/etc/grub.d

############ kill unwanted stuff ############

# stubdom: newlib
rm -rf $pkgdir/usr/*-xen-elf

# hypervisor symlinks
rm -rf $pkgdir/boot/xen-4.1.gz
rm -rf $pkgdir/boot/xen-4.gz
rm -rf $pkgdir/boot/xen.gz

# silly doc dir fun
rm -rf $pkgdir/usr/share/doc/xen
rm -rf $pkgdir/usr/share/doc/qemu

# Pointless helper
rm -f $pkgdir/usr/sbin/xen-python-path

# qemu stuff (unused or available from upstream)
rm -rf $pkgdir/usr/share/xen/man
rm -rf $pkgdir/usr/bin/qemu-*-xen
for file in bios.bin openbios-sparc32 openbios-sparc64 ppc_rom.bin \
pxe-e1000.bin pxe-ne2k_pci.bin pxe-pcnet.bin pxe-rtl8139.bin \
vgabios.bin vgabios-cirrus.bin video.x openbios-ppc bamboo.dtb
do
rm -f $pkgdir/usr/share/xen/qemu/$file
done

# adhere to Static Library Packaging Guidelines
rm -rf $pkgdir/usr/lib/*.a

}

md5sums=(
'bed929d5c5e5135cab40e2a6aab73fa0'
'86b98d762ebb43230a038f0a41b0326b'
'7a1ed81ecc828037724bb3280058c9fc'
'4aebccf16b578ed97aa8bab945011f35'
)

M0Rf30 commented on 2012-08-11 00:47

4.1.3 is out

workdowg commented on 2012-08-06 17:41

@beej175560 - "This package builds correctly for me if I set MAKEFLAGS="-j1" in /etc/makepkg.conf"
Didn't see this the first time...I concur.

workdowg commented on 2012-08-06 17:40

[quote] beej175560 - This package builds correctly for me if I set MAKEFLAGS="-j1" in /etc/makepkg.conf[/quote]
Didn't see this the first time...I concur.

workdowg commented on 2012-08-05 02:53

i8259.c:66:9: error: initialization from incompatible pointer type [-Werror]
(MANY lines in between...)
i8259.c:70:5: error: (near initialization for 'interrupt[255]') [-Werror]
cc1: all warnings being treated as errors
make[4]: *** [i8259.o] Error 1
make[4]: Leaving directory `/tmp/packerbuild-0/xen/xen/src/xen-4.1.2/xen/arch/x86'
make[3]: *** [/tmp/packerbuild-0/xen/xen/src/xen-4.1.2/xen/arch/x86/built_in.o] Error 2
make[3]: Leaving directory `/tmp/packerbuild-0/xen/xen/src/xen-4.1.2/xen/arch/x86'
make[2]: *** [/tmp/packerbuild-0/xen/xen/src/xen-4.1.2/xen/xen] Error 2
make[2]: Leaving directory `/tmp/packerbuild-0/xen/xen/src/xen-4.1.2/xen'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/tmp/packerbuild-0/xen/xen/src/xen-4.1.2/xen'
make: *** [install-xen] Error 2
==> ERROR: A failure occurred in build().
Aborting...
The build failed.

Anyone else...

miffe commented on 2012-07-31 11:52

This patch to the PKGBUILD makes it build on i686, fixes parallel make and depends on x86_64


--- PKGBUILD.old 2012-07-23 20:30:26.000000000 +0200
+++ PKGBUILD 2012-07-31 13:49:55.524274223 +0200
@@ -12 +12 @@
-[ "$CARCH" == "x86_64" ] && depends=(${depends} 'lib32-glibc')
+[ "$CARCH" == "x86_64" ] && depends=(${depends[*]} 'lib32-glibc')
@@ -18 +18 @@
-options=(!strip)
+options=(!strip !makeflags !buildflags)
@@ -28,0 +29 @@
+ fix-i8259.patch::http://lists.xen.org/archives/html/xen-devel/2012-01/txto1FW8UIpuq.txt
@@ -40,2 +41 @@
-
-unset CFLAGS LDFLAGS
+ patch -p1 -i $srcdir/fix-i8259.patch

Anonymous comment on 2012-07-27 01:06

This package builds correctly for me if I set MAKEFLAGS="-j1" in /etc/makepkg.conf

Apparently it triggers some bug in GNU make when compiled with parallel make.

Mr.Smith1974 commented on 2012-07-24 18:43

@luceo - No problem. http://dpaste.com/774714/

Anonymous comment on 2012-07-24 11:33

@Mrs.Smith1974 - Can you show more output? That text only shows warnings.

Mr.Smith1974 commented on 2012-07-24 08:02

minios.c: In function ‘minios_detect’:
minios.c:15:34: warning: unused parameter ‘a’ [-Wunused-parameter]
minios.c: In function ‘minios_init’:
minios.c:21:32: warning: unused parameter ‘a’ [-Wunused-parameter]
minios.c: In function ‘minios_cleanup’:
minios.c:26:35: warning: unused parameter ‘a’ [-Wunused-parameter]
rm -f libpci.a
ar rcs libpci.a access.o generic.o dump.o names.o filter.o minios.o
ranlib libpci.a
sed <libpci.pc.in >libpci.pc -e 's,@PREFIX@,/usr/local,' \
-e 's,@INCDIR@,/usr/local/include,' \
-e 's,@LIBDIR@,/usr/local/lib64,' \
-e 's,@IDSDIR@,/usr/local/share,' \
-e 's,@VERSION@,2.2.9,' \
-e 's,@LIBZ@,-lz,'
make[3]: Leaving directory `/tmp/yaourt-tmp-user/aur-xen/src/xen-4.1.2/stubdom/pciutils-x86_64/lib'
make[2]: Leaving directory `/tmp/yaourt-tmp-user/aur-xen/src/xen-4.1.2/stubdom/pciutils-x86_64'
make[1]: Leaving directory `/tmp/yaourt-tmp-user/aur-xen/src/xen-4.1.2/stubdom'
make: *** [install-stubdom] Error 2
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build xen.
==> Restart building xen ? [y/N]

Anonymous comment on 2012-07-23 21:08

I've adopted this package and uploaded a 'working' build.

Tested on x64 fresh build.

Anonymous comment on 2012-07-19 15:55

Mad_Dud: dev86 is part of [multilib] repo which you can enable in /etc/pacman.conf by uncommenting.

I have successfully compiled (but not yet tested) this just by changing 'xz-utils' to 'xz' in PKGBUILD.

Mad_Dud commented on 2012-07-15 20:31

Hello,

Dependency `dev86' of `xen' does not exist.

Which package should be used instead of dev86?

Anonymous comment on 2012-07-15 05:06

hello

I cannot build using gnailuy's patch. Is this true for others? seems like this package needs some love :)

nadley commented on 2012-06-09 19:00

Hi,

This PKGBUILD is out of date it should be updated regardings comments below.

Thanks

Anonymous comment on 2012-05-24 11:20

Hi @revellion, xz-utils is now xz, and there is a small issue when I compile it using gcc 4.7.0. The following patch should work:

--

diff -rc a/xen/include/asm-x86/hvm/svm/intr.h b/xen/include/asm-x86/hvm/svm/intr.h
*** a/xen/include/asm-x86/hvm/svm/intr.h 2012-05-23 03:53:04.639411967 +0800
--- b/xen/include/asm-x86/hvm/svm/intr.h 2012-05-23 03:58:25.169415909 +0800
***************
*** 21,26 ****
#ifndef __ASM_X86_HVM_SVM_INTR_H__
#define __ASM_X86_HVM_SVM_INTR_H__

! void svm_intr_assist(void);

#endif /* __ASM_X86_HVM_SVM_INTR_H__ */
--- 21,26 ----
#ifndef __ASM_X86_HVM_SVM_INTR_H__
#define __ASM_X86_HVM_SVM_INTR_H__

! asmlinkage void svm_intr_assist(void);

#endif /* __ASM_X86_HVM_SVM_INTR_H__ */
diff -rc a/xen/include/asm-x86/hvm/vmx/vmx.h b/xen/include/asm-x86/hvm/vmx/vmx.h
*** a/xen/include/asm-x86/hvm/vmx/vmx.h 2012-05-23 03:53:04.639411967 +0800
--- b/xen/include/asm-x86/hvm/vmx/vmx.h 2012-05-23 03:58:38.896079619 +0800
***************
*** 63,69 ****

void vmx_asm_vmexit_handler(struct cpu_user_regs);
void vmx_asm_do_vmentry(void);
! void vmx_intr_assist(void);
void vmx_do_resume(struct vcpu *);
void vmx_vlapic_msr_changed(struct vcpu *v);
void vmx_realmode(struct cpu_user_regs *regs);
--- 63,69 ----

void vmx_asm_vmexit_handler(struct cpu_user_regs);
void vmx_asm_do_vmentry(void);
! asmlinkage void vmx_intr_assist(void);
void vmx_do_resume(struct vcpu *);
void vmx_vlapic_msr_changed(struct vcpu *v);
void vmx_realmode(struct cpu_user_regs *regs);

Refutationalist commented on 2012-05-03 09:16

You'll want to cd out of that directory. Also, if you add those lines to get pv-grub, you'll want libgl as a dependency.

Refutationalist commented on 2012-04-23 08:29

Hi!

Working on a new package since I'm hoping to upgrade to a modern pvops dom0 and openvswtich.

I would suggest adding the following lines (from a patch):

cd stubdom
make PYTHON=python2 DESTDIR=$pkgdir install-grub
make PYTHON=python2 DESTDIR=$pkgdir XEN_TARGET_ARCH=x86_32 install-grub



Adding these after xen is built will build the pv-grub modules, which are pretty useful for people who give out domU's without access to the dom0. pv-grub is more secure than pygrub.

Refutationalist commented on 2012-04-23 08:20

Hi!

Working on a new package since I'm hoping to upgrade to a modern pvops dom0 and openvswtich.

I would suggest adding the following lines (from a patch):

42,43d41
< make PYTHON=python2 DESTDIR=$pkgdir install-grub
< make PYTHON=python2 DESTDIR=$pkgdir XEN_TARGET_ARCH=x86_32 install-grub



Adding these after xen is built will build the pv-grub modules, which are pretty useful for people who give out domU's without access to the dom0. pv-grub is more secure than pygrub.

encbladexp commented on 2012-03-31 18:04

Take a look at https://bitbucket.org/encbladexp/aur for an up2date Version of this Package. If already fixed the libxl thing, and some dependencies ;-)

Greetings

Anonymous comment on 2012-03-25 00:34

Running makepkg -s on a x86_64 does not resolve the python2 dep.

grossws commented on 2012-03-15 00:39

P. S. I'm building it on x86_64 host.

grossws commented on 2012-03-15 00:38

It fails because can't find as86. So bin86 should be added to makedepends.

Anonymous comment on 2012-03-14 14:16

Hi,
I think you might want to add python2 as a compile-time dependency as well.

fatmike commented on 2012-03-14 08:59

@revellion: Could you please add the following changes?

- The patch that tritron mentioned:
src/xen-4.1.2/tools/libxl/libxl_internal.h needs to be patched
-> /var/run/xenstored.pid needs to be changed to /run/daemons/xenstored.pid

- Copying src/xen-4.1.2/tools/hotplug/Linux/*.rules to pkg/etc/udev/rules.d/

Thanx.

fatmike commented on 2012-03-13 13:05

@Subnaut:
See https://bbs.archlinux.org/viewtopic.php?id=137415 - Post #2

Citral commented on 2012-03-10 13:54

Try creating guest with xl instead of xm.

Anonymous comment on 2012-02-22 02:21

Any one got it up and running?

I get "Error: Device 0 (vif) could not be connected. Hotplug scripts not working.".
Is it possible to Fix it without downgrade udev, mkinitcpio etc.?

I compiled the patches given by aaronfitz to the source (thanks man), but now i'm stuck..

Anonymous comment on 2012-02-09 14:33

Hello,
Can you please provide a link to the patch in plain text format? Pastebin, sprunge.us, something similar. Thanks.

miffe commented on 2012-01-30 23:42

Thanks aaronfitz, I hade exactly that problem and your fix worked!

aaronfitz commented on 2012-01-28 06:09

@miffe: This may interest you. Not sure if you've run into this issue or not.

I was having issues creating a HVM under the x86_64 dom0 I started with. After some digging, it was due to some improper behavior in Xen 4.1 which is patched in xen-unstable. xm list would show dom0, but xm create would cause xend to crash, causing the xm create to fail saying the connection was refused to xend. After this, xm list would show a Domain-Unnamed which was useless. The revisions which fix this issue in xen-unstable are 24341, 24344, and 24345. At first I struggled to get xen-unstable to compile correctly, but was unsuccessful because of an incompatible libyajl. I modified this PKGBUILD to apply those 3 patches and rebooted (losing my reference where I found the revision numbers in the process) and now xend is no longer crashing! Windows just finished installing in my new HVM and is now booted up to its brand new desktop.

@revellion: Are you still active? If so, would you consider adding this to a revision of this package? If not, I'll wait a couple days and see if I can figure out how to push it up myself.

[aaron@myhost 41newpatch]$ diff -au ../orig41/ .
Only in .: 24341.patch
Only in .: 24344.patch
Only in .: 24345.patch
diff -au ../orig41/PKGBUILD ./PKGBUILD
--- ../orig41/PKGBUILD 2011-10-22 10:26:27.000000000 -0500
+++ ./PKGBUILD 2012-01-28 00:04:43.252295563 -0600
@@ -2,7 +2,7 @@
#Contributor WaxyMouthfeel
pkgname=xen
pkgver=4.1.2
-pkgrel=1
+pkgrel=2
pkgdesc="Xen 4 (hypervisor and tools)"
arch=(i686 x86_64)
url="http://xen.org/"
@@ -20,7 +20,10 @@
09_xen
xen.patch
archinit.patch
- dom0_xz_decompression.patch)
+ dom0_xz_decompression.patch
+ 24341.patch
+ 24344.patch
+ 24345.patch)

build() {

@@ -30,6 +33,9 @@
patch -p1 -i ../xen.patch
patch -p1 -i ../archinit.patch
patch -p1 -i ../dom0_xz_decompression.patch
+ patch -p1 -i ../24341.patch
+ patch -p1 -i ../24344.patch
+ patch -p1 -i ../24345.patch

unset CFLAGS LDFLAGS

@@ -86,4 +92,7 @@
'1eb1de5675e4499018a37c3a5de973fe'
'f149bae1a6b420e49c51b9f3a74338a4'
'7a1ed81ecc828037724bb3280058c9fc'
- '4aebccf16b578ed97aa8bab945011f35')
+ '4aebccf16b578ed97aa8bab945011f35'
+ 'b561220323e84359d98cd51ba8063aad'
+ '3a3a9ba7324ce52b13f1e450c9ed2585'
+ '95a220076aec53764ca71aacb02f856d')
[aaron@myhost 41newpatch]$ cat 24341.patch
diff -r 3f815406feb2 -r 60d4e257d04b xen/arch/x86/x86_64/mmconfig_64.c
--- a/xen/arch/x86/x86_64/mmconfig_64.c Mon Nov 28 13:37:17 2011 +0100
+++ b/xen/arch/x86/x86_64/mmconfig_64.c Fri Dec 02 09:05:26 2011 +0100
@@ -23,7 +23,7 @@
char __iomem *virt;
};
static struct mmcfg_virt *pci_mmcfg_virt;
-static int __initdata mmcfg_pci_segment_shift;
+static unsigned int mmcfg_pci_segment_shift;

static char __iomem *get_virt(unsigned int seg, unsigned bus)
{

[aaron@myhost 41newpatch]$ cat 24344.patch
diff -r 109b99239b21 -r 72f4e4cb7440 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c Fri Dec 02 06:07:52 2011 -0800
+++ b/tools/libxc/xc_cpuid_x86.c Fri Dec 02 06:31:14 2011 -0800
@@ -43,23 +43,23 @@
static void cpuid(const unsigned int *input, unsigned int *regs)
{
unsigned int count = (input[1] == XEN_CPUID_INPUT_UNUSED) ? 0 : input[1];
+#ifdef __i386__
+ /* Use the stack to avoid reg constraint failures with some gcc flags */
asm (
-#ifdef __i386__
"push %%ebx; push %%edx\n\t"
-#else
- "push %%rbx; push %%rdx\n\t"
-#endif
"cpuid\n\t"
"mov %%ebx,4(%4)\n\t"
"mov %%edx,12(%4)\n\t"
-#ifdef __i386__
"pop %%edx; pop %%ebx\n\t"
+ : "=a" (regs[0]), "=c" (regs[2])
+ : "0" (input[0]), "1" (count), "S" (_regs)
+ : "memory" );
#else
- "pop %%rdx; pop %%rbx\n\t"
+ asm (
+ "cpuid"
+ : "=a" (regs[0]), "=b" (regs[1]), "=c" (regs[2]), "=d" (regs[3])
+ : "0" (input[0]), "2" (count) );
#endif
- : "=a" (regs[0]), "=c" (regs[2])
- : "0" (input[0]), "1" (count), "S" (regs)
- : "memory" );
}

/* Get the manufacturer brand name of the host processor. */
diff -r 109b99239b21 -r 72f4e4cb7440 tools/misc/xen-detect.c
--- a/tools/misc/xen-detect.c Fri Dec 02 06:07:52 2011 -0800
+++ b/tools/misc/xen-detect.c Fri Dec 02 06:31:14 2011 -0800
@@ -35,18 +35,21 @@

static void cpuid(uint32_t idx, uint32_t *regs, int pv_context)
{
+#ifdef __i386__
+ /* Use the stack to avoid reg constraint failures with some gcc flags */
asm volatile (
-#ifdef __i386__
-#define R(x) "%%e"#x"x"
-#else
-#define R(x) "%%r"#x"x"
-#endif
- "push "R(a)"; push "R(b)"; push "R(c)"; push "R(d)"\n\t"
+ "push %%eax; push %%ebx; push %%ecx; push %%edx\n\t"
"test %1,%1 ; jz 1f ; ud2a ; .ascii \"xen\" ; 1: cpuid\n\t"
"mov %%eax,(%2); mov %%ebx,4(%2)\n\t"
"mov %%ecx,8(%2); mov %%edx,12(%2)\n\t"
- "pop "R(d)"; pop "R(c)"; pop "R(b)"; pop "R(a)"\n\t"
+ "pop %%edx; pop %%ecx; pop %%ebx; pop %%eax\n\t"
: : "a" (idx), "c" (pv_context), "S" (regs) : "memory" );
+#else
+ asm volatile (
+ "test %5,%5 ; jz 1f ; ud2a ; .ascii \"xen\" ; 1: cpuid\n\t"
+ : "=a" (regs[0]), "=b" (regs[1]), "=c" (regs[2]), "=d" (regs[3])
+ : "0" (idx), "1" (pv_context), "2" (0) );
+#endif
}

static int check_for_xen(int pv_context)

[aaron@myhost 41newpatch]$ cat 24345.patch
diff -r 72f4e4cb7440 -r 491c3ebf1d37 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c Fri Dec 02 06:31:14 2011 -0800
+++ b/tools/libxc/xc_cpuid_x86.c Fri Dec 02 08:40:02 2011 -0800
@@ -52,7 +52,7 @@
"mov %%edx,12(%4)\n\t"
"pop %%edx; pop %%ebx\n\t"
: "=a" (regs[0]), "=c" (regs[2])
- : "0" (input[0]), "1" (count), "S" (_regs)
+ : "0" (input[0]), "1" (count), "S" (regs)
: "memory" );
#else
asm (

aaronfitz commented on 2012-01-28 06:07

@miffe: This may interest you. Not sure if you've run into this issue or not.

I was having issues creating a HVM under the x86_64 dom0 I started with. After some digging, it was due to some improper behavior in Xen 4.1 which is patched in xen-unstable. xm list would show dom0, but xm create would cause xend to crash, causing the xm create to fail saying the connection was refused to xend. After this, xm list would show a Domain-Unnamed which was useless. The revisions which fix this issue in xen-unstable are 24341, 24344, and 24345. At first I struggled to get xen-unstable to compile correctly, but was unsuccessful because of an incompatible libyajl. I modified this PKGBUILD to apply those 3 patches and rebooted (losing my reference where I found the revision numbers in the process) and now xend is no longer crashing! Windows just finished installing in my new HVM and is now booted up to its brand new desktop.

@revellion: Are you still active? If so, would you consider adding this to a revision of this package? If not, I'll wait a couple days and see if I can figure out how to push it up myself.

@miffe: This may interest you. Not sure if you've run into this issue or not.

I was having issues creating a HVM under the x86_64 dom0 I started with. After some digging, it was due to some improper behavior in Xen 4.1 which is patched in xen-unstable. xm list would show dom0, but xm create would cause xend to crash, causing the xm create to fail saying the connection was refused to xend. After this, xm list would show a Domain-Unnamed which was useless. The revisions which fix this issue in xen-unstable are 24341, 24344, and 24345. At first I struggled to get xen-unstable to compile correctly, but was unsuccessful because of an incompatible libyajl. I modified this PKGBUILD to apply those 3 patches and rebooted (losing my reference where I found the revision numbers in the process) and now xend is no longer crashing! Windows just finished installing in my new HVM and is now booted up to its brand new desktop.

@revellion: Are you still active? If so, would you consider adding this to a revision of this package? If not, I'll wait a couple days and see if I can figure out how to push it up myself.

[aaron@myhost 41newpatch]$ diff -au ../orig41/ .
Only in .: 24341.patch
Only in .: 24344.patch
Only in .: 24345.patch
diff -au ../orig41/PKGBUILD ./PKGBUILD
--- ../orig41/PKGBUILD 2011-10-22 10:26:27.000000000 -0500
+++ ./PKGBUILD 2012-01-28 00:04:43.252295563 -0600
@@ -2,7 +2,7 @@
#Contributor WaxyMouthfeel
pkgname=xen
pkgver=4.1.2
-pkgrel=1
+pkgrel=2
pkgdesc="Xen 4 (hypervisor and tools)"
arch=(i686 x86_64)
url="http://xen.org/"
@@ -20,7 +20,10 @@
09_xen
xen.patch
archinit.patch
- dom0_xz_decompression.patch)
+ dom0_xz_decompression.patch
+ 24341.patch
+ 24344.patch
+ 24345.patch)

build() {

@@ -30,6 +33,9 @@
patch -p1 -i ../xen.patch
patch -p1 -i ../archinit.patch
patch -p1 -i ../dom0_xz_decompression.patch
+ patch -p1 -i ../24341.patch
+ patch -p1 -i ../24344.patch
+ patch -p1 -i ../24345.patch

unset CFLAGS LDFLAGS

@@ -86,4 +92,7 @@
'1eb1de5675e4499018a37c3a5de973fe'
'f149bae1a6b420e49c51b9f3a74338a4'
'7a1ed81ecc828037724bb3280058c9fc'
- '4aebccf16b578ed97aa8bab945011f35')
+ '4aebccf16b578ed97aa8bab945011f35'
+ 'b561220323e84359d98cd51ba8063aad'
+ '3a3a9ba7324ce52b13f1e450c9ed2585'
+ '95a220076aec53764ca71aacb02f856d')
[aaron@myhost 41newpatch]$ cat 24341.patch
diff -r 3f815406feb2 -r 60d4e257d04b xen/arch/x86/x86_64/mmconfig_64.c
--- a/xen/arch/x86/x86_64/mmconfig_64.c Mon Nov 28 13:37:17 2011 +0100
+++ b/xen/arch/x86/x86_64/mmconfig_64.c Fri Dec 02 09:05:26 2011 +0100
@@ -23,7 +23,7 @@
char __iomem *virt;
};
static struct mmcfg_virt *pci_mmcfg_virt;
-static int __initdata mmcfg_pci_segment_shift;
+static unsigned int mmcfg_pci_segment_shift;

static char __iomem *get_virt(unsigned int seg, unsigned bus)
{

[aaron@myhost 41newpatch]$ cat 24344.patch
diff -r 109b99239b21 -r 72f4e4cb7440 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c Fri Dec 02 06:07:52 2011 -0800
+++ b/tools/libxc/xc_cpuid_x86.c Fri Dec 02 06:31:14 2011 -0800
@@ -43,23 +43,23 @@
static void cpuid(const unsigned int *input, unsigned int *regs)
{
unsigned int count = (input[1] == XEN_CPUID_INPUT_UNUSED) ? 0 : input[1];
+#ifdef __i386__
+ /* Use the stack to avoid reg constraint failures with some gcc flags */
asm (
-#ifdef __i386__
"push %%ebx; push %%edx\n\t"
-#else
- "push %%rbx; push %%rdx\n\t"
-#endif
"cpuid\n\t"
"mov %%ebx,4(%4)\n\t"
"mov %%edx,12(%4)\n\t"
-#ifdef __i386__
"pop %%edx; pop %%ebx\n\t"
+ : "=a" (regs[0]), "=c" (regs[2])
+ : "0" (input[0]), "1" (count), "S" (_regs)
+ : "memory" );
#else
- "pop %%rdx; pop %%rbx\n\t"
+ asm (
+ "cpuid"
+ : "=a" (regs[0]), "=b" (regs[1]), "=c" (regs[2]), "=d" (regs[3])
+ : "0" (input[0]), "2" (count) );
#endif
- : "=a" (regs[0]), "=c" (regs[2])
- : "0" (input[0]), "1" (count), "S" (regs)
- : "memory" );
}

/* Get the manufacturer brand name of the host processor. */
diff -r 109b99239b21 -r 72f4e4cb7440 tools/misc/xen-detect.c
--- a/tools/misc/xen-detect.c Fri Dec 02 06:07:52 2011 -0800
+++ b/tools/misc/xen-detect.c Fri Dec 02 06:31:14 2011 -0800
@@ -35,18 +35,21 @@

static void cpuid(uint32_t idx, uint32_t *regs, int pv_context)
{
+#ifdef __i386__
+ /* Use the stack to avoid reg constraint failures with some gcc flags */
asm volatile (
-#ifdef __i386__
-#define R(x) "%%e"#x"x"
-#else
-#define R(x) "%%r"#x"x"
-#endif
- "push "R(a)"; push "R(b)"; push "R(c)"; push "R(d)"\n\t"
+ "push %%eax; push %%ebx; push %%ecx; push %%edx\n\t"
"test %1,%1 ; jz 1f ; ud2a ; .ascii \"xen\" ; 1: cpuid\n\t"
"mov %%eax,(%2); mov %%ebx,4(%2)\n\t"
"mov %%ecx,8(%2); mov %%edx,12(%2)\n\t"
- "pop "R(d)"; pop "R(c)"; pop "R(b)"; pop "R(a)"\n\t"
+ "pop %%edx; pop %%ecx; pop %%ebx; pop %%eax\n\t"
: : "a" (idx), "c" (pv_context), "S" (regs) : "memory" );
+#else
+ asm volatile (
+ "test %5,%5 ; jz 1f ; ud2a ; .ascii \"xen\" ; 1: cpuid\n\t"
+ : "=a" (regs[0]), "=b" (regs[1]), "=c" (regs[2]), "=d" (regs[3])
+ : "0" (idx), "1" (pv_context), "2" (0) );
+#endif
}

static int check_for_xen(int pv_context)

[aaron@myhost 41newpatch]$ cat 24345.patch
diff -r 72f4e4cb7440 -r 491c3ebf1d37 tools/libxc/xc_cpuid_x86.c
--- a/tools/libxc/xc_cpuid_x86.c Fri Dec 02 06:31:14 2011 -0800
+++ b/tools/libxc/xc_cpuid_x86.c Fri Dec 02 08:40:02 2011 -0800
@@ -52,7 +52,7 @@
"mov %%edx,12(%4)\n\t"
"pop %%edx; pop %%ebx\n\t"
: "=a" (regs[0]), "=c" (regs[2])
- : "0" (input[0]), "1" (count), "S" (_regs)
+ : "0" (input[0]), "1" (count), "S" (regs)
: "memory" );
#else
asm (

aaronfitz commented on 2012-01-28 00:57

@miffe: Thanks, that worked. For the interested, I did some digging on why--it's a bug with libc attempting to use AVX instructions which are not valid unless XSAVE is enabled. Arch has a fix in glibc-2.15-4 in [testing]: https://bugs.archlinux.org/task/27828

miffe commented on 2012-01-27 10:54

@aaronfitz: I figured it out, you need to add xsave=1 to the xen commandline.

aaronfitz commented on 2012-01-27 05:14

I'm getting the exact same error as miffe. New to Xen so I'm sure I just missed something along the way...

tritron commented on 2012-01-22 06:11

Well it looks like xl is looking in wrong place for xenstored.pid
libxl: error: libxl.c:56:libxl_ctx_init Is xenstore daemon running?
failed to stat /var/run/xenstored.pid: No such file or directory
src/xen-4.1.2/tools/libxl/libxl_internal.h needs to be patched
/var/run/xenstored.pid needs to be changed to /run/daemons/xenstored.pid


Hiz commented on 2012-01-21 02:49

My environment are x86_64. core/linux-lts 3.0.17-1
I got an error below while compiling.
"ERROR: ld.so: object 'libfakeroot.so' from LD_PRELOAD cannot be preloaded: ignored."
and I had to do..

To compile done:
lib32-fakeroot (must build)
extra/bin86 (extra dependency with dev86)

To run:
core/bridge-utils
modprobe -a xen-evtchn (or add rc.conf)

Hiz commented on 2012-01-21 01:29

My environment are x86_64. core/linux-lts 3.0.17-1
I got an error below while compiling.
"ERROR: ld.so: object 'libfakeroot.so' from LD_PRELOAD cannot be preloaded: ignored."
and I had to do..

To compile done:
lib32-fakeroot (must build)
extra/bin86 (extra dependency with dev86)

To run:
core/bridge-utils
modprobe -a xen-evtchn (or add rc.conf)

Hiz commented on 2012-01-21 01:26

my enviroment are x86_64. core/linux-lts 3.0.17-1
I got an error below while compiling.
"ERROR: ld.so: object 'libfakeroot.so' from LD_PRELOAD cannot be preloaded: ignored."
and I had to do..

To compile done:
lib32-fakeroot (must build)
extra/bin86 (extra dependency with dev86)

To run:
core/bridge-utils
modprobe -a xen-evtchn (or add rc.conf)

Hiz commented on 2012-01-21 01:22

I got an error below while compiling.
"ERROR: ld.so: object 'libfakeroot.so' from LD_PRELOAD cannot be preloaded: ignored."

and I had to do..
To compile done:
lib32-fakeroot (must build)
extra/bin86 (extra dependency with dev86)

To run:
core/bridge-utils
modprobe -a xen-evtchn (or add rc.conf)

miffe commented on 2012-01-19 19:33

I can't get xen to work with the arch kernel on x86_64. I get a lot of "Illegal Instruction" during initramfs and it fails to boot. Screenshot of error here http://imgur.com/zn92R
Syslinux cmdline is: COM32 mboot.c32 ../xen-4.1.2.gz dom0_mem=8G iommu=1 --- ../vmlinux-linux root=/dev/md126p2 ro --- ../initramfs-linux.img

Anyone know how to fix this?

Anonymous comment on 2011-12-28 07:35

Patch to archinit.patch, without this patch new xl toolstack doesn't work.
index 645a66e..6e606ec 100644
--- a/archinit.patch
+++ b/archinit2.patch
@@ -25,10 +25,8 @@ diff -Naur orig.xen-4.1.1//tools/hotplug/Linux/init.d/xencommons xen-4.1.1//tool
test -z "$XENSTORED_TRACE" || XENSTORED_ARGS=" -T /var/log/xen/xenstored-trace.log"

- echo -n Starting xenstored...
-- xenstored --pid-file=/var/run/xenstored.pid $XENSTORED_ARGS
+ #echo -n Starting xenstored...
+ stat_busy "Starting xenstored"
-+ xenstored --pid-file=/run/daemons/xenstored.pid $XENSTORED_ARGS

# Wait for xenstored to actually come up, timing out after 30 seconds
while [ $time -lt $timeout ] && ! `xenstore-read -s / >/dev/null 2>&1` ; do

fackamato commented on 2011-11-30 16:36

Looks like the package needs 'bin86' in makedepends. (as86 missing)

chenxiaolong commented on 2011-11-18 00:05

Could you add:

sed -i '/xen_configfile/d' "${pkgdir}/etc/grub.d/09_xen"

to the end of the PKGBUILD or remove the xen_configfile line from 09_xen? That fixes the GRUB2 config generation problem.

iankarmstrong commented on 2011-10-24 11:35

I have installed the Xen 4.1.2 package and I am having the following problem.

Pygrub gives the following error:
Error: Boot loader didn't return any data!

If I try the following:
pygrub /xen/centos.1/centos.5-7.x86.20110914.img

I get this error:
RuntimeError: Unable to find partition containing kernel

I am using Xen images I downloaded from stacklet.com, and I have tried both 32 and 64 bit images, and I get the same error. I have also tried changing the partition information in my pygrub.cfg, and that does not help either.

I have installed Xen on Arch x86_64 with lib32-glibc. I don't understand why Xen needs "lib32-glibc" when it is running on a x86_64 system. It seems like Xen is not yet fully x86_64 compatible.

This is the pygrub.cfg I am using.

bootloader = "/usr/bin/pygrub"
memory = 512
name = "centos.1"
vif = [ '' ]
disk = ['file:/xen/pmos.processmaker.info/centos.6-0.x86-64.20110710.img,xvda,w']
root = "/dev/xvda"
extra = "fastboot"

Any help would be appreciated.




d1t2hsu commented on 2011-10-23 10:42

failure due to texi2html 5.0-1 ambiguous "-number" option
aad this line before make:
sed -i 's/-number/-number-sections -number-footnotes/' $srcdir/xen-${pkgver}/tools/ioemu-qemu-xen/Makefile

Anonymous comment on 2011-10-07 05:41

Sorry for multiple posts.
Couldn't sleep - it works! Magic of that patch :)

Anonymous comment on 2011-10-07 04:27

Have you successfully booted any HVM's?
For me they reboot instantly after creation...
So from here (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636594) I found, xen 4.1.1 compiled with gcc 4.6 results in in broken hvmloader. There is a link to Launchpad bug where you can find link to patch that should fix the problem (http://xenbits.xen.org/hg/staging/xen-4.1-testing.hg/rev/1976adbf2b80). I should test it tomorrow (it's 7am and I need sleep :)), but I'm writing here so you could test it too (if you had problems).

Anonymous comment on 2011-10-06 13:02

Actually I feel kinda lost know. Everything works, but I thought about assumptions in that patch. It assumes that you have XEN capable kernel (but on archlinux this is true only with 64bits, because 32bits doesn't have XEN support enabled by default ('cause devs don't want to enable PAE)) so if you run this on 32bit system you will end up with one unbootable grub2 menu entry. Maybe you should just patch the naming scheme and echo in post_install() that if you want to use grub2 menu entry generation you should put config file of your kernel in /boot/. (on running kernel just run zcat /proc/config.gz > /boot/config-linux).
So, I don't know and that's your choice :)

The next thing is with archinit.patch, it changes the place where xenstored.pid is located (from /var/run to /var/run/daemons) and that causes XL (the new XEN configuration utility) to break.

M0Rf30 commented on 2011-10-06 11:31

please let me know if it works...cause I don't understand your patch format

Anonymous comment on 2011-10-06 09:34

So, why don't you chmod +x 09_xen patch? So it would be executed, when you call grub-mkconfig?
And to get that script to work I needed to patch it like this:
14a15
>
85,93c86,87
< xen_configfiles=`grep -l 'CONFIG_XEN_PRIVILEGED_GUEST=y' /boot/config-*`
<
< for i in $xen_configfiles ; do
< i=`echo $i | sed -e "s,/boot/config-,/boot/vmlinuz26-,g"`;
< if grub_file_is_not_garbage "$i"; then
< list="$list $i";
< fi
< done
<
---
> list="/boot/vmlinuz-linux";
>
101c95
< base_init=`echo $basename | sed -e "s,vmlinuz,kernel,g"`
---
> base_init=`echo $basename | sed -e "s,vmlinuz,initramfs,g"`

Of course there are no checks left about xen support in kernel and it works only with one kernel (I was too lazy to put kernel config files in boot) :)

P.s
But you should patch that script to reflect new naming scheme of kernel in arch :)

hollunder commented on 2011-09-02 09:09

The package did build for me now (still with gcc-multilib), but namcap throws quite a lot of warnings: http://pastebin.com/cpzetB6J

M0Rf30 commented on 2011-08-28 01:32

try to use gcc and not gcc-multilib

hollunder commented on 2011-08-27 19:04

fails to build with:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/cc1: error while loading shared libraries: libcloog-isl.so.1: cannot open shared object file: No such file or directory

Anonymous comment on 2011-08-24 20:28

building also requires iasl.

M0Rf30 commented on 2011-08-23 00:21

added ocaml-findlib as makedep

nikin commented on 2011-08-18 00:26

I could not get this to work in a 32bit enviroment.
It fails to find the root partition. regardless of kernel used.
tested with plain ext3, with md, with LVM, and with md+LVM(which is the planned use)
Using the same package on 64 bit is fine.
Booting the xen patched kernels without the hypervisor on 32 bit works fine.
I was last trying the package on the 8th of august. But my only test machine is
a production machine. So if you could test this, i would really aprechiate it.
I know that nowdays the base is to use 64 bit. But i have some older machines that
i would like to switch to arch, which are 32bit only.

bests

Anonymous comment on 2011-08-17 08:30

when compiling the package,the error message comes to me:
ocamlfind: Command not found......

finally i find the problem:
make-depends is not right.
ocaml or ocaml-findlib is needed!

grossws commented on 2011-08-16 08:47

1) iasl should be in make-depends

2) what's about vanilla 3.0.1 kernel?
$zcat /proc/config.gz | grep XEN :
CONFIG_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=128
CONFIG_XEN_SAVE_RESTORE=y
# CONFIG_XEN_DEBUG_FS is not set
# CONFIG_XEN_DEBUG is not set
CONFIG_PCI_XEN=y
CONFIG_XEN_PCIDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_BACKEND=m
CONFIG_NETXEN_NIC=m
CONFIG_XEN_NETDEV_FRONTEND=m
CONFIG_XEN_NETDEV_BACKEND=m
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m
CONFIG_HVC_XEN=y
CONFIG_XEN_WDT=m
CONFIG_XEN_FBDEV_FRONTEND=m
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=m
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=m
CONFIG_XEN_GNTDEV=m
CONFIG_XEN_GRANT_DEV_ALLOC=m
CONFIG_XEN_PLATFORM_PCI=m
CONFIG_SWIOTLB_XEN=y

Anonymous comment on 2011-08-15 23:18

After discussing the problem with people who know more than I've come to the conclusion that the problem is this line
-----
[ "$CARCH" == "x86_64" ] && depends=(${depends} 'lib32-glibc')
-----
This line is incorrect, since it only takes the first unit, should be changed depends on depends [@]
After correcting the line would look like:
----
[ "$CARCH" == "x86_64" ] && depends=(${depends[@]} 'lib32-glibc')
----

Thx Exio #Archlinux-es, freenode :-P

Anonymous comment on 2011-08-15 22:35

Dependences problem:
yaourt -S xen

==> Edit PKGBUILD ? [Y/n] ("A" to abort)
==> ------------------------------------
==> n

==> xen dependencies:
- xz-utils (already installed)
- lib32-glibc (package found)
- dev86 (package found)


==> Continue building xen ? [Y/n]
-------

yaourt -Si xen | grep Depends
Depends On : xz-utils bzip2 iproute bridge-utils python2 sdl zlib e2fsprogs bin86 pkgconfig iasl gnutls lzo2 glibc

Only takes first dependence.
I do not know what is wrong, but other similar packages are working properly.

Anonymous comment on 2011-08-12 14:05

Day 09/08/2011 build xen perfectly from yaourt.
Day 12/08/2011 after pacman upgrade yaourt don't recongnize all dependences, only first dependence.
If I change depends =('dep1' 'dep2') to depends =('dep1 dep2') works well.

I don't know is a pkgbuild, yaourt or pacman problem.

Refutationalist commented on 2011-08-10 01:30

Oh, here's that patch to extract a PV-GRUB compatible kernel: https://lkml.org/lkml/2011/8/4/168

Refutationalist commented on 2011-08-10 01:29

The problem with HVM for me is apparently something in Xen 4.1.1 itself, as building a xen-unstable package fixes it.

And as far as the XZ-compressed kernels, there's an lkml patch out there that extracts an uncompressed vmlinux from a bzImage. I'm working on a script to automatically build and start an archlinux dom0 from domU, and this is how I'm making the stock kernel26 (for now, obv.) package work with Xen.

Using that and the kernel26-lts package, my phone server's been running in a dom0 for a couple weeks without trouble.

Huulivoide commented on 2011-08-09 16:03

what aboutdoing like this
------------------
[ "$CARCH" == "x86_64" ] && depends=(${depends} 'lib32-glibc')
------------------------

bjorn-oivind commented on 2011-08-08 12:08

The 3.0 kernel has everything I need for domain-0, but the stock Arch images is XZ-compressed, which is not supported in Xen 4.1.
The following patches adds support for this, they are based on the commit introducing XZ-support in xen-unstable.hg (which can be found here: http://xenbits.xensource.com/hg/xen-unstable.hg/rev/9eb9948904cd )

dom0_xz_decompression.patch: http://pastebin.com/KBnGBupT
PKGBUILD.patch: http://pastebin.com/ji17yCZH

I just booted this with the stock arch 3.0.1 kernel, I've done no testing beyond that.
As a bonus, with this you can use XZ-compressed initrd's too.

Refutationalist commented on 2011-07-09 14:57

What kernel are folks using with this? The ood one in AUR? I've been rolling my own and having a heck of a time getting HVMs to run.

Refutationalist commented on 2011-07-05 20:54

http://codepad.org/dzCVeARK

This is a patch for the init scripts... I cut out some conditionals to check for distros we aren't and I added in some stuff to make it work better with the Arch Linux init process. The xendomains script works, but is hackish and looks funny.

haagch commented on 2011-05-27 23:40

Doesn't work with texi2html-5.0 anymore.
works with texi2html-1.82.

I think upstream knows it but it AGAIN breaks the build process.

linuxSEAT commented on 2011-05-26 09:24

Dependency `lib32-glibc' of `xen' does not exist.

Refutationalist commented on 2011-05-14 03:11

Looks like ocaml and ocaml-findlib are a requirement for (at least) building, and lzo2 is necessary for it to run.

M0Rf30 commented on 2011-04-22 09:39

gcc 4.6 issue fixed;
splitted in xen and xen-docs, to avoid the huge texlive-core dependency if doc is unneded
a little cleanup in $pkgdir

Anonymous comment on 2011-04-20 00:01

hi diver92.

I also encountered this promblem before, may be your gcc version is too high (my is 4.6.0), so it opened the "-Werror=unused-but-set-variable" options by default. You may disable this option in gcc or downgrading gcc to a lower version. In current archlinux core package is 4.5.*. It's no problem.

I guess you open the "[testing]" section in pacman.conf, comment it, and then pacman -Sy at first.

If you encouter "as" error, do like above to the "binutils" package.

Anonymous comment on 2011-04-18 11:15

Hello! I can't build it! Compilation crashed with following errors:


gcc -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -DNDEBUG -nostdinc -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/tmp/yaourt-tmp-root/aur-xen/src/xen-4.1.0/xen/include -I/tmp/yaourt-tmp-root/aur-xen/src/xen-4.1.0/xen/include/asm-x86/mach-generic -I/tmp/yaourt-tmp-root/aur-xen/src/xen-4.1.0/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -mno-red-zone -fpic -fno-asynchronous-unwind-tables -DGCC_HAS_VISIBILITY_ATTRIBUTE -g -D__XEN__ -MMD -MF .cpupool.o.d -c cpupool.c -o cpupool.o
cpupool.c: In function ‘cpupool_add_domain’:
cpupool.c:359:9: error: variable ‘n_dom’ set but not used [-Werror=unused-but-set-variable]
cpupool.c: In function ‘cpupool_rm_domain’:
cpupool.c:384:9: error: variable ‘n_dom’ set but not used [-Werror=unused-but-set-variable]
cpupool.c:383:9: error: variable ‘cpupool_id’ set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

make[4]: *** [cpupool.o] Error 1
make[4]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.1.0/xen/common'
make[3]: *** [/tmp/yaourt-tmp-root/aur-xen/src/xen-4.1.0/xen/common/built_in.o] Error 2
make[3]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.1.0/xen/arch/x86'
make[2]: *** [/tmp/yaourt-tmp-root/aur-xen/src/xen-4.1.0/xen/xen] Error 2
make[2]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.1.0/xen'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.1.0/xen'
make: *** [install-xen] Error 2
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build xen.

Anonymous comment on 2011-03-26 08:23

Xen 4.1 has been released !
http://www.xen.org/products/xen_source.html

haagch commented on 2011-02-18 09:39

I think you should use options=(!strip) in the PKGBUILD.
Do these people that don't have this problem have strip in makepkg.conf disabled?

Anonymous comment on 2011-02-07 20:14

Please add a backup line to the PKGBUILD so that xend-config and other files won't be replaced by the package's contents. Thanks.

haagch commented on 2011-01-25 23:33

I have most of multilib installed. What exactly do I need?
(At the time of the comment before I had gcc instead of gcc-multilib, I don't know why it keeps being replaced...)

Now:
/usr/bin/strip: Unable to recognise the format of the input file `./usr/share/xen/qemu/openbios-sparc32'

flavius commented on 2011-01-25 13:45

You also have to make arch multilib: https://wiki.archlinux.org/index.php/Arch64_FAQ#Multilib_Repository_-_Multilib_Project if you are on x86_64

haagch commented on 2011-01-25 09:30

/usr/bin/strip: Unable to recognise the format of the input file `./usr/share/xen/qemu/openbios-ppc'

Anonymous comment on 2011-01-18 08:05

Please add pyxml dependency, because "xm new" requires xmlproc.

M0Rf30 commented on 2011-01-01 22:38

updated patchset.python2 dependency for 64bit fixed.conflict with 2.6.36.2 headers fixed

Anonymous comment on 2010-12-17 09:32

python2 should be in x86_64 depends, not python.

Anonymous comment on 2010-11-12 15:46

Seems to be working fine with 2.6.34-xen-dom0-dev kernel, udev 151-3 and python2.7 patch below.

Anonymous comment on 2010-11-11 15:34

I am having trouble getting xm to work with python2.7. I think this needs this patch: http://www.gossamer-threads.com/lists/xen/devel/182210

M0Rf30 commented on 2010-11-02 22:44

updated,reversioned,removed some unappropriate patches

Anonymous comment on 2010-11-02 14:44

patch: **** Can't open patch file ../xen.patch : No such file or directory
Apparently either that command line is obsolete or xen.patch is missing from package...

Anonymous comment on 2010-10-26 03:28

Looks like i needed to change:

(network-script /bin/true)

to

(network-script network-bridge). Also needed to ensure that the config file for the VM has eth0 as it's bridge instead of xenbr0.

Thanks,
Ryan

Anonymous comment on 2010-10-25 21:16

I'm getting the following error when i attempt to load a VM:

[root@xen ~]# xm create dc.hvm
Using config file "/etc/xen/dc.hvm".
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

I spoke with some people in ##xen and they have indicated that this normally occurs when the network backend isn't working properly. This is a fresh install with only Xen on it. ifconfig shows the following:

http://paste.pocoo.org/show/281452/

Any thoughts?

M0Rf30 commented on 2010-10-23 14:45

a first approach to grub-mkconfig for xen entries

M0Rf30 commented on 2010-10-23 14:21

Please let me know if there are other problems

M0Rf30 commented on 2010-10-23 14:20

Updated to work with python2
Commented xen-initscript.patch

Refutationalist commented on 2010-10-21 20:13

Oh, about that patch: you'll want to add it to the PKGBUILD right after the first python change patch to get it to go cleanly, and you'll need to update the deps, obviously.

Refutationalist commented on 2010-10-21 20:11

Here's an incredibly brute force patch to allow it to build with the recent python changes: http://aur.pastebin.com/DYQCmUHx

I also have some improved init scripts and such-- but like this patch, they're kinda hackish right now.

nicedream commented on 2010-10-21 19:39

Seems to not compile with the recent change from python2 to python3.

nicedream commented on 2010-10-13 02:06

This package builds fine for me on my i686 server, but within a half hour of booting the system is unresponsive. Since the server is remote, I'm not sure if it's just the network that locks up, or the whole kernel. This happens with both the regular and dev dom0 kernels in the AUR.

Magicking commented on 2010-10-02 19:11

I experienced the same problem as robertmarq and resolved it by adding the evtchn module.

Anonymous comment on 2010-09-20 16:52

I can not start xend.
Error: Unable to connect to xend: No such file or directory. Is xend running?

start xenstored..
[root@sistemas sistemas]# xenstored
[root@sistemas sistemas]# FATAL: Failed to open evtchn device: No such file or directory

Refutationalist commented on 2010-09-15 06:46

At least on x86_64, I needed to start xenstored, then xend, then xenconsoled in order to get proper functioning under xen 4.0.1-- this is with the pv-ops git repository, stable branch.

luka12345 commented on 2010-09-02 12:03

i have only one issue; when using vnc i can't start domu.
in log file there is an error:

xen be core: xen be core: can't open gnttab device
can't open gnttab device

luka12345 commented on 2010-09-01 21:55

i found out that error is in xen-initscript.patch - in xend file, i have removed this patch and everything works now just fine :-)
also i can compile and run xen without any patches...

luka12345 commented on 2010-09-01 21:54

hi,

i found out that error is in xen-initscript.patch - in xend file...

i have removed this patch and everything works now just fine...

also i can compile and run xen without any patches...

Anonymous comment on 2010-08-31 20:52

I have to admit that the xen4 package, updated to 4.0.1 works. I will try this package now too.
Morfeo do you recommend to use udev-151 or the most recent one?

M0Rf30 commented on 2010-08-30 14:26

I will investigate..now you can use xen4 PKG

M0Rf30 commented on 2010-08-30 14:25

try the xen4 PKGBUILD

M0Rf30 commented on 2010-08-30 14:25

try the xen4 PKGBUILD

M0Rf30 commented on 2010-08-30 14:25

try the xen4 PKGBUILD

M0Rf30 commented on 2010-08-30 14:25

try the xen4 PKGBUILD

luka12345 commented on 2010-08-30 13:51

I can not start xend :-(, everything worked fine in xen-4.0.0
here is error log from /var/log/xend.log:

http://aur.pastebin.com/UFXhmECC

Can you send me the old xen-4.0.0 pkg build?

Anonymous comment on 2010-08-29 11:32

In order to install lib32-glibc I had to enable to multilib repository ( ' http://www.archlinux.org/news/508/ ' ),
afterwards it compiled successfully on X86_64.

M0Rf30 commented on 2010-08-28 14:48

completely fixed! fixed! fixed! now it should compile at least on i686
I'm waiting for someone to compile on x86_64

M0Rf30 commented on 2010-08-28 14:20

I've updated and fixed many problems...but I don't know how to finalize install-xen...for now it packages only tools and doc..
let me know if there's a solution.
I only know that if I try to compile dist-xen or install-xen without the PKGBUILD it succeedes althought during the makepkg process it miserably fails.

steve1234 commented on 2010-07-02 18:47

Is lib32-glibc-devel still a dependency? Looking at the PKGBUILD for lib32-glibc-devel I see the source get to:

http://www.mirrorservice.org/sites/ftp.archlinux.org/core/os/i686/glibc-2.12-2-i686.pkg.tar.xz

I have package glibc-2.12-2-x86_64.pkg.tar.xz installed. Does this satisify the dependency of lib32-glibc-devel for the AUR package 'xen'?

mortzu commented on 2010-06-24 12:38

this package is now without kernel. so please use kernel26-xen-dom0

Anonymous comment on 2010-04-07 21:32

Xen 4.0 is out