Package Details: xen 4.19.1pre-1

Git Clone URL: https://aur.archlinux.org/xen.git (read-only, click to copy)
Package Base: xen
Description: Open-source type-1 or baremetal hypervisor
Upstream URL: https://xenproject.org/
Keywords: hypervisor virtualization xen
Licenses: GPL2
Submitter: sergej
Maintainer: Refutationalist
Last Packager: Refutationalist
Votes: 185
Popularity: 0.63
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2024-09-20 00:31 (UTC)

Pinned Comments

Refutationalist commented on 2024-05-22 22:08 (UTC) (edited on 2024-05-23 00:07 (UTC) by Refutationalist)

As of now (2024-22-05) Xen with stubdom doesn't build because of a problem in the imported code. Been this way for about two weeks. Anyone else seeing this behavior?

Also, there is a lot of work happening on Xen in my development repo, thanks to @Serus. Check it out at: https://github.com/refutationalist/saur

Latest Comments

« First ‹ Previous 1 .. 91 92 93 94 95 96 97 98 99 100 101 Next › Last »

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