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: 183
Popularity: 0.68
First Submitted: 2009-11-09 11:22
Last Updated: 2021-04-15 09:43

Packages (2)

Pinned Comments

Refutationalist commented on 2021-04-15 09:56

1) 4.15.0-1 adds zstd kernel support, so the hook for that is no longer needed, but I'm not sure if ever made it out of my personal repo.

2) The -no-pie problem in linking is present in 4.15, and there's an included patch for that. It is now the only patch needed to compile cleanly on Arch.

3) As promised, stubdom has moved from building by default to not building by default, as no one has spoken up about using it. If I continue maintaining the package, the plan is to remove it in the next major release.

4) I haven't done anything about the SDL2 deps.

5) Unless a co-maintainer is added, this is likely going to be the last release for a few months as I'm going in for surgery to have a brain tumor removed next month.

Latest Comments

1 2 3 4 5 6 ... Next › Last »

mxca commented on 2021-05-27 14:32

I came across this patch to get Xen building with GCC 11.

I also needed to make a few changes to support a system with split /efi and /boot (using XBOOTLDR). I ended up adding the make arguments BOOT_DIR=/boot EFI_DIR=/boot EFI_MOUNTPOINT=/efi. Technically that BOOT_DIR=/boot is redundant because it's the default, but I actually modified the package to set them as variables (e.g., _boot_dir=${boot_dir:-/boot}) and pass "${_common_make_flags[@]} to each make invocation.

EFI_DIR is where the xen.efi symlink farm gets installed along with the actual EFI image, so setting EFI_DIR=/boot looks weird but is the right thing to do on a SystemD bootctl-powered system using XBOOTLDR: the end result is that I don't need a hook to update the EFI system partition.

I also needed to refactor the symlink cleanup; specifically remove all the symlinks at the end after we've done both the multiboot and the EFI image relocations. Otherwise, if BOOT_DIR and EFI_DIR are the same thing you're gonna have a bad time.

I put my changes on github. Built it in a chroot with multilib-build, gonna go test it now.

Update: Works for me.

ArthurBorsboom commented on 2021-04-15 10:03

Thanks for your efforts. I wish you all the best with your surgery and a fast and painless recovery!

Refutationalist commented on 2021-04-15 09:56

1) 4.15.0-1 adds zstd kernel support, so the hook for that is no longer needed, but I'm not sure if ever made it out of my personal repo.

2) The -no-pie problem in linking is present in 4.15, and there's an included patch for that. It is now the only patch needed to compile cleanly on Arch.

3) As promised, stubdom has moved from building by default to not building by default, as no one has spoken up about using it. If I continue maintaining the package, the plan is to remove it in the next major release.

4) I haven't done anything about the SDL2 deps.

5) Unless a co-maintainer is added, this is likely going to be the last release for a few months as I'm going in for surgery to have a brain tumor removed next month.

vibrion commented on 2021-04-13 22:01

@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

@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

@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

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

"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

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

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

just a nitpick: in optdepends edk2-ovmf is misspelled

ArthurBorsboom commented on 2021-01-31 11:36

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

@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

ArthurBorsboom commented on 2021-01-17 13:04

@Refutationalist, regarding the zstd support, it seems support for Dom0 is in progress.

https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg01060.html

Refutationalist commented on 2021-01-12 21:05

I've tested this 4.14.1 on my older AMD box and my Xeon booting via EFI.

I'm in the middle of purging my need for the stubdom stuff, so I'm interested in hearing if people are using that at the moment. Also might have a co-maintainer shortly. Looking for input on how to handle zstd kernels.

Refutationalist commented on 2020-12-22 11:29

4.14.1 has been out, and I'm working through it at the moment. Should hit my github repo in the next few days, and assuming it boots on my intel and AMD test systems, here shortly after.

Refutationalist commented on 2020-11-24 18:20

@alaricljs -- the only real change between in the recent update was the inclusion of security patches from Xen. Might try pulling some of those out and see if that takes care of it for you. I'll see what I can test from here, but I'm not running any Windows VMs at the moment.

There was a patch update this morning, but I haven't looked at it closely yet. If it applies, there'll be a -5 soon.

alaricljs commented on 2020-11-22 22:46

@refutationalist - the -04 rev causes my Win VM to hang on boot (just the circular dot thing frozen on screen). The error in the vm log is:
qemu-system-i386: relocate_memory 4096 pages from GFN 40f000 to GFN f1000 failed: Bad address The version I was using prior to update was 4.14.0-1, I've rolled back.

ska67 commented on 2020-11-22 14:47

Please replace the dependency sdl with sdl2 in your next version. SDL v1.2 is outdated and, as far as I can tell, is no longer supported by xen-4.14. Additionally libjpeg-turbo will be needed.

Refutationalist commented on 2020-11-21 21:23

For the record, I almost universally use linux-lts on my servers, and that continues to work.

Also, when you update EFI, remember to copy the EFI kernel to /boot. That's not for you, that's for me, since I just spent an hour forgetting that.

EDIT: I will add a reminder in the next update. Maybe consider a hook, see how the kernels do it.

Refutationalist commented on 2020-11-11 00:40

Updated to 4.14.0-4, added security patches, cmake fixes from cdchapman for stubdom building.

eduncan911 commented on 2020-11-09 16:28

@alaricljs: that info would be better documented in the Wiki's Discussion page (or an update to the wiki if you have a procedure tested). Comments get lost into oblivion.

alaricljs commented on 2020-11-09 16:11

A partial (dom0 & PV) solution to the zstd compression issue that sticks to current kernels: https://gist.github.com/alaricljs/757d4b452335b187d7dff1b7e2c5808e

