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.68
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 .. 3 4 5 6 7 8 9 10 11 12 13 .. 101 Next › Last »

vibrion commented on 2021-04-13 22:01 (UTC)

@juceda must set at top of PKGBUILD

Build Options

_build_stubdom=${build_stubdom:-false} _build_qemu=${build_qemu:-false}

tec14 commented on 2021-03-25 17:16 (UTC) (edited on 2021-03-25 17:28 (UTC) by tec14)

@juceda: how to make the below modification on src/xen-4.14.1/tools/qemu-xen-build/config-host.mak file so that it is taken into account

juceda commented on 2021-02-20 21:48 (UTC)

@Guard - FYI that issue (unable to disambiguate: -no-pie) is caused by a recent binutils package: binutils-2.36-3-x86_64.pkg.tar.zst

If you downgrade it you'll be able to compile again (at least to bypass that point).

the flag is on: src/xen-4.14.1/tools/qemu-xen-build/config-host.mak changing LDFLAGS_NOPIE=-no-pie to LDFLAGS_NOPIE= will also fix the issue.

Guard commented on 2021-02-11 05:11 (UTC) (edited on 2021-02-11 05:12 (UTC) by Guard)

pkgbuild was successful after changing _build_stubdom and _build_qemu from "build_qemu/stubdom:-true" to "build_qemu/stubdom:-false"

Guard commented on 2021-02-11 00:11 (UTC) (edited on 2021-02-11 03:15 (UTC) by Guard)

"ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)"

happens every build, regardless of the source. perhaps I am missing a dependency? it fails to build afterwards.

ska67 commented on 2021-02-07 14:58 (UTC)

SDL2 has the least dependencies when display output is needed for (pv)hvm domUs. I run xen on two Laptops and gpu passthrough is not an option. I patch the PKGBUILD and the built-in qemu myself. I can continue to do that. So for my sake the SDL2 support can be removed.

I think spice support is automatically enabled when the spice and spice-protocol packages are installed before makepkg runs. This probably also applies to GTK, VTE and other configuration switches. This could be an alternative to a toggle in PKGBUILD, but should be documented somewhere.

Thanks for your efforts :)

Refutationalist commented on 2021-02-03 19:23 (UTC)

Hello!

In my personal repo I have an updated version of 4.14.1 with security patches and the changes suggested in the last couple weeks. With the new hook, it will boot recent kernels, but both the most recent linux and linux-lts kernels will not start any virtual machines. I'm trying to narrow down where the problem happens still, but what I know is that 5.4.88 works, and 5.4.94 doesn't. If you want to help me track down the problem, my repo is at https://github.com/refutationalist/saur

And now some future stuff where I need some feedback:

Stubdom: I'm now transitioning to using the package without stubdom support. In the comments, I think I was the only person who needed it. If that continues to be the case, I will begin to phase out stubdom starting with the next Xen release.

SDL2: The number of dependencies goes up significantly if one uses the built-in QEMU support, which is the default as the package in extra does not have xen support in it. Since I run Xen almost entirely on headless machines, I'd like to remove SDL2 support. Unless someone says otherwise, I'll have QEMU configured to not use sdl2, otherwise I'll have to turn it into a toggle.

libvirt, qemu, and getting the package into the repos: I've talked to a couple of TUs who are interested in getting the package into the repos, but not much has actually happened on that score. I could try to become a TU myself, but I do have a lot on my plate and I don't know that I have the brain space to handle that. Would it make more sense for me to just abandon the package and hope a TU picks it up? Some direction from someone who knows the political ins and outs of Arch Linux would be very helpful.

ilstam commented on 2021-01-31 23:18 (UTC)

just a nitpick: in optdepends edk2-ovmf is misspelled

ArthurBorsboom commented on 2021-01-31 11:36 (UTC)

I am using libvirt with Xen.

Unfortunately the [Community] package libvirt does not have Xen support, since it depends on Xen to build and Xen is in the AUR.

https://bugs.archlinux.org/task/64800

Is there any chance to get this package in [Community]?

alaricljs commented on 2021-01-27 20:12 (UTC) (edited on 2021-01-27 20:15 (UTC) by alaricljs)

@refutationalist I've been using a hook to deal with the zstd kernel issue until support is complete.

xen-kernel.hook:

[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = linux

[Action]
Description = Pull ELF kernel to /boot
Depends = linux-headers
When = PostTransaction
Exec = /usr/bin/strip /usr/src/linux/vmlinux -o /boot/vmlinux

« First ‹ Previous 1 .. 3 4 5 6 7 8 9 10 11 12 13 .. 101 Next › Last »