Package Base Details: xen

Git Clone URL: https://aur.archlinux.org/xen.git (read-only, click to copy)
Keywords: hypervisor virtualization xen
Submitter: sergej
Maintainer: Refutationalist
Last Packager: Refutationalist
Votes: 185
Popularity: 0.46
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2024-01-19 23:00 (UTC)

Latest Comments

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 Next › Last »

<deleted-account> commented on 2012-07-15 05:06 (UTC)

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 (UTC)

Hi, This PKGBUILD is out of date it should be updated regardings comments below. Thanks

<deleted-account> commented on 2012-05-24 11:20 (UTC)

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 (UTC)

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 (UTC)

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.

encbladexp commented on 2012-03-31 18:04 (UTC)

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

<deleted-account> commented on 2012-03-25 00:34 (UTC)

Running makepkg -s on a x86_64 does not resolve the python2 dep.

grossws commented on 2012-03-15 00:39 (UTC)

P. S. I'm building it on x86_64 host.

grossws commented on 2012-03-15 00:38 (UTC)

It fails because can't find as86. So bin86 should be added to makedepends.

<deleted-account> commented on 2012-03-14 14:16 (UTC)

Hi, I think you might want to add python2 as a compile-time dependency as well.

fatmike commented on 2012-03-14 08:59 (UTC)

@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 (UTC)

@Subnaut: See https://bbs.archlinux.org/viewtopic.php?id=137415 - Post #2

Citral commented on 2012-03-10 13:54 (UTC)

Try creating guest with xl instead of xm.

<deleted-account> commented on 2012-02-22 02:21 (UTC)

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..

<deleted-account> commented on 2012-02-09 14:33 (UTC)

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 (UTC)

Thanks aaronfitz, I hade exactly that problem and your fix worked!

aaronfitz commented on 2012-01-28 06:09 (UTC)

@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 (UTC)

@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 (UTC)

@aaronfitz: I figured it out, you need to add xsave=1 to the xen commandline.

aaronfitz commented on 2012-01-27 05:14 (UTC)

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 (UTC)

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 01:29 (UTC)

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)

miffe commented on 2012-01-19 19:33 (UTC)

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?

<deleted-account> commented on 2011-12-28 07:35 (UTC)

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 (UTC)

Looks like the package needs 'bin86' in makedepends. (as86 missing)

chenxiaolong commented on 2011-11-18 00:05 (UTC)

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.

d1t2 commented on 2011-10-23 10:42 (UTC)

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

<deleted-account> commented on 2011-10-07 05:41 (UTC)

Sorry for multiple posts. Couldn't sleep - it works! Magic of that patch :)

<deleted-account> commented on 2011-10-07 04:27 (UTC)

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).

<deleted-account> commented on 2011-10-06 13:02 (UTC)

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.

robertfoster commented on 2011-10-06 11:31 (UTC)

please let me know if it works...cause I don't understand your patch format

<deleted-account> commented on 2011-10-06 09:34 (UTC)

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 (UTC)

The package did build for me now (still with gcc-multilib), but namcap throws quite a lot of warnings: http://pastebin.com/cpzetB6J

robertfoster commented on 2011-08-28 01:32 (UTC)

try to use gcc and not gcc-multilib

hollunder commented on 2011-08-27 19:04 (UTC)

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

<deleted-account> commented on 2011-08-24 20:28 (UTC)

building also requires iasl.

robertfoster commented on 2011-08-23 00:21 (UTC)

added ocaml-findlib as makedep

nikin commented on 2011-08-18 00:26 (UTC)

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

<deleted-account> commented on 2011-08-17 08:30 (UTC)

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 (UTC)

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

<deleted-account> commented on 2011-08-15 23:18 (UTC)

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

<deleted-account> commented on 2011-08-15 22:35 (UTC)

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.

<deleted-account> commented on 2011-08-12 14:05 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

what aboutdoing like this ------------------ [ "$CARCH" == "x86_64" ] && depends=(${depends} 'lib32-glibc') ------------------------

bjorn-oivind commented on 2011-08-08 12:08 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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.

Refutationalist commented on 2011-05-14 03:11 (UTC)

Looks like ocaml and ocaml-findlib are a requirement for (at least) building, and lzo2 is necessary for it to run.

robertfoster commented on 2011-04-22 09:39 (UTC)

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

<deleted-account> commented on 2011-04-20 00:01 (UTC)

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.

<deleted-account> commented on 2011-04-18 11:15 (UTC)

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.

<deleted-account> commented on 2011-03-26 08:23 (UTC)

Xen 4.1 has been released ! http://www.xen.org/products/xen_source.html

haagch commented on 2011-02-18 09:39 (UTC)

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?

<deleted-account> commented on 2011-02-07 20:14 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

/usr/bin/strip: Unable to recognise the format of the input file `./usr/share/xen/qemu/openbios-ppc'

<deleted-account> commented on 2011-01-18 08:05 (UTC)

Please add pyxml dependency, because "xm new" requires xmlproc.

robertfoster commented on 2011-01-01 22:38 (UTC)

updated patchset.python2 dependency for 64bit fixed.conflict with 2.6.36.2 headers fixed

<deleted-account> commented on 2010-12-17 09:32 (UTC)

python2 should be in x86_64 depends, not python.

<deleted-account> commented on 2010-11-12 15:46 (UTC)

Seems to be working fine with 2.6.34-xen-dom0-dev kernel, udev 151-3 and python2.7 patch below.

<deleted-account> commented on 2010-11-11 15:34 (UTC)

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

robertfoster commented on 2010-11-02 22:44 (UTC)

updated,reversioned,removed some unappropriate patches

<deleted-account> commented on 2010-11-02 14:44 (UTC)

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...

<deleted-account> commented on 2010-10-26 03:28 (UTC)

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

<deleted-account> commented on 2010-10-25 21:16 (UTC)

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?

robertfoster commented on 2010-10-23 14:45 (UTC)

a first approach to grub-mkconfig for xen entries

robertfoster commented on 2010-10-23 14:21 (UTC)

Please let me know if there are other problems

robertfoster commented on 2010-10-23 14:20 (UTC)

Updated to work with python2 Commented xen-initscript.patch

Refutationalist commented on 2010-10-21 20:13 (UTC)

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 (UTC)

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 (UTC)

Seems to not compile with the recent change from python2 to python3.

Magicking commented on 2010-10-02 19:11 (UTC)

I experienced the same problem as robertmarq and resolved it by adding the evtchn module.

<deleted-account> commented on 2010-09-20 16:52 (UTC)

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 (UTC)

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.

luka commented on 2010-09-02 12:03 (UTC)

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

luka commented on 2010-09-01 21:55 (UTC)

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...

<deleted-account> commented on 2010-08-31 20:52 (UTC)

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?

robertfoster commented on 2010-08-30 14:26 (UTC)

I will investigate..now you can use xen4 PKG

luka commented on 2010-08-30 13:51 (UTC)

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?

<deleted-account> commented on 2010-08-29 11:32 (UTC)

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.

robertfoster commented on 2010-08-28 14:48 (UTC)

completely fixed! fixed! fixed! now it should compile at least on i686 I'm waiting for someone to compile on x86_64

robertfoster commented on 2010-08-28 14:20 (UTC)

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 (UTC)

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'?

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 Next › Last »