A Pacman hook that grabs the uncompressed kernel and puts it in /boot. Works on dom0 and PV guests (that's all that was tested, perhaps others work too).

kapcom01 commented on 2020-11-06 09:04

Thanks to the previous comments I installed linux-lts and then sudo grub-mkconfig -o /boot/grub/grub.cfg it worked :) A new entry appeared on GRUB menu and now I booted to dom0 successfully.

manueljben commented on 2020-10-26 15:07

Thank you for your tip @g8sqh!!!

I've posted this issue on forums some days ago (https://bbs.archlinux.org/viewtopic.php?id=260107), following the guidelines not to post questions etc here), but nobody answered.. ¬_¬

g8sqh commented on 2020-10-23 11:00

Please also note that Xen (4.14.0) no longer works with the standard Arch kernel (at least as dom-0)

Arch (at 5.9.1) compresses using zstd (CONFIG_KERNEL_ZSTD=1), and the ELF-reading code in Xen has a decompressor for xz (in xen/common/xz), but nothing for zstd

Message is elf-init: not an ELF binary and a (xen) kernel panic.

Until either Xen gains zstd, or Arch provides a kernel package using xz, you need an older kernel from the archive, or to build from source with CONFIG_KERNEL_XZ=1

ccook13 commented on 2020-09-29 17:28

Gotcha @eduncan911. Link: https://bbs.archlinux.org/viewtopic.php?id=259428

eduncan911 commented on 2020-09-27 23:24

Everyone, please take this to the forums. Subscriptions to package notifications are just that: notifications about package updates, breaks, and news.

It's not a discussion, debugging, nor How To forum.

ccook13 commented on 2020-09-27 18:27

@skyzh Sorry for the flurry of comments; How do you actually apply that patch? I've done makepkg -o to just get the source files, I haven't done much manual makepkg work before.

ccook13 commented on 2020-09-27 06:53

@skyzh Got the same issue with GCC9 (can provide log snippets if need be), perhaps the patch you found is the only remedy at the moment.

ccook13 commented on 2020-09-27 06:01

@skyzh I'm getting the same problem, I'm going to attempt building with gcc9, which is in the community repo, then gcc8 if it still fails. I got nothing else better to do right now.

skyzh commented on 2020-09-27 02:45

@Refutationalist It seems to be an issue related to gcc10. Here's the version info of my compiler.

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/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++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)

I built Xen with makepkg -si.

Refutationalist commented on 2020-09-27 02:42

@skyzh: How were you building when you triggered that message? I just built Xen on a brand new install and didn't manage to see that in the captured build output.

@ska67: For booting, I think the best way forward would be to update the wiki page with specific bootloader instructions, and then point to the wiki on install. We recently pulled out GRUB specific code, the direct EFI boot needs some changes that would make it longer than I think is useful in an install message, and there a lot of different boot methods being discussed in the comments here.

As far as QEMU goes, is there anything specific that needs to be added for Xen functionality? If we're just adding stuff to QEMU to use QEMU separate from Xen, I would not build QEMU inside this package, but modify the stock Arch qemu package to include Xen support.

Refutationalist commented on 2020-09-14 04:52

Just a note that I see the recent comments, but I'm not in a position to work on them at the moment. I'll get to them ASAP.

skyzh commented on 2020-09-14 04:49

Thanks for this AUR package! I tried to install this on latest archlinux, and the compiler reports

multiple definition of 'tpm version'

in several files.

I found that this can be solved with this patch from GitHub https://github.com/patchew-project/xen/commit/ac9d413015d3bcf1e8f31cda764590b3ee949bc1.patch

Hope this could help other users when using this AUR package.

ska67 commented on 2020-09-12 10:51

Your PKGBUILD uses "build_qemu" as build option to enable or disable the integrated Xen version of upstream Qemu. The Xen configuration allows additional configuration options for building this upstream Qemu with --with-extra-qemuu-configure-args[="--ARG1 ..."]. Please allow such additional configuration options for "build_qemu", besides the options true and false.

I am using systemd-boot, after build and install I have to copy /usr/lib/efi/xen.efi and /etc/xen/efi-xen.cfg as xen.cfg to my esp (boot) partition. The names of xen.efi and xen.cfg must be equal. It would be great if a hint would be displayed during the installation on uefi systems using systemd-boot or efistub booting.

@jac299792458 Use "console=vga vga=text-80x25,keep" on the hypervisor command line and "console=hvc0 earlyprintk=xen" on the kernel command line if you do not have a serial console for hypervisor output.

jac299792458 commented on 2020-09-02 19:07

I was able to get this to build and install successfully. However, I'm having the damnedest time getting it to boot on my Dell Precision 5550 laptop. I've tried using grub-xen-git (which boot regular Arch, same kernel, just fine), and I've tried directly booting Xen from UEFI.

In both cases, I see the Xen messages scroll by, the last one mentions relinquishing the VGA port, it blanks the screen and ... nothing. It just sits there.

I've removed and / or tweak the intel-ucode scanning with no change in behavior. Is there anything else I should try next to get some more actionable info? I've also added 'earlyprintk=xen' to the kernel cmdline for both via Grub->Xen and UEFI -> Xen ...

ephreal commented on 2020-08-31 18:39

I've been having trouble getting this to compile. Is it possible that there's a missing dependency? Here's where the make errors out.


make[7]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc'
make[6]: *** [Makefile:582: all-recursive] Error 1
make[6]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc'
make[5]: *** [Makefile:574: all-recursive] Error 1
make[5]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom/newlib-x86_64/x86_64-xen-elf/newlib'
make[4]: *** [Makefile:402: all] Error 2
make[4]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom/newlib-x86_64/x86_64-xen-elf/newlib'
make[3]: *** [Makefile:8613: all-target-newlib] Error 2
make[3]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom/newlib-x86_64'
make[2]: *** [Makefile:697: all] Error 2
make[2]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom/newlib-x86_64'
make[1]: *** [Makefile:100: cross-root-x86_64/x86_64-xen-elf/lib/libc.a] Error 2
make[1]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom'
make: *** [Makefile:138: install-stubdom] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

cman commented on 2020-08-04 19:58

@Refutationalist If you have it running, go ahead and do a package release for 4.14.0. Sorry I wasn't able to submit the GRUB bits before heading to the mountains for a family reunion this week. If you're game, we can do another package release with the updated GRUB once I get back to civilization.

Refutationalist commented on 2020-08-04 05:32

I've got a 4.14.0-0 on my github that seems to be running well on my test machines, so if those grub changes are good to go, I can push to AUR.

cman commented on 2020-07-29 22:40

@Reutationalist That's great and Github will work just fine. I'm in process with some other projects, but I will try to get those Grub changes to you by the end of the week.

Refutationalist commented on 2020-07-29 22:11

@cman -- Yeah, the changes turned out to be pretty trivial and I've already got it compiling, will start testing shortly. I could use those GRUB changes as I'm GRUB-avoidant. If github is good, I've been using my PKGBUILD repo as a staging area, so you can get me the changes there, otherwise we'll figure it out.

Repo is: https://github.com/Refutationalist/saur

cman commented on 2020-07-29 21:51

Hi @Refutationalist, thanks for the great package. I have compiled this package with 4.14.0, and can confirm that most, but not all, of the gcc patches are no longer needed. I've also rebased the grub script on what is in the latest Archlinux package, plus added support to the script for cpu microcode updates and xsm, if present.

I, too, am not too conversant with aur, so I don't know whether a standard way exists to do that (other than with git, of course), but I'm happy to contribute patchsets if you would like if you tell me how you want them.

Refutationalist commented on 2020-07-29 19:24

@linuxninja - Yeah, my package is still requiring qemu-xen from my personal repo, something that I'll be fixing in the next update.

I'm also looking at 4.14.0, which is not compiling but looks to have some of the same problems as 4.13.1 did. I'll try to have something ASAP, depending on complexity and my workload.

linuxninja commented on 2020-07-29 06:44

I was able to build with the changes to the source that I noted, however, I am unable to start a HVM VM with the new build options in this PKGBUILD. I had to revert to the old PKGBUILD and go back to Xen 4.13.0.

linuxninja commented on 2020-07-29 03:08

source = https://src.fedoraproject.org/rpms/xen/raw/master/f/xen.gcc10.fixes.patch https://src.fedoraproject.org/rpms/xen/raw/master/f/xen.ocaml.4.10.patch

Needs to be changed to

source = https://src.fedoraproject.org/rpms/xen/raw/f32/f/xen.gcc10.fixes.patch https://src.fedoraproject.org/rpms/xen/raw/f32/f/xen.ocaml.4.10.patch

in the PKGBUILD. The f32 tag reflects the files the PKGBUILD has been using up to this point. The Master branch has moved on to Xen 4.14.0 and has removed the ocaml patch and the gcc10 patch is no longer the same file.

alaricljs commented on 2020-07-21 21:14

Ok, so it turns out I'm actually blind. Removing --with-system-qemu from the build function does the deed. Makes me think there should be an optdepends or depends on qemu if you're going that route so that it's slightly more obvious.

alaricljs commented on 2020-07-21 16:43

So how do I get a functional HVM with this release? (4.13.1-4) There's no /usr/lib/xen/bin/qemu-dm but I don't see anything obvious in the PKGBUILD as to why.

Refutationalist commented on 2020-07-20 18:55

WANTED: Maintainer or co-maintainer.

I've written a lot of PKGBUILDs for my own purposes, but I'm not that conversant with AUR itself other than using it. I'm also going to be hip deep in work over the next few months and might miss stuff.

Refutationalist commented on 2020-07-20 18:49

Okay, I've added the disable flag for qemut, and at least allowed the package to disable stubdom if people don't want it. I've also split out the docs package, as before. This package is currently at parity with what's in my git.

Next, I'd like to take a closer look at qemu before I willy-nilly push qemu-xen to AUR.

Refutationalist commented on 2020-07-10 05:16

@JohnTh:

The minimal-components builds were never useful to me without modification, which is another reason why my personal repo is the way it is. But my build wasn't going to be on AUR, so I suppose I should revisit that. I invariably need stubdom, so I pulled out the optional check. Other stuff I can probably get rid of, qemut in particular.

I'm not familiar with what the community decisions were. I can review the comments, but that wasn't my initial aim and I took over the package as I seemed to have inadvertently caused a problem. Would it make more sense if you or someone else took over the package? I'm open to that.

Otherwise, I'm going to look into fixing what I have outstanding and updating the package sometime next week.

eduncan911 commented on 2020-07-01 10:57

@JohnTh qemu requires the Xen headers to compile Xen support, so unless you can get this into an arch repository, it will be unlikely our qemu maintainers will want to build the Xen tools themselves.

I would prefer such headers/compilation to be a separate package, so to keep this one lean. Much like the kernel headers are available in an addition package.

JohnTh commented on 2020-06-30 22:46

It is much easier to support a minimal-components build:

Do we need?: - qemut (--disable-qemu-traditional) https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=configure;hb=staging - stubdom (--disable-stubdom) https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=configure;hb=staging - ipxe (only used with qemut rombios / with-system-ipxe exists, but only aur ipxe package) https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/firmware/Makefile;h=809a5fd0255e19b15abda6daf891ed1f5e63e9ad;hb=staging

qemu requires the Xen headers to compile Xen support, so unless you can get this into an arch repository, it will be unlikely our qemu maintainers will want to build the Xen tools themselves.

Most of these have been covered deeper in these comments: https://aur.archlinux.org/pkgbase/xen/?O=0&PP=100

My minimal Xen staging tee build seems to be compiling fine without any extra patches, but it is way too messy to use: https://gitlab.com/archlinux-packages-johnth/xen/-/blob/xen-git/PKGBUILD

Thanks FFY00 and Ref.

Refutationalist commented on 2020-06-30 21:07

Thank you for your work, FFY00.

I'm currently out in the woods with limited internet. I'll be back sometime next week, at which point I'll clean up outstanding changes in my repo and push it to AUR. I didn't care about the docs package, but I can re-add that.

I'll also talk to the QEMU maintainers about adding the configure arg for Xen to QEMU, and seeing what they're doing upstream about GCC and python changes. I'll also likely push my PVH kernel to AUR.

Refutationalist commented on 2020-06-30 01:51

@FFY00: The package I'm working on is very much based on your work and is intended as an interim solution while you are doing things properly. I tried to make that clear in my notes. If I have given any other impression, it is not intended and I apologize.

I had a personal itch to scratch and I shared my work. I wasn't figuring on much of anything beyond that, so the formatting changes didn't really matter to me very much. You're welcome to use what I've done or dismiss it entirely.

FFY00 commented on 2020-06-28 00:05

There were several things that blocked me from updating the package, you should be able to find the discussion below. If you think you are able to do it package the new version properly, please show me a PKGBUILD and I'll disown.

sl4mmy commented on 2020-06-22 15:13

@Refutationalist Unfortunately, it's difficult to diff your changes against this PKGBUILD because of all the formatting changes. Do you plan on rebasing your changes on top of this pkg, or do you consider your work to be a hard fork at this point?

Here is the minimal diff I came up with on top of this PKGBUILD to get 4.13.1 building with latest GCC (& drop the python2 dep): https://github.com/sl4mmy/docker-aur-xen/blob/master/aur-xen_PKGBUILD.patch. The two patches for GCC 10 compile fixes can be found here: https://github.com/sl4mmy/docker-aur-xen/blob/master/gcc-10-fixes.patch, and here: https://github.com/sl4mmy/docker-aur-xen/blob/master/gcc-10-ipxe-fixes.patch.

It would be great if we could get this pkg updated to 4.13.1, including all of your additional improvements (stubdom, rundir, firmware hooks, etc.).

Refutationalist commented on 2020-05-24 21:37

@ntegan: that's good to hear. I'll probably want to look at changing the GRUB scripts then to look for xen.gz instead of a versioned file.

My justification is that I use either syslinux or direct EFI boot, and having to change my settings on every revision is suboptimal. Also, since other kernels aren't versioned in the repos, it seemed a bit more Arch-like to me.

In the meantime, since I first posted I've made a couple of bugfixes. I moved ipxe out of _stubdom_sources as it's not for stubdom, set rundir, and then added a hook to extract firmware from intel-ucode so xen EFI can use it. I'm working on an AMD hook.

ntegan commented on 2020-05-24 21:03

Thanks for the updated PKGBUILD, @Refutationalist.

Only thing I had to change for GRUB to generate the menu entry was to move my /boot/xen.gz to /boot/xen-4.13.1.gz, to match what the grub menu entry generator was looking for.

linuxninja commented on 2020-05-21 15:58

I found that the gcc upgrade to 10 broke my compile, too. The only reason I needed to compile is that nettle upgraded and requires xen to be recompiled, but I could only get xen 4.13.0 to compile, not 4.13.1. I downgraded gcc back to the last version of 9 and was able to recompile for the newer version of nettle.

I'm still on kernel 5.5.13-arch2 as it was the latest I could get HVM networking to work (I run OPNSense as a HVM).

My server motherboard doesn't have UEFI, so I'm only doing BIOS boot with Grub2.

Thanks for the repo. I will certainly check it out!

Refutationalist commented on 2020-05-21 05:59

Oh, also, I haven't tested the grub bits at all since, as I don't use it.

Refutationalist commented on 2020-05-21 05:51

Most recent upgrade of one of my dom0s broke this package for me. Also, recompiling from this package or any other PKGBUILD failed under GCC 10.1. I decided to look into it as I needed this machine up and running.

While I was looking for solutions, I noticed that there was a tarball for 4.13.1 available. I found some patches for GCC 10 via Fedora, but there were other simple changes needed for 10.1. It was trial and error, "make it go" hacking rather than anything robust, but it does compile and run.

It's a kitbash of a couple PKGBUILDs with some changes to simplify things. It's available here: https://github.com/refutationalist/saur/tree/master/xen

I've tested it on exactly one system: the one I needed to run. It's successfully booted Arch in PV and OpenBSD in HVM. Haven't tested PVH yet, but that's next. At this point, I thought more eyes were better.

Elsewhere in the repo is a version of qemu from the repos that has been modified to include xen, if that's needed.

linuxninja commented on 2020-05-06 13:11

I've been testing different kernels with dom0 under Xen. I found that kernel 5.6.0 does not work, but 5.5.13-arch2-1 does. I will be looking through the other kernel versions and comparing the kernel compile configs to determine if something changed.

Kernel 5.5.13-arch2-a as a dom0 under Xen 4.13.0 is working, so far.

linuxninja commented on 2020-05-06 12:07

No problem getting Xen 4.13.0 compiled and running. Had to change one configure option...

linuxninja commented on 2020-05-05 16:35

Any updates on getting the version moved up? This package is now a couple of versions behind upstream... current Xen version is 4.13.0

I was able to get 4.12.2 to build without issue.

linuxninja commented on 2020-05-05 15:37

Upgraded to the latest kernel, 5.6.10, and it broke networking for Xen HVM (opnsense). Downgraded the kernel back to 5.5.8 and things work, again. Not sure which kernel version is the last one that works since I haven't upgraded each release.

CyrIng commented on 2020-04-12 20:29

Just failed to build like that:

makepkg -cCsfir
==> Making package: xen 4.12.1-1 (Sun 12 Apr 2020 10:23:19 PM CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Installing missing dependencies...
resolving dependencies...
looking for conflicting packages...

...

==> Retrieving sources...
  -> Found xen-4.12.1.tar.gz
  -> Found xen-4.12.1.tar.gz.sig
  -> Found ipxe-git.tar.gz
  -> Found grub-mkconfig-helper
  -> Found efi-xen.cfg
  -> Found grub.conf
  -> Found xen.conf
  -> Found tmpfiles.conf
==> Validating source files with sha256sums...
    xen-4.12.1.tar.gz ... Passed
    xen-4.12.1.tar.gz.sig ... Skipped
    ipxe-git.tar.gz ... Passed
    grub-mkconfig-helper ... Passed
    efi-xen.cfg ... Passed
    grub.conf ... Passed
    xen.conf ... Passed
    tmpfiles.conf ... Passed
==> Verifying source file signatures with gpg...
    xen-4.12.1.tar.gz ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Extracting xen-4.12.1.tar.gz with bsdtar
==> Starting prepare()...
  -> Copying downloaded files...
  -> Applying XSA patches...
  -> Applying tools patches (qemu-xen-traditional)...
  -> Applying tools patches (qemu-xen)...
  -> Applying misc compile fixes...
  -> Fixing installation paths...
==> Sources are ready.
==> Removing installed dependencies...
checking dependencies...
:: brltty optionally requires ocaml: OCaml support
:: graphviz optionally requires ocaml: ocaml bindings

...

 CC       xentoollog_stubs.o
xentoollog_stubs.c: In function 'stub_xtl_ocaml_vmessage':
xentoollog_stubs.c:93:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
   93 |  value *func = caml_named_value(xtl->vmessage_cb) ;
      |                ^~~~~~~~~~~~~~~~
xentoollog_stubs.c: In function 'stub_xtl_ocaml_progress':
xentoollog_stubs.c:123:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
  123 |  value *func = caml_named_value(xtl->progress_cb) ;
      |                ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
...
==> ERROR: A failure occurred in build().
    Aborting...
...

JohnTh commented on 2020-04-04 23:08

Not sure if we not need to install the xen /boot/xen-$version.config, we do not have a Arch linux /boot/config-vmlinuz, which is where one GRUB 20_linux_xen issue comes from: GRUB upstream bug: 20_linux_xen does not work if no kernel config file

xen-$version.efi may still be wanted by some, and GRUB should not add this as a multiboot2 option: GRUB upstream bug: 20_linux_xen also creates garbage entries for xenconfig and xenefi

FFY00 commented on 2020-04-04 22:20

Xen installs the /usr/lib/modules-load.d/xen.conf file. It also contains (historic) module names that do not exist in our distribution. systemd-modules-load.service will exit with failure for these nonexistant modules, but boot does continue. see:pacman -Ql linux | grep -E 'xen-' https://aur.archlinux.org/pkgbase/xen/?O=0&PP=100#comment-622244

Ah, thanks.

My second GRUB patch null config filename we could workaround by installing: /boot/config-${linux pkgbase} with CONFIG_XEN_DOM0=y in a pacman hook? But this is only appropriate to booting Xen with GRUB on Arch. I will open bug upstream and pursue it there as well.

Thanks! Please post a link when you do :)

JohnTh commented on 2020-04-04 19:20

Hey FF,

Great to see progress.

modules-load.d/xen.conf

Xen installs the /usr/lib/modules-load.d/xen.conf file. It also contains (historic) module names that do not exist in our distribution. systemd-modules-load.service will exit with failure for these nonexistant modules, but boot does continue. see:pacman -Ql linux | grep -E 'xen-' https://aur.archlinux.org/pkgbase/xen/?O=0&PP=100#comment-622244

GRUB helper fixes upstream

Yes, will try for GRUB helper upstream changes.

Should not need my first GRUB patch -vmlinuz-*, +vmlinuz anymore, as it looks like mkinitcpio installs kernel as vmlinuz-${pkgbase} now I use dracut, so I cannot check this on system. https://git.archlinux.org/mkinitcpio.git/tree/libalpm/scripts/mkinitcpio-install

My second GRUB patch null config filename we could workaround by installing: /boot/config-${linux pkgbase} with CONFIG_XEN_DOM0=y in a pacman hook? But this is only appropriate to booting Xen with GRUB on Arch I will open bug upstream and pursue it there as well.

Cheers

FFY00 commented on 2020-04-04 17:09

I think we should work on fixing the issue in the upstream (so, grub) and backport the patch to the grub package. Do you want to do it? Since you wrote the patches.

The two last patches that is. For the first we should open a bug report for grub package.

FFY00 commented on 2020-04-04 17:08

Hey, sorry for the delay catching up.

ovmf typo in your PKGBUILD optdepends and Xen configure option Package has /etc/init.d/ files

Fixed (locally).

Maybe some sort of install message about: - booting Xen & enabling services? (Xen gets booted before linux dom0) - fixing dom0 memory in the bootloader Xen hypervisor config

Will add before moving to the repos.

Worth cleanup of usr/lib/modules-load.d/xen.conf to avoid modules load errors: I used this in prepare(). find tools -iname 'configure*' -exec sed -i -E -e '/^LINUX_BACKEND_MODULES="$/,/^"$/{/"/b;/^xen-/!d;s/scsibk/scsiback/;};' {} \;

Can you explain exactly what is the issue here?

GRUB helper for loading the Xen dom0: It might be better to fix the Arch grub package with a patch so that 20_linux_xen works for arch kernel? My old changes linked. Need retesting. - vmlinuz- - don't fail on no /boot/config file - ignore xen files grub cannot boot

I think we should work on fixing the issue in the upstream (so, grub) and backport the patch to the grub package.

Do you want to do it? Since you wrote the patches.

JohnTh commented on 2020-03-10 11:15

Hey FF,

Have not yet had a chance to install and test, but looking over it again:

Cheers

FFY00 commented on 2020-03-10 08:59

I think I fixed everything in the PKGBUILD[1]. Both the updated xen package and a qemu package built with --enable-xen are available in my repo[2]. Could you guys please try it and let me know if there are still are any issues?

Regarding the bootloader, the pvgrub helper is packaged but it is broken. This is an upstream issue, I am going to contact them. Basically, in Python 3.8 the descriptor flags for native modules are checked when the module is imported, as opposed to when a certain method is called. This causes the xen.lowlevel.xc to fail to import. This should be a quick fix from the upstream, I had a look but couldn't find the culprit (the python error message could be a little more verbose :P).

Also, if you want UEFI support you will need the ovfm package from [testing].

[1] https://paste.xinu.at/mbZ/ [2] https://pkgbuild.com/~ffy00/repo/

JohnTh commented on 2020-03-08 07:56

Hi FF, With my own built and installed Xen git master:

The OVMF package in Arch [testing] now includes OVMF.fd, and that boots for me. I tested a boot to EFI BIOS & linux had populated /sys/firmware/efi/efivars/

Tested with: domU.cfg options

bios = "ovmf"
bios_path_override = "/usr/share/ovmf/x64/OVMF.fd"

I cannot use the current Arch system QEMU:

tail /var/log/xen/qemu-dm-*.log
qemu-system-x86_64: -xen-domid 11: Option not supported for this target

Tested with: domU.cfg options

device_model_version = "qemu-xen"
device_model_override = "/usr/bin/qemu-system-x86_64"

To use Arch system QEMU would require some changes in the Arch qemu package. At least makedep xen for the header files, and compiled with --enable-xen, and possibly --enable-xen-pci-passthrough Then check qemu still functions without the xen headers, or split these headers from the xen package and depend on them in qemu? https://packages.debian.org/sid/amd64/libxen-dev/filelist

If you want to move this packaging planning somewhere else, let us know.

Cheers

tony_42 commented on 2020-03-06 11:04

Hi FFY00,

Other things that could be improved in your PKGBUILD, you can use Arch Linux's SeaBIOS, with:

./configure --with-system-seabios=/usr/share/qemu/bios-256k.bin

For backup=(), this is probably the list of configuration file:

etc/default/xencommons
etc/default/xendomains
etc/xen/cpupool
etc/xen/xl.conf
etc/xen/scripts/*

Cheers.

FrostbittenKing commented on 2020-03-05 21:07

It almost builds. It builds, but then fails when packaging here: mv "${pkgdir}/usr/lib64/efi/xen".efi "${pkgdir}/boot". The folder .../lib64 doesn't exist, and xen.efi isn't built. I don't have any idea why. After all the build works (after using the patched PKGBUILD). Can somebody explain why the xen.efi binaries aren't built? Tried to understand the makefiles, ..I guess some precondition isn't met but I have no fing idea.

invisiblek commented on 2020-03-05 19:43

It builds fine (is valgrind necessary? quite a large dependency).

Got this when trying to install: https://gist.github.com/invisiblek/01920f2b63f37e7d0d317ae549c9de00 It's due to an empty /usr/lib64 dir in the package which is residual from the mv of efi in package() function. Add an rmdir "$pkgdir"/usr/lib64/ after the mv on line 97 and it installs fine.

Your PKGBUILD does not include a grub helper like this one does, so creating a grub config would have to be done manually or something after installation. I'm not sure the best way to handle that situation (for an official build you probably need to handle more than just grub as the user's bootloader?).

JohnTh commented on 2020-03-05 19:41

FF,

I have not yet tried your package, just had a quick look over it.

It has been years since I tried to use Arch system qemu and ovmf (typo in your optdepends), and it would be delightful to find these just worked now...

When I did:

It would be great to see this tested and packaged. Cheers

FFY00 commented on 2020-03-05 17:47

Hey guys. I have been working on a PKGBUILD but haven't been able to test it.

https://paste.xinu.at/6PR/

Can anyone see if there are any issues? If everything is fine we can go ahead and move it to the official repos.

invisiblek commented on 2020-03-04 04:55

This commit fixes the current build issue: http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=368375d7360a38c27de8e0276498bdd29e9e8a03

Sadly that commit hasn't been backported to the 4.12 branch, so it has to be patched during makepkg. I suppose you could also downgrade your ocaml to something before 4.09 and things would work again too...but that seems foolish.

Possible solutions here:

  1. Fix up the current 4.12.1 build like so: https://github.com/invisiblek/xen-aur/commits/4.12.1-2

  2. Step one plus update to 4.12.2 while we're at it: https://github.com/invisiblek/xen-aur/commits/4.12.2-1

  3. Move to 4.13.0: https://github.com/invisiblek/xen-aur/commits/4.13.0-1

All three do require this minor patch to remove a now deprecated flag in qemu: https://github.com/invisiblek/xen-aur/commit/168fbdaa33265c4902ebfd5e8def892b0c2c14ca

I'll be testing with my 4.13.0-1 branch for now.

I see FFY00 mentioned official repos a couple months ago, unsure the status on that as of yet. Maybe I'll ping them on irc one of these days and see where that whole thing is at.

For now at least we can have working builds again :)

ColonelThirtyTwo commented on 2020-03-04 01:27

Getting the same error as @schweratlet, installing with pikaur.

schweratlet commented on 2020-02-17 22:35

@mbroemme I'm getting the same error when trying to install (installing with yay -S xen. though I hope it doesn't make a difference.

make -C xentoollog install make[8]: Entering directory '/home/shogoro/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/xentoollog' python2 genlevels.py _xtl_levels.mli.in _xtl_levels.ml.in _xtl_levels.inc MLDEP MLC xentoollog.cmo MLA xentoollog.cma CC xentoollog_stubs.o xentoollog_stubs.c: In function 'stub_xtl_ocaml_vmessage': xentoollog_stubs.c:93:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 93 | value func = caml_named_value(xtl->vmessage_cb) ; | ^~~~~~~~~~~~~~~~ xentoollog_stubs.c: In function 'stub_xtl_ocaml_progress': xentoollog_stubs.c:123:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 123 | value func = caml_named_value(xtl->progress_cb) ; | ^~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors )

It leaves a whole bunch of directories and then.

make[1]: [Makefile:74: install] Error 2 make[1]: Leaving directory '/home/shogoro/.cache/yay/xen/src/xen-4.12.1/tools' make: [Makefile:127: install-tools] Error 2 ==> ERROR: A failure occurred in build(). Aborting... Error making: xen

Is this in any way my fault? Any advice? I have installed Xen successfully before, more specifically twice 4-5 months ago both on a fresh install. This is the first time I'm encountering such an error. I've tried it several times.

eduncan911 commented on 2019-12-20 11:10

@FFY00 oh please do!

In regards to CIS, this is the only package remaining that we use outside of the official repos.

FFY00 commented on 2019-12-20 00:18

Hey, I want to move this to the official repos. Are you ok with that?

sl4mmy commented on 2019-12-19 15:26

@mbroemme - do you plan on dropping the python2 dependency in favor of python? Also, would you be willing to consider switching the brltty dependency to the brltty-minimal available in AUR?

Thanks in advance!

mbroemme commented on 2019-12-18 13:12

4.13.0 is available, will built and merge all changes requested in the comments in the next few days.

ArthurBorsboom commented on 2019-12-14 15:21

I have spent many hours the last days trying to get a VM running with UEFI (ovmf), but Xen keeps crashing (visible by "xl dmesg").

It is related to the used Arch ovmf package in combination with the Xen configure parameter in PKGBUILD

--with-system-ovmf=/usr/share/ovmf/x64/OVMF_CODE.fd

After removing this parameter, Xen uses its 'native' ovmf binary provided by

/usr/lib/xen/boot/ovmf.bin

and not the one from the arch ovmf package provided by

/usr/share/ovmf/x64/OVMF_CODE.fd /usr/share/ovmf/x64/OVMF_VARS.fd

Would you mind to either (for now) remove the ovmf configure parameter and/or solve the cause of the crashing Xen with the Arch ovmf package?

linuxninja commented on 2019-11-21 19:59

I ran into the same libiscsi.so.8 problem. Re-compiling Xen and re-installing resolved the issue.

geh commented on 2019-11-21 15:03

Hi sometroubles with xen when compile the package see below make[4]: Leaving directory '/tmp/trizen-geh/xen/src/xen-4.12.1/tools/ocaml' make[3]: [/tmp/trizen-geh/xen/src/xen-4.12.1/tools/../tools/Rules.mk:251: subdir-install-ocaml] Error 2 make[3]: Leaving directory '/tmp/trizen-geh/xen/src/xen-4.12.1/tools' make[2]: [/tmp/trizen-geh/xen/src/xen-4.12.1/tools/../tools/Rules.mk:246: subdirs-install] Error 2 make[2]: Leaving directory '/tmp/trizen-geh/xen/src/xen-4.12.1/tools' make[1]: [Makefile:74: install] Error 2 make[1]: Leaving directory '/tmp/trizen-geh/xen/src/xen-4.12.1/tools' make: [Makefile:127: install-tools] Error 2 ==> ERREUR : Une erreur s’est produite dans build(). Abandon… :: Unable to build xen - makepkg exited with code: 4

alaricljs commented on 2019-11-15 18:56

Post upgrade, xen cannot start Windows HVM since libiscsi got upgraded. Can you make that dependency build-time version specific?

[2019-11-15T12:09:35-0500] [ALPM] upgraded libiscsi (1.18.0-1 -> 1.19.0-1)

/usr/lib/libiscsi.so.9

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

cdwijs commented on 2019-10-16 08:28

I had to add this line to the PKGBUILD file:

Compile fixes.
  • sed 's/CFLAGS += -fPIC -Werror -I$(shell ocamlc -where)/CFLAGS += -fPIC -I$(shell ocamlc -where)/' -i tools/ocaml/common.make

Details are here: https://bbs.archlinux.org/viewtopic.php?id=249954

xer01ne commented on 2019-10-14 15:32

I am getting this error when trying to compile:

make[8]: Entering directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/mmap'
 MLDEP    
 MLI      xenmmap.cmi
 MLC      xenmmap.cmo
 MLA      xenmmap.cma
 CC       xenmmap_stubs.o
 MKLIB    libxenmmap_stubs.a
 MLOPT    xenmmap.cmx
 MLA      xenmmap.cmxa
sed 's/@VERSION@/4.1/g' < META.in >META.new && mv -f META.new META
mkdir -p /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml
ocamlfind remove -destdir /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml xenmmap
ocamlfind: [WARNING] No such file: /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/META
ocamlfind install -destdir /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml -ldconf ignore xenmmap META xenmmap.cmi xenmmap.cma xenmmap.cmxa *.a *.so *.cmx
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/xenmmap.cmx
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/dllxenmmap_stubs.so
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/xenmmap.a
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/libxenmmap_stubs.a
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/xenmmap.cmxa
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/xenmmap.cma
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/xenmmap.cmi
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/META
make[8]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/mmap'
make[7]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs'
make[7]: Entering directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs'
make -C xentoollog install
make[8]: Entering directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/xentoollog'
python2 genlevels.py _xtl_levels.mli.in _xtl_levels.ml.in _xtl_levels.inc
 MLDEP    
 MLC      xentoollog.cmo
 MLA      xentoollog.cma
 CC       xentoollog_stubs.o
xentoollog_stubs.c: In function 'stub_xtl_ocaml_vmessage':
xentoollog_stubs.c:93:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
   93 |  value *func = caml_named_value(xtl->vmessage_cb) ;
      |                ^~~~~~~~~~~~~~~~
xentoollog_stubs.c: In function 'stub_xtl_ocaml_progress':
xentoollog_stubs.c:123:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
  123 |  value *func = caml_named_value(xtl->progress_cb) ;
      |                ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[8]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/xentoollog/../../Makefile.rules:37: xentoollog_stubs.o] Error 1
make[8]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/xentoollog'
make[7]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/../../../tools/Rules.mk:251: subdir-install-xentoollog] Error 2
make[7]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs'
make[6]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/../../../tools/Rules.mk:246: subdirs-install] Error 2
make[6]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs'
make[5]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/../../tools/Rules.mk:251: subdir-install-libs] Error 2
make[5]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml'
make[4]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/../../tools/Rules.mk:246: subdirs-install] Error 2
make[4]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml'
make[3]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/../tools/Rules.mk:251: subdir-install-ocaml] Error 2
make[3]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools'
make[2]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/../tools/Rules.mk:246: subdirs-install] Error 2
make[2]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools'
make[1]: *** [Makefile:74: install] Error 2
make[1]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools'
make: *** [Makefile:127: install-tools] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
Error making: xen

sniper7kills commented on 2019-08-15 17:11

@mbroemme First of thanks for getting it working with gcc-9!

Secondly I'm running into the following compile issue: .cache/yay/xen/src/xen-4.12.1/tools/qemu-xen/include/disas/capstone.h:6:10: fatal error: capstone.h: No such file or directory 6 | #include <capstone.h>

I have capstone installed; and /usr/include/capstone/capstone.h exists. Any chance of a suggestion, Also should capstone be listed as a dependency?

mbroemme commented on 2019-08-15 10:08

Package is updated to Xen 4.12.1, ipxe package as well, supporting compilation with gcc-9.

@dhlk thanks for it, added !debug

linuxninja commented on 2019-07-19 07:50

fresh install of arch

attempted to install xen - failed

removed gcc v9, installed gcc-8

symlinked gcc -> gcc-8

re-tried install of xen - failed

/usr/bin/env: 'python': No such file or directory

So, looks like a dependency on python isn't configured properly? python2 is installed...

Installed python (python v3)

re-tried install of xen - failed

ERROR: "cc" either does not exist or does not work

make: Entering directory '/home/user/.cache/yay/xen/src/xen-4.12.0/tools/qemu-xen-build'

make: *** No rule to make target 'all'. Stop.

Not sure how deep this rabbit hole goes. Really don't want to go back to Debian...

CyrIng commented on 2019-06-29 09:38

"error: taking address of packed member of ..."
Same issue here to build Xen 4.12 w/ kernel 5.1.15, gcc 9.1.0
Solved by downgrading to package gcc8

aiyuchan commented on 2019-06-18 21:14

It seems to not compile at all using the latest GCC (9.1.0, just got out of testing today). I get way too many instances of -Werror=address-of-packed-member.

It's a known bug and afaik has been fixed in xen's git repo for a while now. Might be wise to incorporate the patch into the PKGBUILD until it gets merged into a proper release?

EDIT: I should add that this happens even when adding "--disable-werror" to the config params and "!debug" to the options à la dhlk's commment.

EDIT2: Even the latest, bleeding edge staging versions of xen and ipxe do not compile under GCC 9. I'm sure it'll be fixed in a few days or so, but the official Xen 4.13 release probably won't be coming for a while. If it ends up getting fixed and anyone is interested, I can create a xen-git package.

Anonymous comment on 2019-04-17 05:50

the http://google.com

dhlk commented on 2019-03-02 21:09

For anyone else (and my future self) who forgot they enabled debug in makepkg.conf, debug CFLAGS break xen's builds.

Error looks something like this:

<command-line>: error: "__OBJECT_FILE__" redefined [-Werror]
<command-line>: note: this is the location of the previous definition
<command-line>: error: "__OBJECT_LABEL__" redefined [-Werror]
<command-line>: note: this is the location of the previous definition
cc1: all warnings being treated as errors
Makefile:69: recipe for target 'compat/callback.i' failed

Fix requires removing debug in the PKGBUILD:

-options=(!buildflags !strip)
+options=(!buildflags !strip !debug)