Package Details: xen 4.16.1-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.163985
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2022-05-16 19:00 (UTC)

Sources (19)

Pinned Comments

Refutationalist commented on 2022-05-16 19:07 (UTC) (edited on 2022-05-18 22:19 (UTC) by Refutationalist)

Here is 4.16.1-1.

  • Has patches to compile under GCC12, entirely by disabling some error checks.
  • The hvmloader patch has been brought in, fixing that problem.
  • I dropped working on the OVMF fixes, since that's a separate project from Xen.
  • I have tested it on exactly two systems, both of which run AMD processors. Error reports and patches welcome.

UPDATE 2022-05-18: I have one machine running a Ryzen 7 5700G with an Intel 82576 that crashes on iommu. I'm attempting to get help with the problem, but if anyone else has a problem I'd like to hear about it.

Latest Comments

FringeLunatic commented on 2022-07-03 01:34 (UTC) (edited on 2022-07-03 01:35 (UTC) by FringeLunatic)

Like ArthurBorsboom, I get a conflicting file error:

error: failed to commit transaction (conflicting files)
/usr/lib/xen/bin/qemu-keymap exists in both 'xen' and 'xen-qemu-builtin'
Errors occurred, no packages were upgraded.
==> WARNING: Failed to install built package(s).
==> Cleaning up...

I could install xen without qemu builtin, of course, but I need it. Any way to fix this conflict?

Refutationalist commented on 2022-07-02 19:39 (UTC)

@Shapito You need to add the PGP key to your keyring to verify the signature, and patch is part of base-devel, which is always assumed.

Shapito commented on 2022-07-02 09:48 (UTC)

I get two errors when try to install this package. ==> Verifying source file signatures with gpg... xen-4.16.1.tar.gz ... FAILED (unknown public key 83FE14C957E82BD9) ==> ERROR: One or more PGP signatures could not be verified!

And after adding --skippgpcheck makepkg flag usage. ==> Starting prepare()... ==> Applying GCC 12.1 fixes... /home/<user_name>/aur/xen/PKGBUILD: line 172: patch: command not found ==> ERROR: A failure occurred in prepare(). Maybe, you need to add patch dependency.

ArthurBorsboom commented on 2022-06-12 08:04 (UTC) (edited on 2022-06-12 08:05 (UTC) by ArthurBorsboom)

If I want to install the xen-qemu-builtin package, I have to manually delete two files, which conflict with the xen package; then it can be installed without a conflict. Is this caused by the xen package?

[arthur@xen1 xen]$ sudo pacman -U xen-qemu-builtin-4.16.1-1-x86_64.pkg.tar.xz
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) xen-qemu-builtin-4.16.1-1

Total Installed Size:  244.04 MiB

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                                                                                            [#########################################################################] 100%
(1/1) checking package integrity                                                                                          [#########################################################################] 100%
(1/1) loading package files                                                                                               [#########################################################################] 100%
(1/1) checking for file conflicts                                                                                         [#########################################################################] 100%
error: failed to commit transaction (conflicting files)
xen-qemu-builtin: /usr/lib/xen/bin/qemu-keymap exists in filesystem (owned by xen)
xen-qemu-builtin: /usr/lib/xen/libexec/vhost-user-gpu exists in filesystem (owned by xen)
[arthur@xen1 xen]$ sudo rm /usr/lib/xen/bin/qemu-keymap
[arthur@xen1 xen]$ sudo rm /usr/lib/xen/libexec/vhost-user-gpu
[arthur@xen1 xen]$ sudo pacman -U xen-qemu-builtin-4.16.1-1-x86_64.pkg.tar.xz

vibrion commented on 2022-05-31 14:43 (UTC) (edited on 2022-05-31 14:48 (UTC) by vibrion)

After last xen upgrade Im running into a strange error at bootup: none domain are up. Searching logs for a clue i found this:

May 31 11:08:16 bakaneko systemd[1]: Finished Xendomains - start and stop guests on boot and shutdown. May 31 11:08:16 bakaneko xendomains[369]: [done] May 31 11:08:16 bakaneko xendomains[369]: ! May 31 11:08:16 bakaneko xendomains[369]: An error occurred while creating domain new_moodle_eest1-vm.cfg: May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 4:Destruction of domain failed May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 4:Unable to destroy guest May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 4:Non-existant domain May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_create.c:1289:initiate_domain_create: Domain 4:Unable to set disk defaults for disk 0 May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_device.c:399:libxl__device_disk_set_backend: Disk vdev=xvda failed to stat: /dev/mapper/VM_bakaneko_vg-new> May 31 11:08:16 bakaneko xendomains[369]: new_moodle_eest1-vm.cfg

Despite this if xendomains is manually restarted everything boots up normally. Another error is related to qemu-dom0 backend:

May 31 11:36:42 bakaneko systemd[1]: Starting qemu for xen dom0 disk backend... May 31 11:36:42 bakaneko systemd[1]: Started qemu for xen dom0 disk backend. May 31 11:36:42 bakaneko qemu-system-i386[964]: qemu-system-i386: -xen-domid 0: Option not supported for this target.

Also at system upgrade a question arise for qemu-desktop replacement for qemu (dont know its related or not) Any suggestion? Thanks!!

Refutationalist commented on 2022-05-16 19:07 (UTC) (edited on 2022-05-18 22:19 (UTC) by Refutationalist)

Here is 4.16.1-1.

  • Has patches to compile under GCC12, entirely by disabling some error checks.
  • The hvmloader patch has been brought in, fixing that problem.
  • I dropped working on the OVMF fixes, since that's a separate project from Xen.
  • I have tested it on exactly two systems, both of which run AMD processors. Error reports and patches welcome.

UPDATE 2022-05-18: I have one machine running a Ryzen 7 5700G with an Intel 82576 that crashes on iommu. I'm attempting to get help with the problem, but if anyone else has a problem I'd like to hear about it.

Refutationalist commented on 2022-05-13 08:32 (UTC)

@Sven I have a 4.16.1-0 in my repo that compiles cleanly except for stubdom, mostly thanks to an OpenSUSE patch that sets a bunch exceptions here and there. Still looking into the stubdom bit before I update AUR.

Sven commented on 2022-05-12 21:45 (UTC)

Xen 4.16.0-3 doesn't seem to build with gcc 12.1.0

Refutationalist commented on 2022-04-20 21:59 (UTC)

Hoping to get to it this week. Haven't had much time in front of a computer myriad of reasons.

ArthurBorsboom commented on 2022-04-14 07:05 (UTC)

@Refutationalist : any change of applying this patch to the PKGBUILD ?

ska67 commented on 2022-04-13 22:22 (UTC)

@ArthurBorsboom Have a look at https://github.com/refutationalist/saur/pull/8 As long as this patch is not applied yet, you would have to help yourself.

ArthurBorsboom commented on 2022-04-13 13:00 (UTC)

I suspect I am overseeing something, but I can't find the hvmloader anymore in /usr/lib/xen/boot/hvmloader

Do I need to install a separate package? Am I missing a built/makepkg option?

Any pointers?

ska67 commented on 2022-02-19 12:36 (UTC)

@milenus, this package does not build the qemu-xen-traditional device model, but this is needed if you want to use the mini-os-based qemu stubdom with device_model_stubdomain_override = 1. A qemu stubdom based on Linux is needed for use with the qemu-xen device model. As I have read, this will be part of Xen in the future. QubesOS already uses such stubdoms, but I haven't tried them yet. This package builds the VTPM stubdoms, which can be used to store LUKS keys, for example.

milenus commented on 2022-02-18 09:33 (UTC)

Actually in the last two commits there is no hvmloader after installing the compiled packages regardless of the build options, so I rolled back to 4.16.0-1.

Refutationalist commented on 2022-02-17 22:55 (UTC)

@milenus: I don't actually use stubdom, so I'm not surprised they're working right. They're only in by request. I haven't set up a test for them, just hoping to get feedback. Patch will be welcome, otherwise it'll be a bit.

milenus commented on 2022-02-17 12:22 (UTC)

Hello @Refutationalist, I just read how cool are stub domains and decided to try them. Successfully compiled and installed all four xen*.zst packages. I included in the HVM file device_model_stubdomain_override = 1 but when I try to create the VM it fails because of missing hvmloader. Can you please share some info how you use it?

Refutationalist commented on 2022-02-15 18:49 (UTC)

@Sven that's fixed now. I swear that was wrapped in an if statement at some point.

Sven commented on 2022-02-13 09:44 (UTC)

build_qemu=false makepkg -sc fails with rm: cannot remove '/home/skoehler/aur/xen/pkg/xen/usr/share/qemu-xen': No such file or directory

Refutationalist commented on 2022-02-06 14:16 (UTC)

Hello! Here's 4.16.0-2.

As I mentioned earlier, qemu and stubdom, if built, now generate packages rather than being built into xen itself. As a reminder, if you need stubdom, you can pass build_stubdom=true to makepkg. Similarly, passing build_qemu=false will prevent the package from building qemu-xen.

I am working on that OVMF patch, and should have it in shortly.

ska67 commented on 2022-01-30 16:58 (UTC)

The use of SDL requires the new dependency libxi, see https://github.com/libsdl-org/SDL/issues/4938

@Sven Take a look into the PKGBUILD file, you will find the answer there :)

Sven commented on 2022-01-03 00:01 (UTC)

Is there a way to build xen without qemu? I only have guests with paravirtualized hardware (pvh guests) and building qemu takes a lot of time and probably has a lot of dependencies.

ska67 commented on 2022-01-02 14:19 (UTC) (edited on 2022-01-02 14:21 (UTC) by ska67)

OVMF from the edk2-ovmf package can no longer be used with Xen because Xen support has been removed from the x64 platform target. See my last post in arch linux forum: https://bbs.archlinux.org/viewtopic.php?id=269628

OVMF shipped with this Xen package cannot be built due to an upstream error. @Refutationalist, I have a working patch that I will email to you.

Btw, the specific platform target OvmfXen is supposed to be bootable in PVH type DomUs, but I couldn't get that to work.

Refutationalist commented on 2021-12-28 17:47 (UTC) (edited on 2021-12-28 17:47 (UTC) by Refutationalist)

@ska64 I don't work with windows very much at all, so needing TPM for win11 didn't occur to me. I've pushed the changes to AUR and I'll consider what I might do to improve stubdom.

ska67 commented on 2021-12-28 16:20 (UTC)

Your updated package on Github works out of the box. Maybe you could surround the new ninja makedepends with apostrophes, but it compiles without that change.

I tested with and without build_stubdom=true, it compiles and runs. Qemu is built and running as well.

The stubdoms are needed for virtual TPMs. I want to use them to store a LUKS key. But maybe someone else needs them to start Windows?

Refutationalist commented on 2021-12-26 19:29 (UTC) (edited on 2021-12-26 19:32 (UTC) by Refutationalist)

I do not have 4.16 in yet, but I suspect a lot of people by now know that 4.16 is compiling cleanly without extra patches. I just haven't had a chance to test it, or heard of anyone else testing it, so I haven't pushed my changes. I do have a simply updated package in my repo (https://github.com/refutationalist/saur) if you're interested in testing.

So, still out of date officially, but if I can get some confirmations that it works, I can push it here and leaving dealing with stubdom when I get back.

Other notes:

1) I got a request to leave stubdom in. Maybe I could make it part of the split package config? Looking into that, but probably not. The age of the extfiles needed for stubdom is starting to worry me and conflating with the "secure" aspects of stubdom. Part of what moved me to subdomless PVH.

2) I'm not able to recreate the qemu conflicts.

3) If building QEMU, we now need ninja.

4) I'm going to be playing with a Honeycomb LX2, so I'm hoping to have a version of xen that runs under alarm. Building for arm is really different, however.

ArthurBorsboom commented on 2021-10-24 09:33 (UTC)

On my system, the Xen 4.15.1-1 package fails to build. Any pointers ? GCC v11.1.0 ?

xentoollog_stubs.c:57: error: "Some_val" redefined [-Werror]
   57 | #define Some_val(v) Field(v,0)
      | 
In file included from /usr/lib/ocaml/caml/alloc.h:24,
                 from xentoollog_stubs.c:23:
/usr/lib/ocaml/caml/mlvalues.h:396: note: this is the location of the previous definition
  396 | #define Some_val(v) Field(v, 0)
      | 
cc1: all warnings being treated as errors
...
...
...
==> ERROR: A failure occurred in build().

micwoj92 commented on 2021-10-13 19:02 (UTC)

I think it should conflict with qemu by default

error: failed to commit transaction (conflicting files)
xen: /usr/share/locale/bg/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/de_DE/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/fr_FR/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/hu/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/it/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/sv/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/tr/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/zh_CN/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
Errors occurred, no packages were upgraded.

ska67 commented on 2021-09-29 22:20 (UTC)

Thank you for your commitment to this package. I never got the stubdom thing to work, but at some point I would like to try it again. So I would prefer if you keep the stubdom switch as it is implemented now.

Refutationalist commented on 2021-09-28 23:27 (UTC) (edited on 2021-09-28 23:28 (UTC) by Refutationalist)

Here's 4.15.1-1.

1) This one compiles cleanly on GCC11 et al., so there are currently no patches.

2) I'm well away from my usual haunts, so I'm only testing it on the Zen 2 machine I have with me, but it does boot and run HVM and PVH domUs.

3) We're expecting 4.16 around the end of the year, and so this is a reminder that when that's released, I'll be removing stubdom support as I was the only user.

4) I didn't know there was a Xen wiki page. I should update that at some point.

Refutationalist commented on 2021-08-28 07:28 (UTC) (edited on 2021-08-28 07:29 (UTC) by Refutationalist)

Hello! 4.15.0-3 is here. Here's an update:

1) The current GCC11 patch is updated for 4.15.0 and included here. It was in my github for a bit but I forgot to push it here. Whoops.

2) I've added the recent spate of XSA patches, but one had to be redone for our build environment. It is included.

3) mxca's fixes for EFI have been incorporated, but the directory is set to /boot by default, as I understand this is what is common.

4) On a personal note, my surgery went very well! I am still recovering, but things are looking good for me. Thank you for the well-wishes!

Sven commented on 2021-08-09 19:10 (UTC) (edited on 2021-08-14 22:14 (UTC) by Sven)

4.15.0-1 doesn't compile. Compilation stops with an error in line 729 of x86_emulate.c because of -Werror=stringop-overflow.

I assume that we see this error due to gcc 11. The command of mxca links to a patch for compiling with gcc 11.

Also, my best wishes go to Refutationalist. I hope the surgery goes well and you can return soon.

mxca commented on 2021-05-27 14:32 (UTC) (edited on 2021-05-27 21:42 (UTC) by mxca)

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

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

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

ArthurBorsboom commented on 2021-01-17 13:04 (UTC)

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

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 (UTC) (edited on 2020-12-22 11:29 (UTC) by Refutationalist)

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

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

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

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 (UTC) (edited on 2020-11-21 21:24 (UTC) by Refutationalist)

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

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

eduncan911 commented on 2020-11-09 16:28 (UTC)

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

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

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 (UTC) (edited on 2020-10-26 15:09 (UTC) by manueljben)

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

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

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

eduncan911 commented on 2020-09-27 23:24 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 (UTC) (edited on 2020-07-29 04:08 (UTC) by linuxninja)

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

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

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

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

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 (UTC) (edited on 2020-07-10 05:17 (UTC) by Refutationalist)

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

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

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

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 (UTC) (edited on 2020-06-30 20:22 (UTC) by Refutationalist)

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

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

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

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

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

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

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

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

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

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

linuxninja commented on 2020-05-05 16:35 (UTC)

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

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

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

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

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

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

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

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 (UTC) (edited on 2020-03-10 11:20 (UTC) by JohnTh)

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 (UTC) (edited on 2020-04-04 16:38 (UTC) by FFY00)

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

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 (UTC) (edited on 2020-03-06 11:04 (UTC) by tony_42)

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 (UTC) (edited on 2020-03-05 21:08 (UTC) by FrostbittenKing)

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

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

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 (UTC) (edited on 2020-03-05 17:48 (UTC) by FFY00)

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 (UTC) (edited on 2020-03-04 04:59 (UTC) by invisiblek)

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

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

schweratlet commented on 2020-02-17 22:35 (UTC)

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

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

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

sl4mmy commented on 2019-12-19 15:26 (UTC)

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

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

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

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

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

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

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 (UTC) (edited on 2019-10-14 15:33 (UTC) by xer01ne)

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

@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 (UTC) (edited on 2019-08-15 10:08 (UTC) by mbroemme)

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 (UTC) (edited on 2019-07-19 07:51 (UTC) by linuxninja)

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 (UTC) (edited on 2019-06-29 16:31 (UTC) by CyrIng)

"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 (UTC) (edited on 2019-06-19 00:39 (UTC) by aiyuchan)

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.

commented on 2019-04-17 05:50 (UTC)

the http://google.com

dhlk commented on 2019-03-02 21:09 (UTC) (edited on 2019-03-02 21:09 (UTC) by dhlk)

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)

CyrIng commented on 2018-12-06 13:08 (UTC)

Works like a charm, Thank you.

eduncan911 commented on 2018-10-31 15:46 (UTC)

@ArthurBorsboom: thank you! i'll have an AMD system to test it out on soon.

instead of flooding these comments with discussions, let's keep it in recent forum topic here:

https://bbs.archlinux.org/viewtopic.php?pid=1814467

In short, there's another way that we can ask the author of the intel-ucode package to resolve (posted in the link above).

ArthurBorsboom commented on 2018-10-31 07:52 (UTC)

I have found a solution in the past (and am still using) another way of loading the (AMD) microcode in Xen.

In essence:

  • Create a symlink from /lib/firmware/amd-ucode/microcode_amd_fam15h.bin -> /boot/microcode_amd_fam15h.bin
  • Edit the /etc/xen/grub.conf and add " ucode=-1"
  • Manually update the file /etc/grub.d/09_xen by adding the following two lines (note that these lines differ a little bit from the forum post

    echo 'Loading AMD Microcode' module2 ${REAL_DIR}/microcode_amd_fam15h.bin

  • rebuild grub conf file: grub-mkconfig -o /boot/grub/grub.cfg

  • reboot

I have described it more accurately in this forum post, where you have to replace the word module (outdated) with module2.

https://bbs.archlinux.org/viewtopic.php?id=191828

So, no kernel panic while loading multiple ramdisks.

Does this help you to find a persistent solution?

eduncan911 commented on 2018-10-30 15:14 (UTC) (edited on 2018-10-30 15:39 (UTC) by eduncan911)

EDIT: Created a bbs topic for discussion: https://bbs.archlinux.org/viewtopic.php?pid=1814467

Intel (and perhaps AMD, can't test that yet) microcode patching.

Problem:

xen.cfg for Xen EFI cannot use the intel-ucode.img microcode binary produced by the intel-ucode system package. Attempting to specify multiple ramdisk lines panics the kernel (Xen EFI only reads the first line); and, specifying multiple imgs on the single ramdisk line is invalid by Xen EFI and just exits the boot.

Resolution:

Create a "patched" initramfs-linux.img file:

# cat /boot/intel-ucode.img /boot/initramfs-linux.img > /boot/intel-ucode_initramfs-linux.img

And then change xen.cfg to use this new patched ramdisk.

You can verify the fix with:

$ sudo xl dmesg | grep microcode
(XEN) microcode: CPU0 updated from revision 0x28 to 0x32, date = 2018-05-11
(XEN) microcode: CPU2 updated from revision 0x28 to 0x32, date = 2018-05-11

The bbs discussion above is to figure out the best place to capture this information.

ArthurBorsboom commented on 2018-10-01 07:56 (UTC)

I confirm the error message reported by sniper7kills: "free(): invalid pointer".

sniper7kills commented on 2018-09-30 06:32 (UTC)

To generate the error I went to tools/firmware/hvmloader and ran make while using the latest version of acpica

make -C ../../libacpi  ACPI_BUILD_DIR=/storage/xen/src/xen-4.11.0/tools/firmware/hvmloader DSDT_FILES="dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c"
make[1]: Entering directory '/storage/xen/src/xen-4.11.0/tools/libacpi'
gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -Wdeclaration-after-statement -DCONFIG_X86 -I/storage/xen/src/xen-4.11.0/tools/libacpi/../../tools/include -D__XEN_TOOLS__ -o /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/mk_dsdt mk_dsdt.c
# Remove last bracket
awk 'NR > 1 {print s} {s=$0}' dsdt.asl > /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.asl.tmp
cat dsdt_acpi_info.asl >> /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.asl.tmp
/storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/mk_dsdt --debug=n --maxcpu any  >> /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.asl.tmp
mv -f /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.asl.tmp /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.asl
iasl -vs -p /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.tmp -tc /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.asl
free(): invalid pointer
make[1]: *** [Makefile:78: /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.c] Aborted (core dumped)
make[1]: Leaving directory '/storage/xen/src/xen-4.11.0/tools/libacpi'
make: *** [Makefile:72: acpi] Error 2

sniper7kills commented on 2018-09-30 06:08 (UTC)

Unlikely that this is a xen issue; but building fails when using the latest acpica package.

It was something to do with the hvmloader and unable to call free() due to an invalid pointer.

Downgrading acpica to version 20180629 allows the package to compile.

Once I recompile xen to fix my libiscsi issue, I'll upgrade acpica again to try and provide more information.

alaricljs commented on 2018-08-01 00:53 (UTC)

Orphaned package removal routine* breaks this package. Please fix your depends/makedepends so that they are accurate.

*https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#Removing_unused_packages_.28orphans.29

Thanks!

mbroemme commented on 2018-07-10 11:10 (UTC)

4.11.0 is available and I will test it till next week and update PKGBUILD

k96hkh commented on 2018-07-07 11:01 (UTC)

@mbroemme: No problem, thanks for reply and for your work on xen package. Have an awesome weekend!

mbroemme commented on 2018-07-06 11:57 (UTC)

@k96hkh: I believe xen 4.11.0 will come out in the next 2 weeks. Is it okay to wait this 2 weeks and I will update the PKGBUILD as soon as 4.11.0 is out.

k96hkh commented on 2018-07-06 11:00 (UTC)

I'm afraid I got stuck with same error as "Anonym" and "tendermonster", any idea what I can do to get xen to build? I guess I could build from 4.11-rcX like "tendermonster" but I would prefer to use the AUR package. Cheers!

tendermonster commented on 2018-06-22 16:22 (UTC)

My lil story on installing xen from aur:

i got the same error what "Anonym commented on 2018-06-21 15:01" got. Then i tried to compile xen myself from gitrepo but failed with save error. I tries fixing it my editing countless c++ files, but at the end i gave up when i encountered "util.o: In function hvmloader_acpi_build_tables': util.c:(.text+0x183e): undefined reference todsdt_anycpu_qemu_xen' util.c:(.text+0x1b52): undefined reference to dsdt_anycpu' util.c:(.text+0x1b65): undefined reference todsdt_15cpu' ovmf.o: In function ovmf_acpi_build_tables': ovmf.c:(.text+0xf8): undefined reference todsdt_anycpu_qemu_xen' seabios.o: In function seabios_acpi_build_tables': seabios.c:(.text+0x25a): undefined reference todsdt_anycpu_qemu_xen' rombios.o: In function rombios_acpi_build_tables': rombios.c:(.text+0x68): undefined reference todsdt_anycpu' rombios.c:(.text+0x7e): undefined reference to `dsdt_15cpu' " errors. I have no idea what really causes it(Makefile in tools/firmware/hvmloader?)

After that I just compiled the more uptodate "i guess" 4.11-rcX from https://github.com/xen-project/xen and all just worked fine.

Just install all required packaged "make gcc lib32-gcc-libs lib32-fakeroot lib32-libltdl seabios patch autoconf pkgconf linux-headers zlib python python-pip python-lxml xorg-server haskell-uuid yajl libaio glib2 bridge-utils bison flex acpica cmake markdown figlet bin86 dev86 python2 python-pip fig2dev wget pandoc patch" and configure; make; install

Just to be on the safe side use python2 and gcc7 also link then to gcc and python with ln -s /usr/bin/python2 /usr/bin/python and ls -s /usr/bin/gcc-7 /usr/bin/gcc

It would ne cool if anyone would notify me if the problem resolves on xen 4.10.1

Much thx and have a sunny day :)

dhlk commented on 2018-06-22 00:51 (UTC)

@anon This commit updates the makefile for newer versions of iasl: https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=858dbaaeda33b05c1ac80aea0ba9a03924e09005

Anonym commented on 2018-06-21 13:01 (UTC)

when compiling dsdt_anycpu.c, I get the following error dsdt_anycpu.c:7495:28: Error:‘dsdt_anycpu’ undeclared here (not in a function); did you mean ‘dsdt_anycpu_len’? int dsdt_anycpu_len=sizeof(dsdt_anycpu); ^~~~~~~~~~~ dsdt_anycpu_len

baratharon commented on 2018-05-08 08:47 (UTC)

@daniel_shub AFAIK, this is a new feature in GCC 8, which will be an error if -Werror is used. If you need the build ASAP, then you can downgrade your GCC.

daniel_shub commented on 2018-05-07 23:55 (UTC)

I am building in a clean chroot. I get the following error;

xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN);

It looks like there may be a patch for it https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg11468.html

mbroemme commented on 2018-05-03 08:09 (UTC)

@virtualdxs: I've fixed OVMF system path, also added XSA-258 and glibc-2.27 compilation fix.

Regarding build failure, it looks like there was a previosuly applied patch in the src/ directory. Did you do rm -R src/ pkg/ before trying another compilation?

virtualdxs commented on 2018-05-02 15:59 (UTC)

Here's the patch output: https://pastebin.com/VyPBun68

virtualdxs commented on 2018-05-02 15:53 (UTC)

Also xsa253-xsa254-diff-release410-comet1.1.patch is failing. Build succeeds without it.

virtualdxs commented on 2018-05-02 15:28 (UTC)

I could've sworn this was fixed months ago, but the compile options are wrong.

    --enable-ovmf \
    --with-system-ovmf \
    --with-system-seabios=/usr/share/qemu/bios-256k.bin \

Notice the --with-system-ovmf doesn't have a path. So Xen tries to access the file yes when looking for an EFI bios.

baratharon commented on 2018-04-18 12:28 (UTC)

@mbroemme

xencommons: afaik I did not modified anything in xencommons https://pastebin.com/fjL3aRXw

xenstored.log:

...
Xen Storage Daemon, version 1.0
Xen Storage Daemon, version 1.0
Xen Storage Daemon, version 1.0
[20170612T07:40:10.883Z|error|xenstored] closing socket connection: write error: Broken pipe
Xen Storage Daemon, version 1.0
Xen Storage Daemon, version 1.0
...

mbroemme commented on 2018-04-14 07:51 (UTC)

@barathon: Do you have anything in /var/log/xen/xenstored.log Could you please post a link to your /etc/conf.d/xencommons

baratharon commented on 2018-04-13 14:18 (UTC)

Nope, its still not working.

$ systemctl status xenstored
● xenstored.service - The Xen xenstore
   Loaded: loaded (/usr/lib/systemd/system/xenstored.service; enabled; vendor preset: disabled)
   Active: failed (Result: protocol) since Fri 2018-04-13 06:08:24 CEST; 10h ago
  Process: 493 ExecStart=/etc/xen/scripts/launch-xenstore (code=exited, status=0/SUCCESS)
  Process: 484 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS)
 Main PID: 493 (code=exited, status=0/SUCCESS)
$
$ pacman -Qi xen
Version         : 4.10.0-4
Provides        : xen-4.10.0
Installed Size  : 63.92 MiB
Build Date      : Thu 12 Apr 2018 09:29:46 AM CEST
Install Date    : Thu 12 Apr 2018 09:30:24 AM CEST

baratharon commented on 2018-04-12 07:16 (UTC)

@mbroemme: Sure. But I can restart the machine only tomorrow.

mbroemme commented on 2018-04-12 07:07 (UTC)

@jsteel: I've fixed the dependencies and aligned them between qemu-xen and qemu-xen-traditional.

@ianu/@dhlk: Fixed it as well and also applied and enabled all patches up to XSA-256.

@baratharon: Could you please retry with latest PKGBUILD from AUR?

jsteel commented on 2018-03-14 09:13 (UTC)

xen-qemu-dom0-disk-backend.service fails, libepoxy is needed: /usr/lib/xen/bin/qemu-system-i386: error while loading shared libraries: libepoxy.so.0: cannot open shared object file: No such file or directory

ianu commented on 2018-03-13 21:06 (UTC)

This change should fix it

    # XSA patches (Last checked: XSA-253)
    'bba1abb5e4368421de29385e37f8477bf3534d3ba3ff7e2aae9c9d3da53f1393'
-   '5276d63e3b2ffc5217981e7b683c28d75b81793af8d2ffc75566db39aaabbaef'
+   'fa8cd07b85a8ff29cba8d891f12f9be4b173dd91a58404aabbf49c3f83152af9'

dhlk commented on 2018-03-10 01:08 (UTC)

Looks like the checksum on xsa254-diff-release410-comet1.1.patch is incorrect.

baratharon commented on 2018-02-28 09:30 (UTC) (edited on 2018-02-28 09:30 (UTC) by baratharon)

Today I upgraded from 4.8 to 4.10, and I got this (no more information is available, so I don't know what should I do; also, google has no any usable info):

 xenstored.service - The Xen xenstore
   Loaded: loaded (/usr/lib/systemd/system/xenstored.service; enabled; vendor preset: disabled)
   Active: failed (Result: protocol) since Wed 2018-02-28 10:23:45 CET; 2min 6s ago
  Process: 506 ExecStart=/etc/xen/scripts/launch-xenstore (code=exited, status=0/SUCCESS)
  Process: 485 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS)
 Main PID: 506 (code=exited, status=0/SUCCESS)

JohnTh commented on 2017-12-15 02:33 (UTC)

If your guest cannot see disks, make sure you have the xen-blkfront module loaded in your guest. You can use a serial port on the dom0 to get the full Xen log. I have a 4.10 PKGBUILD here: https://gitlab.com/archlinux-packages-johnth/xen

sniper7kills commented on 2017-12-15 02:05 (UTC)

@mbroemme if you happen to have a git repo or PKGBUILD for 4.10 I'd love to give it a try; for some reason I'm having issues with linux install disks not detecting the HDD on any VM I try to setup and also been getting some errors after xen boots prior to the kernel but haven't been able to capture them at all.

Hoping that 4.10 resolves these for me.

mbroemme commented on 2017-12-12 08:53 (UTC) (edited on 2017-12-12 08:55 (UTC) by mbroemme)

@das_j: According to the wiki 4.10 was released. If you want I can also take it over and continue to maintain it.

mbroemme commented on 2017-12-08 11:26 (UTC)

@ezequiel.ezb: Import key via 'gpg --recv-keys 83FE14C957E82BD9' and retry build

ezequiel.ezb commented on 2017-12-08 11:21 (UTC)

All dependencies install correctly, however, I get this error afterwards:

==> Verifying source file signatures with gpg... xen-4.9.0.tar.gz ... FAILED (unknown public key 83FE14C957E82BD9) ==> ERROR: One or more PGP signatures could not be verified! makepkg -si 21.93s user 5.66s system 5% cpu 9:01.31 total

mbroemme commented on 2017-11-24 14:31 (UTC)

@das_j: Xen 4.9 has full multiboot2 support to make EFI + Grub + Xen working out of the box. See https://wiki.xenproject.org/wiki/Xen_EFI In Arch Linux there is already grub2 2.02 with working multiboot2, so could cou please apply the following patch to grub-mkconfig-helper: https://zuppy.pm/patches/xen-grub2-efi-multiboot2.patch I've tested it already, with this patch Xen can be booted via grub in BIOS and UEFI mode. Without the patch you are forced to switch to BIOS mode or use EFI binary directly which makes multi-OS / grub2 booting very complicated.

mbroemme commented on 2017-11-24 14:17 (UTC) (edited on 2017-11-24 14:17 (UTC) by mbroemme)

@das_j: There is a bug in this package which will result in systemd failing to load kernel modules: Nov 24 15:09:49 server systemd-modules-load[4287]: Failed to find module 'gntdev' Nov 24 15:09:49 server systemd-modules-load[4287]: Failed to find module 'netbk' Nov 24 15:09:49 server systemd-modules-load[4287]: Failed to find module 'blkbk' Nov 24 15:09:49 server systemd-modules-load[4287]: Failed to find module 'xen-scsibk' Nov 24 15:09:49 server systemd-modules-load[4287]: Failed to find module 'usbbk' Nov 24 15:09:49 server systemd-modules-load[4287]: Failed to find module 'pciback' Nov 24 15:09:49 server systemd-modules-load[4287]: Failed to find module 'blktap2' Nov 24 15:09:49 server systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE Nov 24 15:09:49 server systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'. Nov 24 15:09:49 server systemd[1]: Failed to start Load Kernel Modules. The reason is because the shipped xen.conf is never installed during package build, therefore the xen default is installed but not working for Arch Linux kernels. Could you please apply the following patch to PKGBUILD: https://zuppy.pm/patches/xen-modules-load-fix.patch

ipdown commented on 2017-11-09 17:20 (UTC)

Does anyone knows how to get coretemp/lm_sensors to work with xen-kernel? I am able to monitor cpu temperature with regular kernel, but not in dom0/xen-kernel.

ArthurBorsboom commented on 2017-10-19 18:05 (UTC)

If this only installs one package, what about changing the make dependency in the package from pandoc to pandoc-bin? Or does this have side effects?

zootboy commented on 2017-10-19 03:41 (UTC)

@ArthurBorsboom You can install pandoc-bin in its place.

ArthurBorsboom commented on 2017-10-15 08:45 (UTC)

Xen doesn't build (anymore): entry.S: Assembler messages: entry.S:42: Error: invalid operands (*ABS* and *UND* sections) for `-' entry.S:61: Error: invalid operands (*UND* and *UND* sections) for `+' entry.S:115: Error: invalid operands (*ABS* and *UND* sections) for `-' entry.S:110: Error: invalid operands (*UND* and *UND* sections) for `-' make[6]: *** [/opt/tmp/makepkg/xen/src/xen-4.9.0/xen/Rules.mk:177: entry.o] Error 1 Any idea how to solve this?

ArthurBorsboom commented on 2017-10-14 08:11 (UTC)

Is the pandoc make dependency really necessary? It brings in exactly 101 haskell-* (dependency) packages.

JohnTh commented on 2017-10-01 01:19 (UTC)

Thanks das_j Hi finnland, I didn't have any issues installing or running win10 or freebsd11 amd64 iso zroot with ovmf. This patch for xen-4.9.0 built-in ovmf: https://github.com/tianocore/edk2/commit/fe4a28ccbfd33cae9e1f56b174d46b4eb2329efd.patch Or the full ovmf BIOS built with a modified Arch ovmf PKGBUILD. diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD index f9297d0..098ab18 100644 --- a/trunk/PKGBUILD +++ b/trunk/PKGBUILD @@ -1,6 +1,7 @@ # $Id$ # Maintainer: Thomas Bächler <thomas@archlinux.org> -pkgname=ovmf +pkgbase=ovmf +pkgname=('ovmf' 'ovmf-unsplit') pkgver=r22345.bec7a86c70 epoch=1 pkgrel=1 @@ -51,10 +52,15 @@ build() { ./BaseTools/BinWrappers/PosixLike/build } -package() { +package_ovmf() { #install -D -m644 "${srcdir}"/edk2/Build/OvmfIa32/RELEASE_${_toolchain_opt}/FV/OVMF_CODE.fd "${pkgdir}"/usr/share/ovmf/ia32/OVMF_CODE.fd #install -D -m644 "${srcdir}"/edk2/Build/OvmfIa32/RELEASE_${_toolchain_opt}/FV/OVMF_VARS.fd "${pkgdir}"/usr/share/ovmf/ia32/OVMF_VARS.fd install -D -m644 "${srcdir}"/edk2/Build/OvmfX64/RELEASE_${_toolchain_opt}/FV/OVMF_CODE.fd "${pkgdir}"/usr/share/ovmf/x64/OVMF_CODE.fd install -D -m644 "${srcdir}"/edk2/Build/OvmfX64/RELEASE_${_toolchain_opt}/FV/OVMF_VARS.fd "${pkgdir}"/usr/share/ovmf/x64/OVMF_VARS.fd install -D -m644 "${srcdir}"/edk2/OvmfPkg/License.txt "${pkgdir}"/usr/share/licenses/ovmf/License.txt } + +package_ovmf-unsplit() { + install -D -m644 "${srcdir}"/edk2/Build/OvmfX64/RELEASE_${_toolchain_opt}/FV/OVMF.fd "${pkgdir}"/usr/share/ovmf/ovmf_x64.bin + install -D -m644 "${srcdir}"/edk2/OvmfPkg/License.txt "${pkgdir}"/usr/share/licenses/"${pkgname[2]}"/License.txt +} VM config ### Xen VM options ## http://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html name="win10.cfg" builder="hvm" memory=2048 bios="ovmf" bios_path_override="/usr/share/ovmf/ovmf_x64.bin" #device_model_args=[ "-debugcon", "file:ovmf_debug.log", "-global", "isa-debugcon.iobase=0x402"] hdtype="ahci" disk=[ "/mnt/server/software/os/Microsoft_Windows/to_check/Win10_1703_EnglishInternational_x64.iso, raw, xvdc, cdrom", # "/mnt/server/software/os/FreeBSD-11.1-RELEASE-amd64-disc1.iso, raw, xvdc, cdrom", "/dev/mapper/sda1_vg-win10, raw, xvda, rw" ] vif=[ "" ] vnc=1 vnclisten="0.0.0.0" vncunused=1 vncpasswd="pass" usb=1 usbdevice=[ "tablet" ]

commented on 2017-09-30 21:14 (UTC)

@tony_42 Thank you, applied :) @maldo Building from AUR requires base-devel @maldo @asura Added SPICE dependency @JohnTh Applied all XSA patches

finnland commented on 2017-09-25 12:52 (UTC)

Hi JohnTh, after quite a bit of tinkering I got Xen built with the in tree ovmf. It does not build out of the box so i had to select a newer version, the one it selects from git by default has a bug in it. Anyhow I got it so far that I can start a machine using ovmf but it seems quite flaky, win 10 just reboots immediately , Freebsd 11 crashes. Arch works tho. I gave up for now and sticking with seabios, which seems to work.

JohnTh commented on 2017-09-24 00:57 (UTC)

Hi finnland, There was some discussion about this on the Xen lists. It is not clear if Xen currently will work with ovmf split code and vars. http://markmail.org/message/vh5kk53z3v4fxhpa If you do want to use system ovmf: Test if the Arch PKGBUILD ovmf combined image works with xen. I think it did when I tested some time ago. Easiest to makepkg ovmf and copy the combined image somewhere. Then use the xl vm guest options bios="ovmf" bios_path_override="path to ovmf" If this works, we could ask the Arch ovmf package maintainer to change the PKGBUILD to produce split packages of ovmf (as is) and ovmf-combined (only package the merged ovmf). Should be minimal changes to the PKGBUILD. https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/ovmf There are also a number of XSA patches for xen-4.9.0

finnland commented on 2017-09-23 21:54 (UTC)

The build flag --with-system-ovmf works the same as --with-system-seabios in that it should contain a path such as --with-system-ovmf=/usr/share/ovmf/ovmf_code_x64.bin. Cannot make it boot properly with it tho, unsure how to tell it about split ovmf images.

lazycat commented on 2017-09-03 04:10 (UTC)

@JohnTh Thanks a lot, rebuilding kernel helped me

JohnTh commented on 2017-08-31 06:13 (UTC)

Hey Lazycat, This is an Arch linux 4.12 kernel bug due to CONFIG_INTEL_ATOMISP https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711298 Arch bug here https://bugs.archlinux.org/task/55447 The 201707 install disk uses 4.11 and boots Arch used 4.12 from 2017-07-05 https://git.archlinux.org/svntogit/packages.git/commit/?h=packages/linux&id=6e70fcab0f7e068216f579f72385175113587083 You can build a 4.12 kernel with CONFIG_INTEL_ATOMISP=n or use the Arch Linux archive: https://wiki.archlinux.org/index.php/Arch_Linux_Archive#How_to_restore_all_packages_to_a_specific_date For the spice error, makedepend libcacard The spice Arch package removed it as a depend in 0.12.8+8+ga957a90b

lazycat commented on 2017-08-30 17:28 (UTC)

Hello all! Today i made full system upgrade and upgrade xen from 4.8 to 4.9 from aur too. Now i can't create new PV domU (but old runs fine) error: Parsing config from test.cfg [ 0.107779] xen:manage: Unable to read sysrq code in control/sysrq [ 0.110203] dmi: Firmware registration failed. [ 0.131027] intel_mid_msgbus_init: Error: msgbus PCI handle NULL [ 3.997728] BUG: unable to handle kernel paging request at ffffc90040199060 [ 3.997742] IP: vlv2_plat_configure_clock+0x3b/0xa0 [ 3.997746] PGD 3fe10067 [ 3.997746] P4D 3fe10067 [ 3.997748] PUD 3e202067 [ 3.997750] PMD 3e203067 [ 3.997752] PTE 0 [ 3.997753] [ 3.997757] Oops: 0000 [#1] PREEMPT SMP [ 3.997760] Modules linked in: [ 3.997765] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.3-1-ARCH #1 [ 3.997768] task: ffff88003e2c4240 task.stack: ffffc9004018c000 [ 3.997773] RIP: e030:vlv2_plat_configure_clock+0x3b/0xa0 [ 3.997776] RSP: e02b:ffffc9004018fbe0 EFLAGS: 00010246 [ 3.997779] RAX: 0000000000000000 RBX: ffffc90040199060 RCX: 0000000001d5dfff [ 3.997783] RDX: ffff88003e2c4240 RSI: 0000000000000002 RDI: ffffffff81ac9980 [ 3.997786] RBP: ffffc9004018fbf0 R08: 0000000000001000 R09: ffffffff811d6101 [ 3.997790] R10: 0000000000007ff0 R11: ffffe8ffffffffff R12: 0000000000000002 [ 3.997793] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 3.997803] FS: 0000000000000000(0000) GS:ffff88003f800000(0000) knlGS:0000000000000000 [ 3.997807] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.997812] CR2: ffffc90040199060 CR3: 0000000001a09000 CR4: 0000000000042660 [ 3.997817] Call Trace: [ 3.997825] vlv2_plat_clk_probe+0x3f/0x70 [ 3.997832] platform_drv_probe+0x3b/0xa0 [ 3.997837] driver_probe_device+0x2ff/0x450 [ 3.997842] __device_attach_driver+0x83/0x100 [ 3.997848] ? __driver_attach+0xe0/0xe0 [ 3.997853] bus_for_each_drv+0x69/0xb0 [ 3.997858] __device_attach+0xdd/0x160 [ 3.997863] device_initial_probe+0x13/0x20 [ 3.997867] bus_probe_device+0x92/0xa0 [ 3.997872] device_add+0x451/0x690 [ 3.997877] platform_device_add+0x10d/0x270 [ 3.997884] ? set_debug_rodata+0x17/0x17 [ 3.997888] platform_device_register_full+0xfe/0x110 [ 3.997895] ? vlv2_plat_clk_init+0x19/0x19 [ 3.997901] vlv2_plat_clk_init+0x48/0x82 [ 3.997906] do_one_initcall+0x50/0x190 [ 3.997912] kernel_init_freeable+0x186/0x214 [ 3.997918] ? rest_init+0x90/0x90 [ 3.997923] kernel_init+0xe/0x100 [ 3.997929] ret_from_fork+0x25/0x30 [ 3.997933] Code: 47 83 fe 02 41 89 f4 77 67 48 8b 05 60 49 84 00 48 85 c0 74 48 c1 e7 02 48 63 ff 48 8d 1c 38 48 c7 c7 80 99 ac 81 e8 95 0f 15 00 <8b> 03 83 e0 fc 44 09 e0 89 03 48 c7 c7 80 99 ac 81 e8 6f 09 15 [ 3.997966] RIP: vlv2_plat_configure_clock+0x3b/0xa0 RSP: ffffc9004018fbe0 [ 3.997970] CR2: ffffc90040199060 [ 3.997976] ---[ end trace 43ffeef3f6ee6085 ]--- [ 3.997991] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 3.997991] [ 3.998001] Kernel Offset: disabled .cfg file name = "test" memory = "1024" #root = "/dev/xvdc1" #bootloader = "pygrub" kernel = "/mnt/arch/boot/x86_64/vmlinuz" ramdisk = "/mnt/arch/boot/x86_64/archiso.img" extra = "archisobasedir=arch archisolabel=ARCH_201708" disk = ["archlinux-2017.08.01-x86_64.iso,,xvdc,cdrom,r","/dev/VG/test,,xvda,rw"] vif = [ 'mac=00:22:26:11:21:10,bridge=brint0' ] #boot = "d" Whats wrong? Any ideas?

maldo commented on 2017-08-16 19:33 (UTC)

I can confirm the observation of asura for a fresh arch install. installing spice-glib did work for me as well

asura commented on 2017-08-16 16:17 (UTC)

For anyone having trouble to build this package and getting spice dependency errors ERROR: User requested feature spice configure was not able to find it. Install spice-server(>=0.12.0) and spice-protocol(>=0.12.3) devel Installing community/spice-glib and community/spice-gtk3 solved the issue for me.

maldo commented on 2017-07-23 18:17 (UTC) (edited on 2017-07-23 18:19 (UTC) by maldo)

Hi das_j, just started building for a naked arch... seems autoconf and patch are missing as dependencies

tony_42 commented on 2017-07-20 15:51 (UTC)

Hi das_j, looks like there is a patch for the build failure: https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=672949d6c61d9cba01c5b414eed9d522082f04d3

pew commented on 2017-06-19 12:47 (UTC) (edited on 2017-06-19 22:26 (UTC) by pew)

JohnTh, can you please provide a link for the 4.9-rc8 version that have fixes for the warnings? I've been using this: https://downloads.xenproject.org/release/xen/4.9.0-rc8/ and I'm still getting all the warnings with gcc7. Nevermind, all the errors I was having were for other packages inside of xen (ie qemu, ipxe)

JohnTh commented on 2017-06-07 08:40 (UTC)

The upgrade to gcc7 brings a number of new warnings that show up in building xen-4.8.1 My xen PKGBUILD has diverged a bit from this one, but should build xen 4.8.1 (without stubdom!) https://gitlab.com/johnth/aur-xen/tree/master Either fix the files, or change the C(PP)FLAGS; remove Werror, or use -Wno-error= for each error warning. This needs to be done for each component with error warnings (xen, ipxe, ovmf, vtpm). Most of the warnings have fixes upstream, and are included in xen-4.9.0-rc8. I am unable to build stubdom with the current Arch packages, getting linking errors: ld -nostdlib -L/build/xen/src/xen-4.8.1/stubdom/cross-root-x86_64/x86_64-xen-elf/lib -m elf_x86_64 -T /build/xen/src/xen-4.8.1/stubdom/mini-os-x86_64-vtpmmgr/arch/x86/minios-x86_64.lds /build/xen/src/xen-4.8.1/stubdom/mini-os-x86_64-vtpmmgr/mini-os.o -o /build/xen/src/xen-4.8.1/stubdom/mini-os-x86_64-vtpmmgr/mini-os /build/xen/src/xen-4.8.1/stubdom/mini-os-x86_64-vtpmmgr/mini-os.o: In function `vtpmmgr_GroupRegister': /build/xen/src/xen-4.8.1/stubdom/vtpmmgr/vtpm_cmd_handler.c:555: undefined reference to `tpmrsa_free''

jsteel commented on 2017-06-07 08:17 (UTC)

I think it's an issue with gcc7. I found this patch http://git.ipxe.org/ipxe.git/commitdiff/5f85cbb which gets around the error reported by ArthurBorsboom but then I get a similar error shortly after: [BUILD] bin/ath5k_desc.o drivers/net/ath/ath5k/ath5k_desc.c: In function 'ath5k_hw_setup_2word_tx_desc': drivers/net/ath/ath5k/ath5k_desc.c:106:15: error: this statement may fall through [-Werror=implicit-fallthrough=] frame_type = AR5K_AR5210_TX_DESC_FRAME_TYPE_NO_DELAY; drivers/net/ath/ath5k/ath5k_desc.c:107:3: note: here case AR5K_PKT_TYPE_PIFS: ^~~~

ArthurBorsboom commented on 2017-06-06 09:30 (UTC)

I got a compile error with the latest PKGBUILD (4.8.0-7): drivers/net/igbvf/igbvf_vf.c: In function 'igbvf_promisc_set_vf': drivers/net/igbvf/igbvf_vf.c:359:10: error: this statement may fall through [-Werror=implicit-fallthrough=] msgbuf |= E1000_VF_SET_PROMISC_MULTICAST; drivers/net/igbvf/igbvf_vf.c:360:2: note: here case e1000_promisc_unicast: ^~~~

baratharon commented on 2017-06-03 05:17 (UTC)

I got a compile error with the latest PKGBUILD (4.8.0-7): runtime.c: In function 'efi_compat_get_info': /home/aron/build/xen-4.8.0-7/xen/src/xen-4.8.0/xen/include/asm/x86_64/uaccess.h:58:37: error: '*' in boolean context, suggest '&&' instead [-Werror=int-in-bool-context] compat_access_ok(addr, (count) * (size))) ^ Details: https://pastebin.com/jrb44Mg1

Flubbadub commented on 2017-06-01 09:38 (UTC)

For anyone else using Manjaro (or probably me in the future) the kernels are named differently in Manjaro. I had to apply this patch in order to get the grub menu entried to be generated correctly: diff --git a/etc/grub.d/09_xen b/etc/grub.d/09_xen index 59ac88a..3a41376 --- a/etc/grub.d/09_xen +++ b/etc/grub.d/09_xen @@ -38,11 +38,11 @@ _FUNC_GRUB_FILE_PRESENT() { case "${GRUB_PLATFORM}" in x86) - list="$(for i in "${GRUB_ROOT}"/boot/vmlinuz-linux* ; do + list="$(for i in "${GRUB_ROOT}"/boot/vmlinuz-* ; do if grub_file_is_not_garbage "${i}" && "${grub_file}" ${check} "${i}" ; then echo -n "${i} " ; fi done)" ;; *) - list="$(for i in "${GRUB_ROOT}"/boot/vmlinuz-linux* ; do + list="$(for i in "${GRUB_ROOT}"/boot/vmlinuz-* ; do if grub_file_is_not_garbage "${i}" && "${grub_file}" ${check} "${i}" ; then echo -n "${i} " ; fi done)" ;; esac

Refutationalist commented on 2017-05-31 05:19 (UTC)

I just tried building 4.8.0-7 from a clean install-- I usually do this so I can catch missing dependencies and to control clutter. I got a build failure: https://gist.github.com/anonymous/a8c48f68b086a14407cc0067c222ce00

jsteel commented on 2017-04-04 09:27 (UTC)

Thanks, specifying the seabios file in the PKGBUILD as you suggested worked!

tony_42 commented on 2017-04-03 14:04 (UTC)

@jsteel: I think it's a mistake in the PKGBUILD. It should be: --with-system-seabios=/usr/share/qemu/bios-256k.bin (so with the path to SeaBIOS specified) There should be a path as well for OVMF, but I just realize the package change recently so I don't know if it's going to work with Xen.

jsteel commented on 2017-04-03 12:35 (UTC)

After updating from 4.8.0-4 to 4.8.0-5 I installed seabios but I get an error when booting a domU: libxl: error: libxl_dom.c:892:libxl__load_hvm_firmware_module: failed to read BIOS file: No such file or directory I've gone back to 4.8.0-4 for now. Any idea what else is needed apart from installing seabios for non-UEFI systems now? Thanks.

jonnyt886 commented on 2017-04-03 09:09 (UTC)

Hitting repeated issues building this when downloading ovmf: -> Cloning ovmf git repo... Cloning into bare repository '/tmp/yaourt-tmp-jonny/aur-xen/ovmf'... remote: Counting objects: 240383, done. remote: Compressing objects: 100% (59223/59223), done. remote: Total 240383 (delta 184842), reused 229977 (delta 174449) Receiving objects: 100% (240383/240383), 225.31 MiB | 259.00 KiB/s, done. fatal: unable to open /tmp/yaourt-tmp-jonny/aur-xen/ovmf/objects/pack/tmp_pack_0lHJ2u: No such file or directory fatal: index-pack failed ==> ERROR: Failure while downloading ovmf git repo Aborting... ==> ERROR: Makepkg was unable to build xen. ==> Restart building xen ? [y/N] ==> ---------------------------- Tried removing ovmf from the PKGBUILD (removed all lines referring to ovmf except for the 'optDepends' entry) and then checksum validations fail, but with no file mentioned. And yes I did remove all the ovmf entries! Is anyone else getting this?

commented on 2017-03-28 06:46 (UTC)

Bumped to 4.8.0-5. This version adds XSA-211, splits out SeaBIOS and OVMF and disables Werror (hopefully).

badboy commented on 2017-03-20 09:41 (UTC)

I'd be fine with that.

commented on 2017-03-19 19:32 (UTC)

So what do you guys think about using the system's OVMF and SeaBios? Apart from faster build times because we don't need to build them ourselfs, we also prevent errors like the one of @maldo. Once this is decided, I will push out a new PKGBUILD with the --disable-werror patch and possibly the new SeaBIOS/OVMF.

maldo commented on 2017-03-19 09:01 (UTC) (edited on 2017-03-19 09:02 (UTC) by maldo)

@das_j @badboy @JohnTh @tony_42 I am able to reproduce the makedev issue... and am running in further problems with ovmf ... any leads/ideas? my system: naked arch with base-devel & multilib-devel (multilib enabled) approach: sudo pacman -Syu git clone https://aur.archlinux.org/xen.git makepkg -si ... public key issue with xen4.8.0 makepkg -si --skippgpcheck ... makedev issue tap-ctl-allocate.c: In function 'tap_ctl_make_device': tap-ctl-allocate.c:109:13: error: In the GNU C Library, "makedev" is defined by <sys/sysmacros.h>. For historical compatibility, it is currently defined by <sys/types.h> as well, but we plan to remove this soon. To use "makedev", include <sys/sysmacros.h> directly. If you did not intend to use a system-defined macro "makedev", you should undefine it after including <sys/types.h>. [-Werror] err = mknod(devname, perm, makedev(major, minor)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors applying workaround of tony_42 build() { ... --with-extra-qemuu-configure-args="--disable-bluez --disable-gtk --enable-spice --enable-usb-redir --disable-werror" \ ... make LANG=C PYTHON=python2 APPEND_CFLAGS=-Wno-error dist } makepkg -si --skippgpcheck g/Library/BaseUefiCpuLib/X64/InitializeFpu.nasm > /home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/ovmf-dir-remote/Build/OvmfX64/RELEASE_GCC44/X64/UefiCpuPkg/Library/BaseUefiCpuLib/BaseUefiCpuLib/OUTPUT/X64/InitializeFpu.i /home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/ovmf-dir-remote/MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointer.c: In function 'MigratePeiServicesTablePointer': /home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/ovmf-dir-remote/MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointer.c:100:26: error: variable 'Status' set but not used [-Werror=unused-but-set-variable] EFI_STATUS Status; ^~~~~~ /home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/ovmf-dir-remote/MdePkg/Library/PeiHobLib/HobLib.c: In function 'GetHobList': /home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/ovmf-dir-remote/MdePkg/Library/PeiHobLib/HobLib.c:46:25: error: variable 'Status' set but not used [-Werror=unused-but-set-variable] EFI_STATUS Status; ^~~~~~ /home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/ovmf-dir-remote/MdePkg/Library/PeiHobLib/HobLib.c: In function 'GetBootModeHob': /home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/ovmf-dir-remote/MdePkg/Library/PeiHobLib/HobLib.c:212:26: error: variable 'Status' set but not used [-Werror=unused-but-set-variable] EFI_STATUS Status; ^~~~~~ cc1: all warnings being treated as errors make[7]: *** [GNUmakefile:315: /home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/ovmf-dir-remote/Build/OvmfX64/RELEASE_GCC44/X64/MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt/OUTPUT/PeiServicesTablePointer.obj] Error 1 make[7]: Leaving directory '/home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/ovmf-dir-remote/Build/OvmfX64/RELEASE_GCC44/X64/MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt' build.py... : error 7000: Failed to execute command make tbuild [/home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/ovmf-dir-remote/Build/OvmfX64/RELEASE_GCC44/X64/MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt] build.py... : error 7000: Failed to execute command make tbuild [/home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/ovmf-dir-remote/Build/OvmfX64/RELEASE_GCC44/X64/MdePkg/Library/PeiHobLib/PeiHobLib] build.py... : error F002: Failed to build module /home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/ovmf-dir-remote/MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf [X64, GCC44, RELEASE] - Failed - Build end time: 09:48:44, Mar.19 2017 Build total time: 00:00:10 make[6]: *** [Makefile:19: build] Error 1 make[6]: Leaving directory '/home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/ovmf-dir-remote' make[5]: *** [/home/rnet-master/xenbuild/xen/src/xen-4.8.0/tools/firmware/../../tools/Rules.mk:218: subdir-all-ovmf-dir] Error 2

devnull_1337 commented on 2017-03-18 22:18 (UTC)

@badboy @JohnTh: you can use the following patch for the makedev compile error: --- a/tools/blktap2/control/tap-ctl-allocate.c 2016-04-25 22:33:15.444681888 -0 700 +++ b/tools/blktap2/control/tap-ctl-allocate.c 2016-04-25 22:30:33.288046037 -0 700 @@ -36,6 +36,7 @@ #include <sys/stat.h> #include <sys/types.h> #include <sys/ioctl.h> +#include <sys/sysmacros.h> #include <linux/major.h> #include "tap-ctl.h" --- a/tools/libxl/libxl_osdeps.h 2016-04-25 22:55:04.326527630 -0700 +++ b/tools/libxl/libxl_osdeps.h 2016-04-25 22:53:36.315440845 -0700 @@ -43,6 +43,7 @@ #define SYSFS_PCIBACK_DRIVER "/sys/bus/pci/drivers/pciback" #define NETBACK_NIC_NAME "vif%u.%d" #include <pty.h> +#include <sys/sysmacros.h> #include <uuid/uuid.h> #elif defined(__sun__) #include <stropts.h>

tony_42 commented on 2017-03-14 16:27 (UTC)

You could avoid this kind of warning, now and later, with two modifications in PKGBUILD. When calling ./configure, add "--disable-werror" to --with-extra-qemuu-configure-args. And add APPEND_CFLAGS=-Wno-error to make. So build() would look like this: ./configure \ PYTHON=/usr/bin/python2 \ --prefix=/usr \ --sbindir=/usr/bin \ --with-sysconfig-leaf-dir=conf.d \ --with-initddir=/etc/init.d \ --enable-systemd \ --enable-ovmf \ "${_config_stubdom:---disable-stubdom}" \ --with-extra-qemuu-configure-args="--disable-bluez --disable-gtk --enable-spice --enable-usb-redir --disable-werror" make LANG=C PYTHON=python2 APPEND_CFLAGS=-Wno-error dist

commented on 2017-03-13 06:50 (UTC)

@badboy: Fixed the architecture problem, split packages are weird. @badboy @JohnTh: I can not reproduce the problem here. I'm running a fully updated Arch. Do you have any changed values in /etc/makepkg.conf?

JohnTh commented on 2017-03-13 04:38 (UTC)

@badboy I'm seeing that too after updating Arch. To resolve, Need to add this include to relevant Xen source files, where minor(), major(), or makedev() are used. #include <sys/sysmacros.h> I found these with grep -R ' \(major\|minor\|makedev\)('. Not sure if they are the correct locations, or implementation: tools/blktap2/control/tap-ctl-allocate.c tools/libxl/libxl_internal.h tools/qemu-xen/include/qemu/osdep.h My patch here https://gitlab.com/johnth/aur-xen/raw/master/patch-include_sys_sysmacros.h.patch Details: glibc 2.25 https://sourceware.org/glibc/wiki/Release/2.25 "The inclusion of sys/sysmacros.h by sys/types.h is deprecated. Using the macros major, minor, or makedev without having directly included sys/sysmacros.h will trigger compiler warnings."

badboy commented on 2017-03-12 17:52 (UTC)

I get another error, but that seems like it needs to go upstream: $ makepkg -As --skippgpcheck [...] tap-ctl-allocate.c: In function 'tap_ctl_make_device': tap-ctl-allocate.c:109:13: error: In the GNU C Library, "makedev" is defined by <sys/sysmacros.h>. For historical compatibility, it is currently defined by <sys/types.h> as well, but we plan to remove this soon. To use "makedev", include <sys/sysmacros.h> directly. If you did not intend to use a system-defined macro "makedev", you should undefine it after including <sys/types.h>. [-Werror] err = mknod(devname, perm, makedev(major, minor));

badboy commented on 2017-03-11 22:40 (UTC)

For some reason I get an error on my 64bit machine: ==> ERROR: xen is not available for the 'x86_64' architecture.

lazycat commented on 2017-03-11 03:50 (UTC)

@das_j, @JohnTh Thank you for answers :)

commented on 2017-03-09 11:53 (UTC)

@lazycat @JohnTh I'm currently updating the package. However, it takes me longer to test, because I only have a really slow machine right now. I'm also adding xen-docs and turn this package into a split package. Update should roll out today.

JohnTh commented on 2017-03-09 11:39 (UTC)

@lazycat The Arch lzo package has changed, and no longer "provides" lzo2. I think you will need to rebuild and upgrade the Xen package to remove the error/ignore. You should be able to change lzo2 to lzo (line 74?) in the depends array in the Xen PKGBUILD. Then rebuild. lzo package change here https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/lzo&id=eb70476e9442d349f3c353e91631c0e713781c07 I would suggest you use multilib-build (from the Arch package devtools) to build in a clean chroot. See how that goes.

lazycat commented on 2017-03-09 09:10 (UTC)

New headache. Can't make system upgrade with pacman -Syu, get error: error: failed to prepare transaction (could not satisfy dependencies) :: xen: installing lzo (2.10-1) breaks dependency 'lzo2' I'm solve it temporally with #IgnorePkg = lzo lzo2, but it's not a good, I guess. Any ideas?

JohnTh commented on 2017-02-26 22:02 (UTC)

@ArgylePwnage gpg --keyserver pgp.mit.edu --recv-key 23E3222C145F4475FA8060A783FE14C957E82BD9 This command should solve that problem. You need to import the Xen Project tree code signing OpenPGP key 23E3222C145F4475FA8060A7(83FE14C957E82BD9) into your gpg keyring. The key is detailed here: https://www.xenproject.org/developers/teams/hypervisor/openpgp.html Otherwise, you can use a command line option with makepkg, or modify the PKGBUILD to remove this check. Have a look through the man pages or comments on the AUR Xen page for more details.

commented on 2017-02-26 14:42 (UTC)

Hello, I have received the following error message: PGP signatures could not be verified for public key "83FE14C957E82BD9". Can you advise? Thank you for your time.

lazycat commented on 2017-01-20 02:34 (UTC)

@JohnTh, Yeah, your config file was really helpful for me, i successfully start arch live cd. But i understood that it is really bad idea to try to build completely work machine with 512 MB ram :D Thank you so much.

JohnTh commented on 2017-01-18 03:39 (UTC) (edited on 2017-01-18 04:00 (UTC) by JohnTh)

@lazycat Yes, possible to use Xen guest with little RAM. May need to boot your arch installer differently though. If you show your config, we will have a better idea. Working config for me, needs arch install iso. name='archtest' disk=['archlinux-2017.01.01-dual.iso, , xvdc, cdrom'] memory='256' root = '/dev/xvdc' bootloader='pygrub' kernel = "arch/boot/x86_64/vmlinuz" ramdisk = "arch/boot/x86_64/archiso.img" extra = "archisobasedir=arch archisolabel=ARCH_201701" boot='d'

lazycat commented on 2017-01-18 03:12 (UTC)

@JohnTh, It is possible use xen with config less then 1500M ram?

JohnTh commented on 2017-01-18 03:08 (UTC)

Good to see maintainer! When trying to boot PV archiso / archboot guest: I get "Initramfs unpacking failed: write error" when there is not enough memory to unpack the ramdisk to memory. I found the archboot64 I tried needed 1500MB memory.

lazycat commented on 2017-01-18 03:03 (UTC)

@das_j Thank you, it's really cool :) Successfully compile and install it, but still have problem with paravirt PV domU.. Trying to create guest with xl create -c and receive [ 0.120463] dmi: Firmware registration failed. [ 5.189734] Initramfs unpacking failed: write error Any ideas? My pc is junk? xD Or I doing something wrong?

commented on 2017-01-17 20:24 (UTC)

@riaqn @lazycat I fixed the package and bumped the pkgrel. I can boot it, hopefully you can as well.

lazycat commented on 2017-01-16 07:24 (UTC)

@riaqn Hello! Have same problem - cannot create correct cfg for grub (add new boot entry to grub) with 09_xen Any ideas?

commented on 2017-01-15 12:33 (UTC)

@riaqn No, this should not matter. I will check once I get home, but maybe not until tomorrow.

riaqn commented on 2017-01-15 05:03 (UTC)

It's probably just me: but in the compiled package, there is only a symlink from boot/xen-4.8.gz to xen-4.8.0.gz, but no xen-4.8.0.gz itself, which is necessary if I want to boot via grub? Do I have to compile on a grub-booted system(as opposed to efi-booted) to get this file in the package?

commented on 2017-01-12 22:59 (UTC)

Adopted package as nobody else seemed to be interested. @John if you still are interested, contact me :) Updated to 4.8, hope I didn't break anything. Removed a lot of patches that are not needed anymore and updated XSAs. I also removed the ati-passthrough patch as it was for Xen 4.4 and didn't apply anymore.

lazycat commented on 2017-01-10 09:23 (UTC)

Hello all! Trying to create Xen PV domU, receive this: [ 0.167092] dmi: Firmware registration failed. [ 5.308116] Initramfs unpacking failed: write error ...and later :: Mounting '/dev/disk/by-label/ARCH_201701' to '/run/archiso/bootmnt' ERROR: '/dev/disk/by-label/ARCH_201701' device did not show up after 30 seconds... Falling back to interactive prompt You can try to fix the problem manually, log out when you are finished sh: can't access tty; job control turned off [rootfs ]# What I'm doing wrong?

ArthurBorsboom commented on 2016-12-11 08:59 (UTC)

I have disowned the package since I have no added value anymore. My preference goes to John maintaining the package. If it doesn't work (so I can test), you will here in the comment box here. :) Package is currently unmaintained.

JohnTh commented on 2016-12-07 07:31 (UTC)

Hi, xen-4.8.0 release has been tagged on xen git. I have update my master to use it and it needs testing. No release notes yet though. https://gitlab.com/johnth/aur-xen/ I included Xen's PGP signature in the PKGBUILD. Install the key (confirm here: https://www.xenproject.org/developers/teams/hypervisor/openpgp.html) with, as the user you build with: gpg --keyserver pgp.mit.edu --recv-key 23E3222C145F4475FA8060A783FE14C957E82BD9 Or use --skippgpcheck, or comment out the .sig and SKIP sha256sum for it in PKGBUILD. I am still unable to test, sorry, and am not happy maintaining until I can as it makes it too hard to troubleshoot. Cheers

bacondropped commented on 2016-11-18 15:25 (UTC)

@ParadoxSpiral @JohnTh The build failed as well on my Manjaro machine with the same relocation errors. I've had this problem before, this seems to happen thanks to 'hardening-wrapper', which forces PIC/PIE, which in turn has its problems when sub-libraries do not configure CFLAGS correctly. I solved the problem by building this package in a clean Arch VM (overkill, I know, but it worked fine).

bacondropped commented on 2016-11-18 15:21 (UTC) (edited on 2016-11-18 18:39 (UTC) by bacondropped)

Perhaps this project could provide 'xenstore'? https://www.archlinux.org/packages/extra/x86_64/pulseaudio-xen/ requires it, and the 'xenstore' package conflicts with this one. (NOTE: Although, for instance, pulseaudio-xen required libxenctrl.so.4.0 which xenstore provides, so this change would be breaking; but it'd be an update, so...)

Refutationalist commented on 2016-11-12 04:47 (UTC)

@JohnTh: 4.7.1-2 fixed it. Additionally, Xen resumed a vm across the upgrade and boots, which is the first time that's worked in a while without a lot of finagling.

ArthurBorsboom commented on 2016-11-11 16:07 (UTC)

@JohnTh: "I will think about maintaining"... and? :)

JohnTh commented on 2016-11-11 12:05 (UTC)

@Refutationalist See if the latest commit on my gitlab repository fixes this? It applies this patch: http://xenbits.xen.org/gitweb/?p=xen.git;a=patch;h=9714f6b87e19b32d3a6663a20df6610265c4bfe5 Discussed here: https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg02889.html cheers

Refutationalist commented on 2016-11-11 09:22 (UTC) (edited on 2016-11-11 09:23 (UTC) by Refutationalist)

@JohnTh Your recent commit to 4.7.1 and pv-grub doesn't seem to boot w/ pv-grub x86_64. I'm going use an earlier pv-grub, but this is a dev server so I can test packages, if that helps. Here's the failure: ============= Init TPM Front ================ Tpmfront:Error Unable to read device/vtpm/0/backend-id during tpmfront initialization! error = ENOENT Tpmfront:Info Shutting down tpmfront pin_table(x) returned 850876 Error 9: Unknown boot failure Press any key to continue...

JohnTh commented on 2016-11-02 20:15 (UTC)

Hi, A patch was released to fix stubdom compile. This should give access to pvgrub. This package needs testing before being pushed (I haven't been able to do any). https://gitlab.com/johnth/aur-xen/ With this patch and indentation fixed in stubdom/vtpmmgr/{log.c,disk_read.c}, the package appears to compile. https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=668e4edf92fcf7cb929eed221059a3eeb02722c3 Cheers.

ParadoxSpiral commented on 2016-10-30 11:26 (UTC)

Building with `multilib-build` works. However when installing with `yaourt -U ..`, there are conflicting files with the xenstore package: http://sprunge.us/ZhNj When removed, xen installs correctly. Thanks for your assistance o7.

JohnTh commented on 2016-10-29 21:51 (UTC)

I would strongly suggest you use multilib-build from the devtools package (as opposed to yaourt) for this package. That way we get the same build environment. Otherwise, update, and see if you still get the error. https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot Yes, I noticed a build failed in the same place (OVMF) on my CI three days ago (on the 27th), but the days before and after have built fine. https://gitlab.com/johnth/aur-xen/pipelines I will think about maintaining.

ParadoxSpiral commented on 2016-10-29 10:25 (UTC)

Hello, building this package fails. http://sprunge.us/LcKE When I manually add -fpic to the gcc args in aur-xen/src/xen-4.7.0/tools/firmware/ovmf-dir-remote/BaseTools/Source/C/Makefiles/header.makefile the build fails again. http://sprunge.us/dFDE Using the PKGBUILD by @JohnTh doesn't work either.

ArthurBorsboom commented on 2016-10-22 12:14 (UTC)

@JohnTh, are you interested in maintaining this package, since you are already doing that on gitlab?

Just-Punk commented on 2016-10-17 21:22 (UTC)

a)thanx for package PKGBUILD I tried to create it myself but I lost on python-dev dependency. b) Xen wasn't build succesfull with stubdom option: (i have ukrainian locale, some parts of output was translated myself with *TRANSLATED mark) ....... checking how to define a 32-bit word... .long checking if .align assembly directive is logarithmic... no checking if the .align directive accepts an 0x90 fill in .text... yes checking for unsigned short... yes checking size of unsigned short... configure: error: cannot compute sizeof (unsigned short) See `config.log' for more details. make[1]: *** [Makefile:174: gmp-x86_64] Error 77 make[1]: Leaving directory '/tmp/yaourt-tmp-carbon/aur-xen/src/xen-4.7.0/stubdom' make: *** [Makefile:105: install-stubdom] Помилка 2 (*TRANSLATED: Error 2 ) ==> ПОМИЛКА: Стався збій у build(). (*TRANSLATED: Error: Failed in build())    Припинення... (*TRANSLATED: Stopped) ==> ПОМИЛКА: Makepkg не може створити xen. (*TRANSLATED: Makepkg can't create xen) ==> Розпочати знову побудову xen ? так/Ні [y/N] (*TRANSLATED: Start again build xen?) ==> ------------------------------------------- c) Wthout stubdom compiled OK. When I'll done successful xen settings & I'll start guest OS, I'll post about. Thanx

Just-Punk commented on 2016-10-17 21:22 (UTC)

a)thanx for package PKGBUILD I tried to create it myself but I lost on python-dev dependency. b) Xen wasn't build succesfull with stubdom option: (i have ukrainian locale, some parts of output was translated myself with *TRANSLATED mark) ....... checking how to define a 32-bit word... .long checking if .align assembly directive is logarithmic... no checking if the .align directive accepts an 0x90 fill in .text... yes checking for unsigned short... yes checking size of unsigned short... configure: error: cannot compute sizeof (unsigned short) See `config.log' for more details. make[1]: *** [Makefile:174: gmp-x86_64] Error 77 make[1]: Leaving directory '/tmp/yaourt-tmp-carbon/aur-xen/src/xen-4.7.0/stubdom' make: *** [Makefile:105: install-stubdom] Помилка 2 (*TRANSLATED: Error 2 ) ==> ПОМИЛКА: Стався збій у build(). (*TRANSLATED: Error: Failed in build())    Припинення... (*TRANSLATED: Stopped) ==> ПОМИЛКА: Makepkg не може створити xen. (*TRANSLATED: Makepkg can't create xen) ==> Розпочати знову побудову xen ? так/Ні [y/N] (*TRANSLATED: Start again build xen?) ==> ------------------------------------------- c) Wthout stubdom compiled OK. When I'll done successful xen settings & I'll start guest OS, I'll post about. Thanx

ArthurBorsboom commented on 2016-10-08 13:41 (UTC)

Please keep in mind for Xen on EFI to work on kernel 4.7.x, you need to compile the linux kernel with this patch: http://lkml.iu.edu/hypermail/linux/kernel/1608.2/03448.html

ArthurBorsboom commented on 2016-10-08 11:30 (UTC)

Since the old package was broken, John's package has replaced the old package. Please be defensive for production systems and give your feedback, so I know if the package works or needs improvements.

ArthurBorsboom commented on 2016-10-08 08:06 (UTC)

Hi John, Why don't we try to merge your PKGBUILD into this package (or the other way around)? Are you in for that?

JohnTh commented on 2016-10-06 19:55 (UTC)

There is a rather wild xen-4.7 PKGBUILD here: https://gitlab.com/johnth/aur-xen I have only tested it EFI booting (with refind) on Intel. XSA-190 has not yet been added to that. Cheers.

ArthurBorsboom commented on 2016-10-06 17:56 (UTC)

I just noticed the package has been disowned. I have adopted the package and I will give it a try to upgrade it... Any help is appreciated.

ArthurBorsboom commented on 2016-10-06 17:54 (UTC)

Any indication to upgrade the package to 4.7? Need help?

daniel_shub commented on 2016-08-30 18:24 (UTC)

I also cannot build 4.5.1 in a clean chroot. It looks like Xen has moved on to 4.7.0: https://www.xenproject.org/downloads/xen-archives/supported-xen-project-47-series/xen-470.html @kantras any chance of getting an update or taking on a co-maintainer to help out. The PKGBUILD is way beyond my comfort level to help with and I don't really have hardware to test on so I am really of no help.

cypher_zero commented on 2016-08-25 02:56 (UTC) (edited on 2016-08-25 03:00 (UTC) by cypher_zero)

Package is currently broken; needs to be updated to support GCC 6, etc. Have tried modifying current PKGBUILD with -Wno-misleading-indentation flag on line 129: export CFLAGS='-fno-caller-saves -Wno-misleading-indentation' makepkg still fails to build.

nevr0sed commented on 2016-08-17 09:31 (UTC)

Hi, Can't compile from the AUR repo. Here I get this error, same as the last comment. non-fatal.c: In function 'init_nonfatal_mce_checker': non-fatal.c:97:5: error: this 'if' clause does not guard... [-Werror=misleading-indentation] if ( __get_cpu_var(poll_bankmask) == NULL ) ^~ non-fatal.c:103:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if' switch (c->x86_vendor) { ^~~~~~ after looking around a bit, it seems that the the 4.5.3 fixes this issues. Can the maintainer of this package update it ? Thanks. n.

xiangzhai commented on 2016-08-12 02:28 (UTC)

non-fatal.c: In function 'init_nonfatal_mce_checker': non-fatal.c:97:5: error: this 'if' clause does not guard... [-Werror=misleading-indentation] if ( __get_cpu_var(poll_bankmask) == NULL ) ^~

newsboost commented on 2016-07-23 20:52 (UTC) (edited on 2016-07-24 13:28 (UTC) by newsboost)

I tried many times, but couldn't make this work - as other people also wrote... I then first re-compiled binutils ( http://stackoverflow.com/questions/20858175/how-to-boot-xen-hypervisor-from-uefi-using-gummiboot-under-arch-linux ) and then did "git clone https://gitlab.com/johnth/aur-xen/" followed by "makepkg" and maybe here I had to do "pacman -S mingw-w64-binutils" and finally "pacman -U xen-4.7.0-1-x86_64.pkg.tar.xz". xen-4.7.0-1 seemed to be installed, however I couldn't make xen work. This is the first time for me on arch linux. Later I downloaded https://gitlab.com/johnth/aur-xen/tree/xen-4.6 and repeated. I think this is better, although now I want to see if I can make it work with virt-manager. Just a hint of advice for anyone else who like me couldn't get the official arch Xen to work...

lazycat commented on 2016-06-20 07:58 (UTC)

Hello all, this package fails to create domU after update libiscsi from libiscsi-1.13.0-1-x86_64 to libiscsi-1.17.0-2-x86_64, After this update it's can't find "libiscsi.so.4" Downgrade is helpful.

daniel_shub commented on 2016-04-04 16:22 (UTC)

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

kantras commented on 2016-04-04 16:15 (UTC)

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

daniel_shub commented on 2016-04-04 16:11 (UTC)

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

frony0 commented on 2016-04-04 15:57 (UTC)

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

BeepDog commented on 2016-03-29 00:36 (UTC)

I used the 4.6.1 packages that @JohnTh provided on gitlab: https://gitlab.com/johnth/aur-xen/tree/master Works great, but does not include pvgrub (I guess that's part of stubdom?) I've got a feature request open for grub2 in core to include the PvGrub2 stuff: http://wiki.xen.org/wiki/PvGrub2 and https://bugs.archlinux.org/task/44201 I'm gonna try to build a custom grub package real quick so I can use that pvgrub2, because it's supposed to be WAY better than pvgrub and pygrub.

vmaffione commented on 2016-03-17 21:46 (UTC) (edited on 2016-03-17 21:48 (UTC) by vmaffione)

I managed to compile it, by means of the following changes 1) do what hypernetoman suggests (removing a comment in a public header file) 2) applying this patch to PKGBUILD --- PKGBUILD 2016-03-17 22:45:49.670416160 +0100 +++ PKGBUILD.old 2016-03-17 22:45:31.183750160 +0100 @@ -129,7 +129,7 @@ build() { export CFLAGS=-fno-caller-saves ./autogen.sh ./configure PYTHON=/usr/bin/python2 --prefix=/usr --sbindir=/usr/bin --with-sysconfig-leaf-dir=conf.d --with-initddir=/etc/init.d \ - --enable-systemd --disable-docs --enable-stubdom --enable-qemu-traditional --enable-rombios \ + --enable-systemd --disable-docs --disable-stubdom --enable-qemu-traditional --enable-rombios \ --with-extra-qemuu-configure-args="--disable-bluez --disable-gtk --enable-spice --enable-usb-redir" # --enable-ovmf make LANG=C PYTHON=python2 } @@ -147,6 +147,9 @@ package() { install -Dm755 "$srcdir/09_xen" etc/grub.d/09_xen install -Dm644 "$srcdir/efi-xen.cfg" etc/xen/efi-xen.cfg + mkdir -p usr/lib/systemd/system + cp $srcdir/$pkgname-$pkgver/tools/hotplug/Linux/systemd/xenstored* usr/lib/systemd/system + # Fix paths in scripts, move to right locations and create missing directories sed -i 's:/var/run:/run:' etc/init.d/xencommons sed -i 's:/var/lock:/run/lock:' etc/xen/scripts/hotplugpath.sh

lembang commented on 2016-03-01 20:56 (UTC)

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

JohnTh commented on 2016-02-29 22:09 (UTC)

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

lembang commented on 2016-02-29 00:49 (UTC)

@malinas Seems we encounter almost the same error, i have already use gcc-multilib and still experience this error. Any idea? pacman -Q | grep gcc gcc-libs-multilib 5.3.0-5 gcc-multilib 5.3.0-5 lib32-gcc-libs 5.3.0-5 checking size of unsigned short... configure: error: cannot compute sizeof (unsigned short) See `config.log' for more details. Makefile:170: recipe for target 'gmp-x86_64' failed make[1]: *** [gmp-x86_64] Error 77 make[1]: Leaving directory '/home/the/aur/aur-xen-master-d1563f51708bc0cd58e989c7e9ab615254c66d6b/src/xen-4.6.1/stubdom' Makefile:106: recipe for target 'install-stubdom' failed make: *** [install-stubdom] Error 2 ==> ERROR: A failure occurred in build().

malinas commented on 2016-02-26 19:38 (UTC)

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

malinas commented on 2016-02-26 18:18 (UTC)

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

JohnTh commented on 2016-02-19 11:51 (UTC)

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

hypernetoman commented on 2016-02-18 20:58 (UTC)

Hi! Below is the full PKGBUILD for xen-docs updated to 4.5.1 so it is aligned with xen. Hope it helps. # Maintainer: M0Rf30 pkgname=xen-docs pkgver=4.5.1 pkgrel=1 pkgdesc="Xen 4 (docs)" arch=('i686' 'x86_64') url="http://xen.org/" license=('GPL') makedepends=('markdown' 'transfig' 'ghostscript') conflicts=('xen4' 'xen3' 'xen-hv-tools' 'libxen4') source=(http://bits.xensource.com/oss-xen/release/${pkgver}/xen-${pkgver}.tar.gz) package() { cd "$srcdir/xen-$pkgver" unset CFLAGS LDFLAGS ./configure --prefix=/usr --disable-xen --disable-tools --disable-stubdom --enable-docs make DESTDIR=$pkgdir install-docs } md5sums=('d12dc9e5e8bd22a68b5c7f53119221f1')

hypernetoman commented on 2016-02-18 20:47 (UTC)

Hello! I was getting a compilation error both with xen-4.5.1 and xen-4.4.2 (packages xen and xen-4.4, resp.): gcc -E ... -o compat/grant_table.i compat/grant_table.c compat/grant_table.c:33:1: error: unterminated comment /* ^ compat/grant_table.c:28:0: error: unterminated #ifndef #ifndef __XEN_PUBLIC_GRANT_TABLE_H__ ^ Makefile:61: recipe for target 'compat/grant_table.i' failed make[3]: *** [compat/grant_table.i] Error 1 I've fixed it by adding this in the PKGBUILD previous to `make LANG=C PYTHON=python2` in build(): `sed -i.backup '33,54d' xen/include/public/grant_table.h` It removes the offendig block comment which prevents compilation. It fixes it for me both in xen and xen-4.4. Hope it helps.

EndlessEden commented on 2016-02-18 06:49 (UTC)

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

KamijouTouma commented on 2016-01-18 08:12 (UTC)

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

alaricljs commented on 2016-01-05 22:09 (UTC)

Recently did an orphaned package cleanup and lost a couple of xen-required libs: #> pacman -Qi vde2 libnl |egrep "Name|Required" Name : vde2 Required By : None Name : libnl Required By : libpcap Without libnl 'xl -list' doesn't work (and no doubt more) Without vde2 hvm VMs don't work

jakogut commented on 2015-12-21 22:36 (UTC)

It seems binutils dropped support for PE binary linking, which broke the EFI binary generation in the Xen build process. The Fedora guys made a patch to replace it with mingw64, which you can find here: https://github.com/jakogut/xen-igvtg-aur/blob/master/xen_efi_build.patch

kline commented on 2015-12-17 04:19 (UTC) (edited on 2015-12-17 04:20 (UTC) by kline)

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

baratharon commented on 2015-11-30 07:09 (UTC)

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

bullekeup commented on 2015-11-29 19:47 (UTC)

If you want to try with the latest Xen release (4.5.2) and an updated PKGBUILD, I've put my modifications on my personal website and I'm waiting for feedback before requesting merging. It may solve some building issues encountered before and also enables OVMF support (tested on an Ubuntu 15.10 VM). https://www.bullekeup.net/files/arch/packages/xen/srctarballs/ xen-ovmf packages are intended for people who want a standard Bios Xen boot, xen-efi is for people who want to actually boot xen via efi. Last one needs a PEP enabled binutils, which PKGBUILD is available here : https://www.bullekeup.net/files/arch/packages/binutils-pep/srctarballs/

baratharon commented on 2015-11-22 18:01 (UTC)

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

bullekeup commented on 2015-11-11 00:44 (UTC) (edited on 2015-11-13 00:24 (UTC) by bullekeup)

@ImATiger : I'm unable to reproduce the problem you encounter... I just have rebuild xen from scratch, just to be sure, no problem... Maybe a network problem ? (proxy, DNS, ...) @ata : You need to apply the patch supplied earlier (see previous comments) in order to be able to compile 32 bit executables. Or you can apply this patch for the PKGBUILD, with build dependencies on each package instead of multilib-devel meta package: --- PKGBUILD 2015-07-05 01:43:49.000000000 +0200 +++ PKGBUILD_new 2015-11-11 01:32:11.575921000 +0100 @@ -14,6 +14,7 @@ depends=(bridge-utils curl gnutls iproute2 libaio libcap-ng libiscsi libjpeg-turbo libpng libseccomp lzo2 nss pixman pciutils python python2 sdl yajl spice usbredir) [[ "$CARCH" == "x86_64" ]] && depends+=(lib32-glibc) makedepends=(bin86 cmake dev86 git iasl markdown ocaml-findlib figlet wget spice-protocol) +[[ "$CARCH" == "x86_64" ]] && makedepends+=(gcc-multilib lib32-fakeroot lib32-libltdl) optdepends=('xen-docs: Official Xen Documentation' 'openvswitch: Optional Networking support') conflicts=(xen-4.2{,-testing-hg} xen-{gdbsx,hg-unstable,rc,git} xen-4.3{,-testing-hg}) backup=(etc/modules-load.d/$pkgname.conf etc/$pkgname/xl.conf etc/conf.d/xen{stored,consoled,domains,commons} etc/$pkgname/grub.conf) @cokomoko : Have you enough RAM available to compile the package ? I had issues in the past with many packages because they were to heavy to be compiled in RAM and since yaourt works in RAM by default (tmpfs)... Maybe try compiling the package yourself outside /tmp ? If this is not the problem, I don't think it is linked with makepkg / AUR system (I personally have successfully build this package several times). Maybe try searching in Xen mailing lists, and report your issue upstream if needed.

ImATiger commented on 2015-11-10 04:26 (UTC)

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

ata commented on 2015-11-08 16:47 (UTC)

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

cokomoko commented on 2015-11-03 23:39 (UTC) (edited on 2015-11-03 23:42 (UTC) by cokomoko)

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

kantras commented on 2015-11-03 22:56 (UTC)

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

bullekeup commented on 2015-11-03 22:42 (UTC) (edited on 2015-11-03 22:43 (UTC) by bullekeup)

@cokomoko The bug you have is an old one (see http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01687.html) It was related to a misdeclared array in symbols.c : symbols_offsets array was declared with a size of 4 bytes (an integer, even on 64 bit machines by default), triggering a warning / error on accesses bellow that size when building w/ some compilers (which is normal). But it has been patched since then (verified in current source tarball) I just builded Xen 4.5.1 on a fresh installed Arch (using patch provided before) without problem. May be try updating your system and do a clean build of the package ?

cokomoko commented on 2015-11-03 22:07 (UTC)

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

bullekeup commented on 2015-11-03 21:43 (UTC)

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

cokomoko commented on 2015-11-03 18:49 (UTC)

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

ephreal commented on 2015-10-26 20:13 (UTC)

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

phg commented on 2015-10-22 05:51 (UTC)

Btw. I traced it down to the invocation of ``autogen.sh`` in ``build()``: If I comment that line, the package again builds and installs flawlessly. Since the package builds nicely without, is there any real need for calling autotools explicitly instead of just using the configure scripts that ship with the source?

phg commented on 2015-10-21 18:33 (UTC)

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

trixpan commented on 2015-10-17 18:55 (UTC)

multilib sorted compiling issues in here as well. However, after a successful build I had: Blank xenstore after boot (visible by Dom0 showing up as null) Unable to start any VM with a NIC.

NicolasCPA commented on 2015-10-13 05:23 (UTC)

@zootboy: Thanks.

zootboy commented on 2015-10-13 04:46 (UTC)

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

kantras commented on 2015-08-31 15:41 (UTC)

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

daniel_shub commented on 2015-08-31 14:56 (UTC)

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

pdc commented on 2015-08-29 13:13 (UTC)

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

daniel_shub commented on 2015-08-24 22:31 (UTC)

I am unable to build the package in an clean x86_64 chroot: ERROR: User requested feature spice configure was not able to find it. Install spice-server and spice-protocol devel make[3]: Entering directory '/build/xen/src/xen-4.5.1/tools/qemu-xen-dir' make[3]: *** No rule to make target 'all'. Stop. make[3]: Leaving directory '/build/xen/src/xen-4.5.1/tools/qemu-xen-dir' Makefile:201: recipe for target 'subdir-all-qemu-xen-dir' failed make[2]: *** [subdir-all-qemu-xen-dir] Error 2 make[2]: Leaving directory '/build/xen/src/xen-4.5.1/tools' /build/xen/src/xen-4.5.1/tools/../tools/Rules.mk:111: recipe for target 'subdirs-install' failed make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory '/build/xen/src/xen-4.5.1/tools' Makefile:69: recipe for target 'install-tools' failed make: *** [install-tools] Error 2

jakogut commented on 2015-08-13 21:40 (UTC)

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

Timizki commented on 2015-08-13 16:02 (UTC)

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

Timizki commented on 2015-08-13 15:17 (UTC)

The actual problem is not those "unrecognized command line option -V" "unrecognized command line option -qversion" errors but the compile error in the newlib-x86_32 module. Atleast in x86_64 arch. My config.log file taken from newlib-x86_32 build can be found at http://pastebin.com/HHPMeTPx

risk commented on 2015-08-10 08:31 (UTC)

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

alaviss commented on 2015-08-06 14:33 (UTC)

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

nocko commented on 2015-08-04 16:59 (UTC)

Updated spice-protocol 0.12.9 PKGBUILD: # $Id$ # Maintainer: Sergej Pupykin <pupykin.s+arch@gmail.com> # Maintainer: Patryk Kowalczyk < patryk at kowalczyk dot ws> pkgname=spice-protocol pkgver=0.12.9 pkgrel=1 pkgdesc="Headers for SPICE protocol" arch=(any) url="http://spice-space.org" license=('BSD' 'LGPL2.1') source=(http://spice-space.org/download/releases/$pkgname-$pkgver.tar.bz2) build() { cd "$srcdir/$pkgname-$pkgver" ./configure --prefix=/usr make } package() { cd "$srcdir/$pkgname-$pkgver" make DESTDIR="$pkgdir/" install install -Dm644 COPYING "$pkgdir/usr/share/licenses/$pkgname/COPYING" } md5sums=('893d9940cd34428f92997f4b634484d3')

nocko commented on 2015-08-04 15:58 (UTC)

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

kantras commented on 2015-08-01 20:43 (UTC)

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

ArthurBorsboom commented on 2015-08-01 16:33 (UTC)

Read below...

polyzium commented on 2015-08-01 14:59 (UTC)

After solving "i have no idea" problem, the compiling still fails. "ERROR: User requested feature spice configure was not able to find it. Install spice-server and spice-protocol devel" I have spice and spice-protocol installed

polyzium commented on 2015-08-01 14:33 (UTC)

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

ArthurBorsboom commented on 2015-07-23 08:50 (UTC)

@piwwo, I did the same.

piwwo commented on 2015-07-23 08:28 (UTC)

Ok that works for me with multilib, however not with spice, not even with spice-protocol-git. I removed spice from config for now. pacman -Q spice spice-protocol-git spice 0.12.5-1 spice-protocol-git 20121019-2

kantras commented on 2015-07-21 13:29 (UTC)

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

piwwo commented on 2015-07-21 09:24 (UTC)

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

ArthurBorsboom commented on 2015-07-19 16:46 (UTC)

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

kantras commented on 2015-07-19 02:25 (UTC)

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

ArthurBorsboom commented on 2015-07-14 20:55 (UTC)

@kantras: I experience the same issue as piwwo. - spice disabled - same gcc, no multilib - kernel 4.0.7-2

piwwo commented on 2015-07-13 09:56 (UTC)

Uhm I think I am using gcc. # pacman -Q gcc gcc 5.1.0-5 Package gcc-multilib was not found. Here is the config log http://pastebin.com/sLcCpzvG

kantras commented on 2015-07-10 23:19 (UTC)

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

kantras commented on 2015-07-10 22:43 (UTC)

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

nocko commented on 2015-07-10 14:57 (UTC)

cd qemu-xen-dir; \ $source/configure --enable-xen --target-list=i386-softmmu \ --enable-debug --enable-trace-backend=stderr \ --prefix=/usr/lib/xen \ --libdir=/usr/lib/xen/lib \ --includedir=/usr/lib/xen/include \ --source-path=$source \ --extra-cflags="-I/home/nock/Downloads/xen/src/xen-4.5.1/tools/../tools/include \ -I/home/nock/Downloads/xen/src/xen-4.5.1/tools/../tools/libxc/include \ -I/home/nock/Downloads/xen/src/xen-4.5.1/tools/../tools/xenstore/include \ -I/home/nock/Downloads/xen/src/xen-4.5.1/tools/../tools/xenstore/compat/include \ " \ --extra-ldflags="-L/home/nock/Downloads/xen/src/xen-4.5.1/tools/../tools/libxc \ -L/home/nock/Downloads/xen/src/xen-4.5.1/tools/../tools/xenstore \ -Wl,-rpath,/usr/lib/xen/lib" \ --bindir=/usr/lib/xen/bin \ --datadir=/usr/share/qemu-xen \ --localstatedir=/var \ --disable-kvm \ --disable-docs \ --disable-guest-agent \ --python=python2 \ --disable-bluez --disable-gtk --enable-spice --enable-usb-redir \ --cpu=x86_64 \ ; \ make all ERROR: User requested feature spice configure was not able to find it. Install spice-server and spice-protocol devel related config.log: In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0: /usr/include/spice-server/spice.h:475:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_INVALID’ SPICE_IMAGE_COMPRESS_INVALID = 0, ^ In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0, from /usr/include/spice-server/spice.h:23, from /tmp/qemu-conf-25875-31202-17030.c:1: /usr/include/spice-1/spice/enums.h:185:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_INVALID’ was here SPICE_IMAGE_COMPRESS_INVALID, ^ In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0: /usr/include/spice-server/spice.h:476:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_OFF’ SPICE_IMAGE_COMPRESS_OFF = 1, ^ In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0, from /usr/include/spice-server/spice.h:23, from /tmp/qemu-conf-25875-31202-17030.c:1: /usr/include/spice-1/spice/enums.h:186:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_OFF’ was here SPICE_IMAGE_COMPRESS_OFF, ^ In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0: /usr/include/spice-server/spice.h:477:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_AUTO_GLZ’ SPICE_IMAGE_COMPRESS_AUTO_GLZ = 2, ^ In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0, from /usr/include/spice-server/spice.h:23, from /tmp/qemu-conf-25875-31202-17030.c:1: /usr/include/spice-1/spice/enums.h:187:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_AUTO_GLZ’ was here SPICE_IMAGE_COMPRESS_AUTO_GLZ, ^ In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0: /usr/include/spice-server/spice.h:478:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_AUTO_LZ’ SPICE_IMAGE_COMPRESS_AUTO_LZ = 3, ^ In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0, from /usr/include/spice-server/spice.h:23, from /tmp/qemu-conf-25875-31202-17030.c:1: /usr/include/spice-1/spice/enums.h:188:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_AUTO_LZ’ was here SPICE_IMAGE_COMPRESS_AUTO_LZ, ^ In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0: /usr/include/spice-server/spice.h:479:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_QUIC’ SPICE_IMAGE_COMPRESS_QUIC = 4, ^ In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0, from /usr/include/spice-server/spice.h:23, from /tmp/qemu-conf-25875-31202-17030.c:1: /usr/include/spice-1/spice/enums.h:189:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_QUIC’ was here SPICE_IMAGE_COMPRESS_QUIC, ^ In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0: /usr/include/spice-server/spice.h:480:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_GLZ’ SPICE_IMAGE_COMPRESS_GLZ = 5, ^ In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0, from /usr/include/spice-server/spice.h:23, from /tmp/qemu-conf-25875-31202-17030.c:1: /usr/include/spice-1/spice/enums.h:190:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_GLZ’ was here SPICE_IMAGE_COMPRESS_GLZ, ^ In file included from /tmp/qemu-conf-25875-31202-17030.c:1:0: /usr/include/spice-server/spice.h:481:5: error: redeclaration of enumerator ‘SPICE_IMAGE_COMPRESS_LZ’ SPICE_IMAGE_COMPRESS_LZ = 6, ^ In file included from /usr/include/spice-1/spice/qxl_dev.h:38:0, from /usr/include/spice-server/spice.h:23, from /tmp/qemu-conf-25875-31202-17030.c:1: /usr/include/spice-1/spice/enums.h:191:5: note: previous definition of ‘SPICE_IMAGE_COMPRESS_LZ’ was here SPICE_IMAGE_COMPRESS_LZ,

piwwo commented on 2015-07-10 11:24 (UTC)

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

kantras commented on 2015-07-10 07:00 (UTC)

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

piwwo commented on 2015-07-07 16:50 (UTC)

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

kantras commented on 2015-07-04 23:47 (UTC)

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

cyberxndr commented on 2015-06-25 21:22 (UTC)

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

mks commented on 2015-06-24 09:21 (UTC)

apparently you can't search 'xen' in the new home i.e. aur4.archlinux.org. any ideas when to expect upstream fix for gcc5 + Xen 4.4/4.5? thanks

PZB1000 commented on 2015-06-24 05:56 (UTC)

Also just tried to build this package. As the option Werror is used i have got an error in symbols.c "arrary subscript is above array bounds" in line 23 from project src/xen-4.5.0/xen/common. gcc Version 5.1 on arch linux 64 bit

pgmillon commented on 2015-06-21 17:40 (UTC)

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

maximevince commented on 2015-06-16 08:23 (UTC)

As posted on the old aur: I can confirm the -fno-caller-saves is a valid workaround. My xen-4.5 build now actually boots my arch kernel. I thought it was a macbook/efi issue, but it was actually caused by gcc5! Patch is here: http://pastebin.com/XDpzbLYa So the full set of patches is: http://pastebin.com/Z5BnzFwc http://pastebin.com/19tb2esC http://pastebin.com/WwxugrRi http://pastebin.com/7742EHd1 http://pastebin.com/aNWdhEH0 http://pastebin.com/XDpzbLYa

ArthurBorsboom commented on 2015-05-31 08:56 (UTC)

From the same thread, apparently a workaround is setting the following compile flag avoiding the bug. fno-caller-saves As long as the bug is present, maybe it is an idea to implement this flag into the PKGBUILD?

jkf commented on 2015-05-30 19:08 (UTC)

After further investigation, it does indeed appear that GCC 5 is mis-compiling Xen. http://www.gossamer-threads.com/lists/xen/devel/381362#381362 Any one know if GCC 4.9 can co-exist with GCC 5 on the same system? Or would it be easier to roll back to a version of Arch before GCC 5 became the default?

jackb commented on 2015-05-30 05:22 (UTC)

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

jkf commented on 2015-05-29 06:43 (UTC)

Greetings, Following the comments in this thread, I have successfully built a Xen 4.5.0 package, but it fails during boot when Xen starts the Linux kernel. I have been following the following thread on the xen-devel mailing list which seems to suggest an issue with GCC 5. I have also posted to that thread to get more data to the Xen developers. http://www.gossamer-threads.com/lists/xen/devel/379916 I am running a system updated just a few days ago, that boots via UEFI and gummiboot. I have a working Xen 4.4.1 package that I built before GCC was upgraded to 5, so I believe this is an issue with Xen itself and not my environment. The system also functions properly when booting the Linux kernel directly. See the link below for the boot log I captured via the serial port. http://pastebin.com/bBC78306 Thinking my toolchain was the issue, I tried the Xen 4.5.0 EFI binary from Fedora 22, and it failed exactly the same way. It was compiled with GCC 5.0.1. See the below link for the boot log from that binary. http://pastebin.com/jvg1JazC Then I found the message linked below and tried the build of 4.5.1-rc1 that a poster did with GCC 4.9.2 on Fedora 21, and it booted successfully. See the boot log below from that. http://www.gossamer-threads.com/lists/xen/devel/380173#380173 http://pastebin.com/DKxwaU2U Xen is way lower level in the system that I'm used to digging around, so does anyone else have any thoughts on this issue? Thanks!

cptG commented on 2015-05-28 10:51 (UTC)

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

maelask commented on 2015-05-27 16:56 (UTC)

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

cptG commented on 2015-05-27 10:27 (UTC)

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

kantras commented on 2015-05-26 04:23 (UTC)

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

jackb commented on 2015-05-26 04:20 (UTC)

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

maximevince commented on 2015-05-25 10:31 (UTC)

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

jackb commented on 2015-05-24 23:31 (UTC)

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

jackb commented on 2015-05-24 23:30 (UTC)

Thanks @djvinz. That successfully resolved the array-bounds issue, but I'm now encountering another: builds/xen-4.4/src/xen-4.4.2/tools/firmware/seabios-dir-remote/src/kbd.c:117: undefined reference to `usb_kbd_command' out/code16.o: In function `mouse_command': builds/xen-4.4/src/xen-4.4.2/tools/firmware/seabios-dir-remote/src/mouse.c:28: undefined reference to `usb_mouse_command' Makefile:158: recipe for target 'out/rom16.o' failed make[6]: *** [out/rom16.o] Error 1 Any ideas what's up with that? I'm new to xen, and new-ish to Arch, so I apologize if I'm wasting your time, but I don't understand how everyone's managing to get this stuff going without issues. Lots of searches have yielded me nothing.

maximevince commented on 2015-05-24 16:58 (UTC)

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

jackb commented on 2015-05-24 07:12 (UTC)

Hey all. I'm having problems running makepkg. I'm getting an error about 'array subscript is above array bounds [-Werror=array-bounds]'. It's being caused by a macro, 'symbols_address'. Is anyone else having this problem? This is on a fresh install; nothing out of the ordinary.

ArthurBorsboom commented on 2015-05-19 09:02 (UTC)

xen-4.2.0 ?

ArthurBorsboom commented on 2015-05-16 21:52 (UTC)

Confirming 4.5.0-3 works fine for me. Good work, David!

kantras commented on 2015-05-16 20:56 (UTC)

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

mks commented on 2015-05-13 14:17 (UTC)

gnutls 3.4.1-1 works too.

ArthurBorsboom commented on 2015-05-13 14:13 (UTC)

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

aneeshusa commented on 2015-05-13 13:58 (UTC)

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

mbroemme commented on 2015-05-07 21:10 (UTC)

Morfeo, below is a patch to make the PKGBUILD ready for Xen 4.5.0: --- xen-docs/PKGBUILD 2014-03-22 21:47:42.000000000 +0100 +++ xen-docs-4.5.0/PKGBUILD 2015-03-31 02:17:45.650019000 +0200 @@ -1,7 +1,7 @@ # Maintainer: M0Rf30 pkgname=xen-docs -pkgver=4.4.0 +pkgver=4.5.0 pkgrel=1 pkgdesc="Xen 4 (docs)" arch=('i686' 'x86_64') @@ -13,11 +13,9 @@ package() { cd "$srcdir/xen-$pkgver" - cd docs unset CFLAGS LDFLAGS - ./configure --prefix=/usr - cd .. + ./configure --prefix=/usr --disable-xen --disable-tools --disable-stubdom --enable-docs make DESTDIR=$pkgdir install-docs } -md5sums=('fd9031d499af38c5d04108681734027e') +md5sums=('9bac43d2419d05a647064d9253bb03fa')

kantras commented on 2015-05-06 12:48 (UTC)

@pierrec - I disabled building of documentation because of the existance of the xen-docs package and because some people want to run their hypervisors very "light", without optional extras such as documentation. If that package doesn't get updated, and is still not orphaned, what I may have to do is add in the relevant changes into my PKGBUILD and just comment them out, so someone can always enable them if needed. @AuthurBorsboom - Will be today; I had a small checklist of things that I wanted to cover, which includes the ones you've mentioned, and i'm about ready to push the updated files.

ArthurBorsboom commented on 2015-05-06 09:07 (UTC)

Hi Kantras, AFAIK the following needs to be updated. - use of $srcdir - patch for gnutls Do you have an estimation of when you are able to publish the new PKGBUILD?

pierrec commented on 2015-05-06 08:48 (UTC)

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

alaricljs commented on 2015-05-05 01:38 (UTC)

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

mks commented on 2015-05-02 03:15 (UTC)

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

kantras commented on 2015-04-30 14:18 (UTC)

Updated package coming later today

tony_42 commented on 2015-04-30 13:38 (UTC)

sorry writing a patch in a comment was not a good idee ... The patch is simple, add this two lines at the end of the PKGBUILD: source+=('gnutls-3.4.0.patch::http://git.alpinelinux.org/cgit/aports/plain/main/xen/gnutls-3.4.0.patch?id=628f27939412a7d6fb67734bd644119a1f49463a') sha256sums+=('e25d38376e22f6f935d2c0ce1b9d6e6b47ff261b5e6056bc3b47168739d7a992') And in the prepare() function add this line (just after # Compile Patches): patch -p1 -i $srcdir/gnutls-3.4.0.patch

mks commented on 2015-04-30 12:25 (UTC)

Sorry sheep_42, patching fails with malformed error at this line: '3f0af16958c3e057b9baa5afc47050d9adf7dd553274dd97ae4f35938fefb568' I could try editing PKGBUILD myself if I knew what goes where. Thanks for helping!

tony_42 commented on 2015-04-30 10:53 (UTC)

tr0llalert, the gnutls fix patch looks correct (and one similair have been sent upstream) so I would use it instead of disable-qemu-traditional. To do that, just modify the PKGBUILD with this patch: --- a/PKGBUILD +++ b/PKGBUILD @@ -71,6 +71,9 @@ '3f0af16958c3e057b9baa5afc47050d9adf7dd553274dd97ae4f35938fefb568' '50a9b7fd19e8beb1dea09755f07318f36be0b7ec53d3c9e74f3266a63e682c0c') +source+=('gnutls-3.4.0.patch::http://git.alpinelinux.org/cgit/aports/plain/main/xen/gnutls-3.4.0.patch?id=628f27939412a7d6fb67734bd644119a1f49463a') +sha256sums+=('e25d38376e22f6f935d2c0ce1b9d6e6b47ff261b5e6056bc3b47168739d7a992') + prepare() { cd $pkgname-$pkgver/ @@ -79,6 +82,7 @@ prepare() { # Security Patches # Compile Patches + patch -p1 -i $srcdir/gnutls-3.4.0.patch # OVMF Compile support (Pulls from GIT repo, so patching to patch after pull request) echo "Patching OVMF..."

mks commented on 2015-04-30 01:41 (UTC)

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

mks commented on 2015-04-30 00:38 (UTC)

Hi Guys, I'm fairly new to this but having the same problem as some of you having. I'm unable to start DomUs (PV and HVM) with following error; /usr/lib/xen/bin/qemu-system-i386: error while loading shared libraries: libgnutls.so.28: cannot open shared object file: No such file or directory. I have tried upgrading Xen 4.4 to 4.5 but it's failing even with sheep_42's suggestion; 'For that, remove from the ./configure line : "--enable-stubdom --enable-qemu-traditional --enable-rombios" and add "--disable-qemu-traditional".' rm: cannot remove usr/share/xen/qemu/openbios-*: Not a directory ERROR: A failure occured in package(). Aborting... I tried downgrading libgnutls but the package suggested by zir_blazer is not being recognized by pacman as a valid archive. Any help with either upgrading Xen to 4.5 or making gnutls work with 4.4 would be appreciated. Thanks!

aneeshusa commented on 2015-04-29 20:09 (UTC)

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

zir_blazer commented on 2015-04-28 10:02 (UTC)

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

tony_42 commented on 2015-04-27 17:47 (UTC)

Hi zir_blazer, To compile Xen with recent gnutls, you could use --disable-qemu-traditional as a workaround if you don't intend to use qemu-traditional or stubdomain. For that, remove from the ./configure line : "--enable-stubdom --enable-qemu-traditional --enable-rombios" and add "--disable-qemu-traditional". For the usb redirection feature of SPICE, you can look at http://wiki.xen.org/wiki/SPICE_support_in_Xen, there is an example configuration file.

zir_blazer commented on 2015-04-27 16:05 (UTC)

For anyone that needs instructions on how to downgrade gnutls until the xen package gets updated to work with gnutls 3.4, you need to download and install the older, working package from the Arch Rollback Machine. Don't worry, you can do it in two commands: curl -O https://seblu.net/a/arm/packages/g/gnutls/gnutls-3.3.14-2-x86_64.pkg.tar.xz pacman -U gnutls-3.3.14-2-x86_64.pkg.tar.xz This applies both to build the xen package, and to use xl create to open your DomU. Keep in mind that you can break your working Xen install while it is running, if you update with pacman -Syyu. After the upgrade, xl create will give out errors. This means that you can screw up your working Xen install if you update Arch Linux while Xen it is running (And its possible that you can fix it downgrading without rebooting, too). Also, did anyone successfully managed to use the SPICE USB Redirect feature? I was told that besides adding a few SPICE-related parameters to my DomU Config File, I also need to use a SPICE client like virt-viewer. virt-viewer is also the very reason why I upgraded gnutls, which broke my Xen install. Since I can't have the latest gnutls, virt-viewer fails, but if I upgrade gnutls xl create fails, so in order to test SPICE I will have to wait for this package to catch up. If someone has a guide or a link with instructions to get it working, I will be most thankful.

sgowie commented on 2015-04-27 15:24 (UTC)

Compilation fails with gnutls 3.4.0-1, presenting: undefined reference to `gnutls_kx_set_priority' Downgrading gnutls corrected the issue.

trixpan commented on 2015-04-25 10:34 (UTC)

has anyone managed to complete makepkg using gcc 5? Seems to be a little bit challenging... https://bugzilla.suse.com/show_bug.cgi?id=921994

ArthurBorsboom commented on 2015-04-24 09:29 (UTC)

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

kantras commented on 2015-04-23 20:06 (UTC)

Testing and should be releasing update either tonight or tomorrow

lembang commented on 2015-04-23 19:56 (UTC)

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

hugleo commented on 2015-04-22 14:58 (UTC)

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

commented on 2015-04-22 14:29 (UTC)

I recently upgraded gnutls to 3.4.0 and it's broken my HVMs. Logs showed libgnutls.so.28 not being found. General advice for these sorts of problems is to rebuild so I tried. Rebuilding fails in tools/qemu-xen-traditional/vnc.c with undefined references to gnutls_*_set_priority. AFAICS this set of functions was deprecated some years ago so I suspect they are no longer present. Downgraded gnutls for now

kantras commented on 2015-04-18 02:16 (UTC)

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

daniel_shub commented on 2015-04-17 14:50 (UTC)

I am having the same problem that @ArthurBorsboom is having with makepkg not being able to find tmpfiles.d-xen.conf when I build in a clean chroot. I am pretty sure install -Dm644 ../../tmpfiles.d-$pkgname.conf usr/lib/tmpfiles.d/$pkgname.conf is making an assumption about the location of $srcdir relative to $pkgdir. I think it should be install -Dm644 $srcdir/tmpfiles.d-$pkgname.conf usr/lib/tmpfiles.d/$pkgname.conf If I am correct, there are a couple of other lines immediately afterwards that also need the change. I think to be totaly robust, $srcdir should be wrapped in quotes throughout the PKGBUILD.

tritron commented on 2015-04-08 19:07 (UTC)

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

zir_blazer commented on 2015-04-08 18:09 (UTC)

I can confirm the last post. The syntax of the dom0_mem option provided in the efi-xen.cfg file is wrong, the correct one is with a : instead of a = in the max parameter. If you're using UEFI Boot, you will eventually notice it. Also, an issue popped where if creating an Arch Linux DomU, installing Xorg and a Desktop Manager, the Mouse cursor is invisible. At least some other guy had the same issue: http://lists.xenproject.org/archives/html/xen-users/2015-04/msg00033.html I can confirm it. I don't know if its a Xen issue, or any other of the upgraded Arch Linux packages related to it (xorg-server 1.17.1 comes to mind). I'm using the xf86-video-vesa Driver. Finally, I made public an english installation guide for Arch Linux and Xen, which I suppose some people here may find interesing: http://lists.xenproject.org/archives/html/xen-devel/2015-04/msg00709.html

JohnTh commented on 2015-04-07 03:15 (UTC)

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

ArthurBorsboom commented on 2015-04-03 13:23 (UTC)

Some more debugging info, where I added a pwd in the PKGBUILD: pwd before "cd pkgdir": /tmp/makepkg/xen/src/xen-4.5.0 pwd before "install cmd": /tmp/makepkg/xen/pkg/xen install: cannot stat ‘../../tmpfiles.d-xen.conf’: No such file or directory

basus commented on 2015-04-02 21:09 (UTC)

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

ArthurBorsboom commented on 2015-04-02 19:32 (UTC)

I did find the symbolic link of the missing file in this directory: /tmp/makepkg/xen/src The symbolic link is: tmpfiles.d-xen.conf -> /tmp/yaourt-tmp-arthur/aur-xen/tmpfiles.d-xen.conf The file does seem to exist: [arthur@orion1695 src]$ cat /tmp/yaourt-tmp-arthur/aur-xen/tmpfiles.d-xen.conf d /run/xen 0755 root root - d /run/xenstored 0755 root root -

ArthurBorsboom commented on 2015-04-02 19:18 (UTC)

Hi Kantras, Thanks for updating the package. Unfortunately, I get a build error: .... install -m0644 -p mini-os-x86_32-grub/mini-os.gz "/tmp/makepkg/xen/pkg/xen/usr/lib/xen/boot/pv-grub-x86_32.gz" make[1]: Leaving directory '/tmp/makepkg/xen/src/xen-4.5.0/stubdom' install: cannot stat ‘../../tmpfiles.d-xen.conf’: No such file or directory ==> ERROR: A failure occurred in package(). Aborting... ==> ERROR: Makepkg was unable to build xen. Any idea what the cause is and how to prevent it? Do you need more logging?

zir_blazer commented on 2015-04-02 15:59 (UTC)

Tested all three things. Got news: At least in my case, the Radeon patch seems to be already redundant. I see the same behaviator on the DomU with and without it (First boot everything works, second boot the Video Card itself works but PowerPlay Power States don't, on third boot everything works again, then repeat the sequence). I was able to change qemu-xen-traditional to qemu-xen on the DomU config file with no issues. Just by starting again the DomU, everything was working. WXP x64 detected some new Hardware and installed a few Drivers. Just to make sure, I uninstalled the GPLPV Drivers and restarted in Safe Mode, opened cmd, then used: set DEVMGR_SHOW_NONPRESENT_DEVICES=1 devmgmt.msc This open Device Manager with an specific flag set, and also by ticking View/Show Hidden devices, allows you to see Devices that aren't present but their Drivers are installed. I uninstalled what I recognized to be emulated QEMU devices or Xen related, then rebooted again, and finally, reinstalled the GPLPV Drivers. Everything seems to be working. This is as clean as I thought I could do the migration. I also uncommented the --enable-ovmf line in PKGBUILD. It builded properly, and after reinstalling the xen package, now I can create a DomU with UEFI Firmware. I do agree that the more sensible choice is to not have it by default, since download and build times skyrockets with it. Just make sure than it is stated somewhere that OVMF is there and ready to use. Basically, absolutely everything I tested is working for me in this version. An amazing achievement, considering that 4.4 broke Passthrough in my setup, yet with 4.5 I have all what I had in 4.3 and better, I'm not bound anymore to qemu-xen-traditional, so I don't have to worry about it being dropped in future versions. What I didn't tried was UEFI Boot (I have to refresh pacman to install Gummiboot, and with 5 months worth of upgrades, if something breaks I will have issues figuring what it was), but since before building I had a binutils with x86_64-pep package installed, it dropped an EFI file in /boot. Since in both 4.3 and 4.4 UEFI Boot worked with Kernel 3.17, I don't see any reason for it not to work. Anyways, thank you. The delay with your xen package was worth it.

zir_blazer commented on 2015-04-02 12:47 (UTC)

Can confirm that I was able to build, install, and get working, the new Xen 4.5. I'm using Kernel 3.17.1 and BIOS Boot - I don't update Arch Linux since the last time I tinkered with it, that was at the end of October. The best part is that it worked out of the box with my current Xen 4.3 WXP x64 DomU config file, that is using qemu-xen-traditional, including Video Card and Sound Card passthrough, with no issues (For those that remember me, I couldn't get neither working properly on Xen 4.4). I simply uninstalled Xen 4.3, rebooted, installed Xen 4.5, enabled systemd services, modified the Syslinux config file, rebooted, and voila. Also, I uncommented the Radeon patch when building, but not sure if it makes a difference or not since its a quite ancient piece of code, will try in a while without using it. I'm also interesed in testing with xen-qemu instead, since xen-qemu-traditional will be gone for Xen 4.6. What I was NOT able to get working, is creating a VM with OVMF. It opens, then inmediately closes. It seems that according to the PKGBUILD --enable-ovmf is commented out. Will try checking if I can build with OVMF support by uncommenting it. After testing with and without the Radeon Passthrough patch, qemu-xen instead of qemu-xen-traditional, and if I can build with OVMF, I will comment again. BTW, looking at some recent Threads about KVM VFIO, is amazing the progress that they made. They can currently do Passthrough of GeForces Video Cards, which on Xen was impossible for years without modding them to Quadro, and some other goodies. Xen is getting a bit stagnant for the niche I am in, which is rather sad...

lembang commented on 2015-04-01 17:20 (UTC)

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

kantras commented on 2015-04-01 07:56 (UTC)

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

kantras commented on 2015-04-01 05:41 (UTC)

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

lembang commented on 2015-04-01 03:59 (UTC)

the new one doesnt work with kernel 3.19 and also all my vm doesnt work now ACPI: no LAPIC found rolled back to kernel 3.18.6 libxl: error: libxl_create.c:1153:domcreate_launch_dm: unable to add disk devices libxl: error: libxl_dm.c:1578:kill_device_model: unable to find device model pid in /local/domain/4/image/device-model-pid libxl: error: libxl.c:1603:libxl__destroy_domid: libxl__destroy_device_model failed for 4 libxl: error: libxl_device.c:797:libxl__initiate_device_remove: unable to get my domid libxl: error: libxl.c:1640:devices_destroy_cb: libxl__devices_destroy failed for 4

ArthurBorsboom commented on 2015-03-22 07:18 (UTC)

Which tests do you still have in mind? Maybe some of us can help out performing those tests?

kantras commented on 2015-03-17 12:55 (UTC)

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

mbroemme commented on 2015-03-17 10:09 (UTC)

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

ArthurBorsboom commented on 2015-03-05 11:51 (UTC)

Hi Kantras, Can I help with any testing?

kantras commented on 2015-02-12 17:21 (UTC)

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

ArthurBorsboom commented on 2015-02-11 21:47 (UTC)

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

tritron commented on 2015-02-01 04:49 (UTC)

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

ArthurBorsboom commented on 2015-01-22 07:46 (UTC)

Yes, I had the same error and it took me quite some time to fix. For me it had to do with an fix for another issue in the kernel 3.18, which has this as a side effect. Since a downgrade of the kernel is a bit complicated, I have chosen to install the AUR package linux-mainline (Arch Linux). Kernel 3.19 rc4 gave me issues due to the Xen kernel boot parameters not being accepted. However Kernel 3.19 rc5 seems to have resolved all my issues. So my solution/advise is to temporary install the kernel 3.19 rc5 and once the regular kernel 3.19 is released, to revert back to the stable kernel 3.19.

tritron commented on 2015-01-22 01:30 (UTC)

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

kantras commented on 2015-01-15 18:32 (UTC)

I will look at that patch when I transition this over to become xen-4.4 (as "xen" will be moving over to match the 4.5 release) Note: I am currently away from my systems so the package update will be delayed until I get back this weekend and can run everything through final tests.

zir_blazer commented on 2015-01-15 13:22 (UTC)

@tritron Are you sure than that patch is needed at all? As far that I know the RAM limit when using VGA Passthrough was fixed sometime during Xen 4.3, as with the xen-4.3 AUR package, I was able to get it working with > 4 GB RAM on a WXP x64 DomU. See this: http://i.imgur.com/a37aoZF.png With Xen 4.4, I had regressions with PCI Passthrough (Sound Card makes nasty noises everytime that it reproduces a sound), and VGA Passthrough was a total no go, this was regardless if I was using 2 GB of RAM or more. Did you successfully managed to get VGA Passthrough working with less than 3.5 GB without the patch and more with it? I would be surprised cause this means yet another regression on Xen 4.4 vs 4.3, through if that patch fixes it we're already covered.

tritron commented on 2015-01-15 04:07 (UTC)

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

BeepDog commented on 2015-01-10 18:59 (UTC)

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

ArthurBorsboom commented on 2015-01-03 16:38 (UTC)

Hi Kantras, I found another way to customize the Xen bootloader. You need to edit the /etc/xen/grub.conf file, as described in the Grub section here. https://wiki.archlinux.org/index.php/xen No need to research any further.

ArthurBorsboom commented on 2014-12-31 10:10 (UTC)

That sounds good to me. Thanks!

kantras commented on 2014-12-31 10:05 (UTC)

Hi ArthurBorsboom, The short version is that it never has supported using those options in /etc/default/grub, even before I took maintainership of it; the rewrite I did was keeping with existing functionality, just extending it to also support the lts kernels. I'm actually working on the PKGBUILD for 4.5 now, so I'll add a task to myself to look into 09_xen vs 20_linux_xen (which is the script which comes packaged with grub that uses that variable) and decide which way is best to go to ensure existing configurations aren't broken by any changes I make either.

ArthurBorsboom commented on 2014-12-31 09:43 (UTC)

Hi Kantras, While trying to set a fixed amount of memory for Dom0, I noticed that the 09_xen file of grub, does not pick up the "GRUB_CMDLINE_XEN_DEFAULT" variable in /etc/default/grub, as I believe it should be. See also: http://wiki.xen.org/wiki/Xen_Project_Best_Practices When I manually modify the "XEN_HYPERVISOR_CMDLINE" variable in 09_xen, it does work. However when 09_xen gets updated, this change will be lost. Do you know why the GRUB_CMDLINE_XEN_DEFAULT is not being used by 09_xen?

kantras commented on 2014-12-16 07:21 (UTC)

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

kantras commented on 2014-10-30 07:09 (UTC)

@zir_blazer: Actually xen maintain their own fork of the OVMF source code, and its from that repository that the build system pulls. This is why I made the comment that I did about the method we use; I didn't want to try against a system install of OVMF as I wasn't sure if all the xen specific patches had been upstreamed and this technically should already be known to be working with xen. I actually tried booting up a live cd via OVMF and it worked great. @ArthurBorsboom: There shouldn't be any impact to existing installs - all that has been done is enabling some support code, that won't be used unless a user enables the specific configuration options (for example, OVMF is a replacement for SeaBIOS, but won't be used unless you add "bios='ovmf'" into the configuration file for the domU. )

ArthurBorsboom commented on 2014-10-29 07:50 (UTC)

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

zir_blazer commented on 2014-10-29 03:41 (UTC)

Just tested the new package yesterday, with good results. Using makepkg with the default PKGBUILD automatically downloads OVMF, builds it successfully, and after installing, it is ready to use as I could create an UEFI DomU showing TianoCore splash screen. Amazing work. I think that you're the first one to introduce OVMF support into a Xen package. I do expect that being default build option, some users may have fun trying to make a UEFI DomU for Windows 7/8 or Linux when they notice that support for OVMF is already included and ready to use. But there are some drawbacks. First, that maybe not everyone likes the 200 MiB download. It goes unnoticed when you have 20-30 mins compile time through, so seems minor. The other drawback is that because you're also downloading code from another repository, if for some reason something breaks on the OVMF side, the package will fail to build. Its potentially more work when that happens (Last time was with GCC 4.9 release). A more safe way could be by including a compiled OVMF Firmware in the package and invoking it with --with-system-ovmf=<path>, through I never managed to get it working that way. For as long as everything works, the current way rocks as you get the latest code. I didn't tested Xen UEFI Boot using binutils with x86_64-pep. However, I did recently a feature request for that to be included in default binutils: https://bugs.archlinux.org/task/42540 The sad part of all this is that I'm stuck with Xen 4.3 due to my regression issue, because as I use Xen for a gaming Windows VM, passthrough is a must. So besides testing to say that it works, I will not be able to enjoy it.

isiachi commented on 2014-10-28 14:17 (UTC)

I've just modified the 09_xen to add grub support to intel_ucode package. My version of 09_xen automatic detects the presence of /boot/intel-ucode.img and add it to grub.cfg. http://downloads.rhyeworld.it/files/static/isiachi/09_xen

kantras commented on 2014-10-28 00:51 (UTC)

@zir_blazer: Ok, was finally able to get the OVMF tree, which is pulled via git during compile, to compile. This new update should have this, along with some more cleanup as well as enabling spice support. Also, if binutils has been rebuilt with the correct option, it will detect the xen.efi file and will move it into /boot. An example xen.cfg is also included as /etc/xen/efi-xen.cfg - simply copy it over into /boot/xen.cfg and edit it with your options.

kantras commented on 2014-10-13 18:09 (UTC)

@zir_blazer: This is on my todo list (Last night I was actually going over the forum posts you had made previously) however I've not had a lot of spare time recently to sit down and work on this (as well as enabling spice support) I'm about to do a major overhaul on my primary desktop system (which uses the xen hypervisor) so was going to tackle that at the same time. I've also been watching your posts on xen-users and xen-devel, so am aware of it; i've not personally experienced those issues however my setup is a little different so wouldn't likely be hit by some of that (i.e I use a usb headset to my domU, rather than pass through sound)

zir_blazer commented on 2014-10-13 17:29 (UTC)

I would like to repeat my request for OVMF support, which allows to make DomUs with UEFI Firmware instead of BIOS. The idea is that by adding --enable-ovmf in the ./configure line, it automatically downloads 200 MiB or so from edk2 Source Repository and builds it to get a binary that is included with Xen, so you can later create a DomU with it: http://wiki.xen.org/wiki/OVMF While I didn't tried building with OVMF recently, the last time I attemped to do so, it fails to build cause the Source Code it downloads from edk2 repository isn't modified to build properly in Arch Linux (It isn't aware that python = Python 3.x and it has to use python2 instead, and it also had some issues with GCC 4.9). The other option for doing so, --with-system-ovmf=<ovmf.bin path> never worked for me either. The only success I had was when I merged the modified Source Code from the ovmf-svn package into the directory where xen downloads the edk2 source. Also, I repeated that procedure with the xen-4.3 package but I wasn't able to get OVMF working. Nor I tested with 4.4.1 to check if it still works. In other news, while toying around with Xen 4.4.1 I hit some nasty regressions in PCI and VGA Passthrough. The Sound Card works but produces tons of noise everytime that it reproduces a sound (Workaroundeable), and VGA Passthrough is a total no-go. Both things works fine if I try with the xen-4.3 package. Would like to know if anyone else that tested both 4.3.x and 4.4.1 had issues with Passthrough. More info here: http://lists.xen.org/archives/html/xen-devel/2014-10/msg00549.html Would like to know if other Passthrough users had issues or not between those two versions.

ArthurBorsboom commented on 2014-10-12 19:32 (UTC)

I hereby confirm that the Xen package on my server has upgraded successfully by my regular updating method using yaourt, from v4.4.0 to v4.4.1. Just a hint for other users, don't forget to update grub manually afterwards; this can save you a phone call to your service provider. (Whoooops) :D Thanks Kantras for analyzing and fixing.

kantras commented on 2014-10-12 09:20 (UTC)

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

hbc2 commented on 2014-10-11 08:51 (UTC)

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

kantras commented on 2014-10-03 21:25 (UTC)

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

clfarron4 commented on 2014-10-03 21:23 (UTC)

This looks like a serious vulnerability that has just emerged: http://xenbits.xen.org/xsa/advisory-108.html https://xen-orchestra.com/blog/xen-security-and-xsa-108/

daniel_shub commented on 2014-10-01 10:33 (UTC)

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

kantras commented on 2014-10-01 09:19 (UTC)

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

3000 commented on 2014-10-01 06:56 (UTC)

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

hbc2 commented on 2014-10-01 03:52 (UTC)

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

3000 commented on 2014-09-30 22:34 (UTC)

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

kantras commented on 2014-09-28 14:47 (UTC)

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

hbc2 commented on 2014-09-28 13:05 (UTC)

ArthurBorsboom's issue is easy to duplicate on a fresh install of arch. (yup, installing arch is easy if you've installed it 50+ times like I have while learning linux. :P ) Seriously, though, on a fresh install with nothing else installed I ran into the same exact problem Mr. Borsboom did. I'm using grub not UEFI. I'm building right out of the AUR. cd /root wget https://aur.archlinux.org/packages/xe/xen/xen.tar.gz tar -xvf xen.tar.gz cd xen makepkg -s --asroot I'm going to poke around in the make files. Never done that before. This should be fun. :)

ArthurBorsboom commented on 2014-09-17 13:00 (UTC)

When I remove the following two lines from the PKGBUILD, the package is build finishes. mv etc/default/xencommons etc/conf.d/xencommons mv etc/default/xendomains etc/conf.d/xendomains There are these two warnings: ==> WARNING: backup entry file not in package : etc/conf.d/xendomains ==> WARNING: backup entry file not in package : etc/conf.d/xencommons Probably coming from: backup=(etc/modules-load.d/$pkgname.conf etc/$pkgname/xl.conf etc/conf.d/xen{stored,consoled,domains,commons} etc/$pkgname/grub.conf) Maybe this gives a clue?

ArthurBorsboom commented on 2014-09-17 12:36 (UTC)

@Zir_blazer, thanks for the suggestion. I did exactly what you proposed, unfortunately with the same result. install -d -m0755 -p "/tmp/makepkg/xen/pkg/xen/usr/lib/xen/boot" install -m0644 -p mini-os-x86_32-grub/mini-os.gz "/tmp/makepkg/xen/pkg/xen/usr/lib/xen/boot/pv-grub-x86_32.gz" make[1]: Leaving directory '/tmp/makepkg/xen/src/xen-4.4.1/stubdom' mv: cannot stat ‘etc/default/xencommons’: No such file or directory ==> ERROR: A failure occurred in package(). Aborting... [arthur@orion1695 xen]$ Any other ideas?

zir_blazer commented on 2014-09-17 08:59 (UTC)

@ ArthurBorsboom On my experience, I have seen similar errors when re-building xen package on the same folder than a previous build. Seems like it is not deleting or replacing something. Basically, everytime you want to build, try to start from scratch on a new folder, or delete the previous build. Try this: mkdir /home/builds cd /home/builds curl -O https://aur.archlinux.org/packages/xe/xen/xen.tar.gz tar -xzf xen.tar.gz cd xen makepkg Should work.

ArthurBorsboom commented on 2014-09-17 06:51 (UTC)

Hi Kantras, Do you have another guess what might be causing the build problem on my system? Xen still doesn't upgrade from 4.4.0 to 4.4.1 with the following error. ld: warning: section `.bss' type changed to PROGBITS gzip -f -9 -c /tmp/makepkg/xen/src/xen-4.4.1/stubdom/mini-os-x86_32-grub/mini-os >/tmp/makepkg/xen/src/xen-4.4.1/stubdom/mini-os-x86_32-grub/mini-os.gz make[2]: Leaving directory '/tmp/makepkg/xen/src/xen-4.4.1/extras/mini-os' install -d -m0755 -p "/tmp/makepkg/xen/pkg/xen/usr/lib/xen/boot" install -m0644 -p mini-os-x86_32-grub/mini-os.gz "/tmp/makepkg/xen/pkg/xen/usr/lib/xen/boot/pv-grub-x86_32.gz" make[1]: Leaving directory '/tmp/makepkg/xen/src/xen-4.4.1/stubdom' mv: cannot stat ‘etc/default/xencommons’: No such file or directory ==> ERROR: A failure occurred in package(). Aborting... ==> ERROR: Makepkg was unable to build xen. ==> Restart building xen ? [y/N] ==> ---------------------------- ==> ==> ERROR: unable to update ==> upgrading SVN/CVS/HG/GIT package

zir_blazer commented on 2014-09-16 11:11 (UTC)

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

zir_blazer commented on 2014-09-15 16:53 (UTC)

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

reynoldsbd commented on 2014-09-15 14:14 (UTC)

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

ArthurBorsboom commented on 2014-09-11 06:33 (UTC)

@kantras, I build my package by entering "yaourt -Suya" which updates all packages on my system. AFAIK, I have a normal Arch kernel. Since I don't know what hardware it is, I have created a system overview with inxi. http://pastebin.com/pFKZaJw6 AFAIK, I have no special packages except Xen. http://pastebin.com/hS8VvWw3

kantras commented on 2014-09-10 21:15 (UTC)

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

tritron commented on 2014-09-10 20:48 (UTC)

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

kantras commented on 2014-09-10 20:44 (UTC)

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

tritron commented on 2014-09-10 20:09 (UTC)

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

kantras commented on 2014-09-10 19:53 (UTC)

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

kantras commented on 2014-09-10 19:51 (UTC)

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

tritron commented on 2014-09-10 19:41 (UTC)

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

ArthurBorsboom commented on 2014-09-09 12:49 (UTC)

It happens during the build. See: http://pastebin.com/r8VPcdqY

kantras commented on 2014-09-08 17:54 (UTC)

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

ArthurBorsboom commented on 2014-09-08 14:49 (UTC)

Yaourt fails to upgrade Xen with the following error: mv: cannot stat ‘etc/default/xencommons’: No such file or directory Looks like somewhere is a slash missing.

moggers commented on 2014-09-07 02:28 (UTC)

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

kantras commented on 2014-09-06 17:39 (UTC)

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

moggers commented on 2014-09-06 09:12 (UTC)

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

kantras commented on 2014-09-04 00:31 (UTC)

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

zir_blazer commented on 2014-09-04 00:05 (UTC)

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

kantras commented on 2014-09-03 09:02 (UTC)

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

kantras commented on 2014-09-03 09:00 (UTC)

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

Naruni commented on 2014-09-01 17:08 (UTC)

When booting from UEFI, kernel cannot mount root partition due to "unknown filesystem vfat" Where are the kernel config options in this pkgbuild? 3.16.1-1-ARCH #1 SMP PREEMPT

Lastebil commented on 2014-08-22 13:37 (UTC)

ryad0m: autoconf is part of base-devel. This is assumed to be installed when using the AUR - see here: https://wiki.archlinux.org/index.php/Arch_User_Repository The base-devel group, for reference: https://www.archlinux.org/groups/x86_64/base-devel/ So no, it should _NOT_ be added to makedepends.

ryad0m commented on 2014-08-22 12:58 (UTC)

Please, add core/autoconf in makedepends

isiachi commented on 2014-08-13 15:24 (UTC)

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

kantras commented on 2014-08-10 05:37 (UTC)

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

zman0900 commented on 2014-08-10 04:27 (UTC)

I think I found something: http://lists.xen.org/archives/html/xen-devel/2014-03/msg02923.html Looks like a new patch was applied at the same time the old one was reverted. I'm about to upgrade for the first time in about 4 months, so I guess I'll find out if it works...

zman0900 commented on 2014-08-10 02:57 (UTC)

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

smakovits commented on 2014-07-17 12:10 (UTC)

Traced the issue to the lvm2 hook. Had a working system, added it and things did not boot again. removed the hook and once again the system booted fine. My original installation was on a lv so I needed it there. This time I used linux (83) for rootfs so it was not needed. I thought i needed it to load a vm when it didnt boot originally, but then the system didnt boot. Removed it and now things are happy again.

hugleo commented on 2014-07-13 15:10 (UTC)

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

smakovits commented on 2014-07-12 04:12 (UTC)

ever since 4.4.0-3 and Kernel 3.15 my screen goes black upon booting xen. I tried syslinux and Grub with the same results. I re-installed arch at least times, keeping with the beginners guide and then xen install instructions. I have no idea what and why, but the screen just goes black and things require a hard reset. The normal arch kernel is fine, but nothing I do helps get me going. I even tried using downgrader to try older kernels, but those too had the same result.

trixpan commented on 2014-07-08 13:06 (UTC)

Kantras, Thanks for the update. Working like a charm. Any chances of adding Spice support to the PKG? Cheers

fatal-error commented on 2014-07-06 07:28 (UTC)

Errors when building @kantras: make[2]: Leaving directory '/[...]/AUR/xen/src/xen-4.4.0/xen' make[1]: Leaving directory '/[...]/AUR/xen/src/xen-4.4.0/xen' fatal: unable to connect to xenbits.xen.org: xenbits.xen.org[0: 50.57.170.242]: errno=Connection timed out Makefile:25: recipe for target 'seabios-dir' failed make[3]: *** [seabios-dir] Error 128 make[3]: Leaving directory '/[...]/AUR/xen/src/xen-4.4.0/tools/firmware' /[...]/AUR/xen/src/xen-4.4.0/tools/../tools/Rules.mk:105: recipe for target 'subdir-install-firmware' failed make[2]: *** [subdir-install-firmware] Error 2 make[2]: Leaving directory '/[...]/AUR/xen/src/xen-4.4.0/tools' /[...]/AUR/xen/src/xen-4.4.0/tools/../tools/Rules.mk:100: recipe for target 'subdirs-install' failed make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory '/[...]/AUR/xen/src/xen-4.4.0/tools' Makefile:96: recipe for target 'install-tools' failed make: *** [install-tools] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

tritron commented on 2014-07-02 15:01 (UTC)

Did anyone compile efi xen and set EFI VENDOR ?

isiachi commented on 2014-07-02 14:59 (UTC)

Hello! If you try to create an HVM guest with usb=1 you get this message: libxl: error: libxl_dm.c:1371:device_model_spawn_outcome: domain 1 device model: spawn failed (rc=-3) libxl: error: libxl_create.c:1186:domcreate_devmodel_started: device model did not start: -3 libxl: error: libxl_dm.c:1475:kill_device_model: Device Model already exited I solved installing usbredir. It's not a dependecy but an optional one for sure!

kantras commented on 2014-06-20 16:21 (UTC)

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

kantras commented on 2014-06-18 00:15 (UTC)

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

ironicbadger commented on 2014-06-17 10:41 (UTC)

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

kantras commented on 2014-06-14 20:35 (UTC)

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

atondwal commented on 2014-06-14 20:02 (UTC)

I'm getting some problems with the vhd libs during compilation... https://gist.github.com/atondwal/53dd5fe2bc954c2642b8

lucaoli commented on 2014-06-12 21:52 (UTC)

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

lucaoli commented on 2014-06-03 21:55 (UTC)

I'm trying to compile xen on a KVM Host, but I receive the following error: checking compiler gcc -mno-red-zone -O1 -fno-omit-frame-pointer -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-error=maybe-uninitialized -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -fno-stack-protector -fno-exceptions has sizeof(long)==4... no configure: error: could not find a working compiler, see config.log for details Makefile:164: recipe for target 'gmp-x86_64' failed make[1]: *** [gmp-x86_64] Error 1 make[1]: Leaving directory '/home/lucaoli/xen/src/xen-4.4.0/stubdom' Makefile:104: recipe for target 'install-stubdom' failed make: *** [install-stubdom] Error 2 In xen-4.4.0/stubdom/gmp-x86_64/config.log I've found: configure:5631: gcc -mno-red-zone -O1 -fno-omit-frame-pointer -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-str ict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-error=maybe-uninitialized -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unuse d-local-typedefs -fno-stack-protector -fno-exceptions -c conftest.c >&5 conftest.c:2:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] main () ^ conftest.c: In function 'main': conftest.c:4:14: error: size of array 'test_array' is negative static int test_array [1 - 2 * (long) (sizeof (long) != 4)]; ^ What does mean "could not find a working compiler"? I think it's normal that on a x86_64 architecture sizeof(long) is 8 and than not 4.

kantras commented on 2014-05-20 00:22 (UTC)

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

kantras commented on 2014-05-17 16:16 (UTC)

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

isiachi commented on 2014-05-17 12:00 (UTC)

This patch came from the stable-4.4 branch of xen. I made this package: http://downloads.rhyeworld.it/static/xen-4.4.0-3.src.tar.gz I've already applied the patch.

chetwisniewski commented on 2014-05-17 00:08 (UTC)

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

isiachi commented on 2014-05-16 19:39 (UTC)

Hi! This is a very good package! I've got only one problem when try to restart or shutdown pvh guests. The entire xen system stuck and I have to manually reboot the entire system. I've solved adding this patch: http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=3a148e0a7ee0ae56a498be5ba973314ec50cd999

trixpan commented on 2014-05-09 11:11 (UTC)

Kantras, Not sure what your opinion is about this but it may be a good idea to add a patch to enable SPICE on QEMU upstream (as documented on http://wiki.xenproject.org/wiki/SPICE_support_in_Xen#QEMU_Upstream) Please note that this would also require adding the following dependencies: - spice (https://www.archlinux.org/packages/extra/i686/spice/) - spice-protocol (https://www.archlinux.org/packages/extra/any/spice-protocol/) - usbredir Modified PKGBUILD => http://pastebin.com/eiJmLFfe Patch to enable SPICE => http://pastebin.com/msDz41yT Cheers

mbroemme commented on 2014-05-09 00:27 (UTC)

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

kantras commented on 2014-05-04 23:51 (UTC)

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

kantras commented on 2014-05-03 17:28 (UTC)

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

methril commented on 2014-05-03 13:55 (UTC)

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

dante82 commented on 2014-05-02 16:15 (UTC)

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

fmarchand commented on 2014-05-01 19:25 (UTC)

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

kantras commented on 2014-04-15 06:46 (UTC)

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

trixpan commented on 2014-03-28 13:21 (UTC)

kantras, thank you for the fix. Being a migrant from debian to arch+xen I it took me a while to pinpoint the grub issue was not some sort of chair <-> keyboard interface on this side of the screen... :-) I managed to get and Haswell GPU passed through a Linux domU without major issues

kantras commented on 2014-03-27 23:24 (UTC)

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

daniel_shub commented on 2014-03-27 11:10 (UTC)

Thank you for the great package and keeping it up to date. I had no problem building and installing the package and seems to work great. The only issue I am having is with my GRUB boot menu. Have you gotten a chance to fix the issue with xen-syms? Is it as simple as adding something like mv boot/$pkgname-syms-* etc/xen/scripts/ after # Compress syms file gzip boot/$pkgname-syms-* although I am not sure why the syms kernel should go in the scripts directory, but I don't know where else to put it.

Oimelchen commented on 2014-03-22 18:05 (UTC)

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

ironicbadger commented on 2014-03-22 08:52 (UTC)

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

Oimelchen commented on 2014-03-22 08:04 (UTC)

Hi, thanks a lot for this package. It builds without any problem (even with the ati-passthrough patch enabled). I was able to passthrough two Radeon 5670 gfx cards to two separate VMs (one to Win7 VM and the other one to a Mint VM, both in secondary passthrough). Unfortunatly when using the xl tool stack, I am not able to restart the VMs, the dom0 totally crashes. So I tried to rebuild this package with enabled xm toolset. When using the same Vms with the xm toolset, every seems to work like charm! This might be a useful hint for those, who try to get to do similar things. :-) So, as a recommendation, could you add the xm toolset to the PKGBUILD by adding the flag --enable-xend to the configure command? I know, it is deprecated, but at least it is a working alternative (at least for me).

kantras commented on 2014-03-18 13:20 (UTC)

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

3000 commented on 2014-03-18 08:40 (UTC)

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

tritron commented on 2014-03-17 19:51 (UTC)

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

kantras commented on 2014-03-17 13:53 (UTC)

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

kantras commented on 2014-03-17 13:48 (UTC)

@3000: to help start to debug this - whats the output from the following commands (run as root): xl info xenstore-read /local/domain/0/domid also, what do you have as the config file for the windows domU and for your grub.cfg file? (can send to me directly if you don't want to post those details)

tritron commented on 2014-03-17 13:36 (UTC)

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

3000 commented on 2014-03-17 12:59 (UTC)

nope, that doesn't work either :( thanks anyway!

hugleo commented on 2014-03-17 12:37 (UTC)

The following config works for me: kernel = "/usr/lib/xen/boot/hvmloader" builder='hvm' memory = 1024 device_model='/usr/lib/xen/bin/qemu-dm' shadow_memory = 8 name = "winxxx" vif = [ 'mac=00:16:3e:11:11:11,bridge=xenbr0', ] disk = [ 'phy:/vms/winxx.img,hda,w' ] boot = "dc" usb = 1 usbdevice = 'tablet' vnc = 1 sdl = 0 vncdisplay=1 #keymap='en' on_xend_stop = 'shutdown'

3000 commented on 2014-03-17 12:15 (UTC)

Hi, just wanted to upgrade. It built fine, without any Problems whatsoever, so great Job kantras! But when I try to start Windows I get this error: libxl: error: libxl_dom.c:281:libxl__build_post: Failed to set event channel limit to 1023 (-1) libxl: error: libxl_create.c:1022:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl_dm.c:1467:kill_device_model: unable to find device model pid in /local/domain/3/image/device-model-pid libxl: error: libxl.c:1421:libxl__destroy_domid: libxl__destroy_device_model failed for 3 what can I do to fix this? thanks a lot!

kantras commented on 2014-03-11 21:37 (UTC)

So, it should be being ran, the problem would be that the script was modified more than just the default kernel (for example, LTS kernels) and it seems to think that the xen-syms file is another kernel. I'll update the package (following the old 4.3.2 package by moving syms to a different location) and upload an updated version

hugleo commented on 2014-03-11 21:03 (UTC)

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

kantras commented on 2014-03-11 16:55 (UTC)

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

panda commented on 2014-03-11 13:58 (UTC)

There is a mistake in the PKGBUILD file. Just before the ATI patch, in the prepare statement, an exit is breaking makepkg. If this is intentional, please advise. Tx for the package however.

kantras commented on 2014-03-11 05:03 (UTC)

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

evilsephiroth commented on 2014-03-10 21:26 (UTC)

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

kantras commented on 2014-03-10 21:15 (UTC)

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

kantras commented on 2014-03-10 20:24 (UTC)

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

kantras commented on 2014-03-10 17:31 (UTC)

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

evilsephiroth commented on 2014-03-10 16:18 (UTC)

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

kingd commented on 2014-03-10 16:15 (UTC)

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

BeepDog commented on 2014-03-10 15:59 (UTC)

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

kantras commented on 2014-02-24 05:00 (UTC)

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

zman0900 commented on 2014-02-24 04:32 (UTC)

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

kantras commented on 2014-02-24 04:28 (UTC)

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

zman0900 commented on 2014-02-24 04:05 (UTC)

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

kantras commented on 2014-02-24 03:55 (UTC)

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

kantras commented on 2014-02-24 03:48 (UTC)

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

zman0900 commented on 2014-02-24 02:23 (UTC)

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

kantras commented on 2014-02-20 06:51 (UTC)

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

ironicbadger commented on 2014-02-15 23:36 (UTC)

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

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

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

ironicbadger commented on 2014-02-01 19:53 (UTC)

gets my vote.

kantras commented on 2014-02-01 19:52 (UTC)

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

hugleo commented on 2014-01-27 18:42 (UTC)

Crashed again, a little more stable however.

hugleo commented on 2014-01-27 15:09 (UTC)

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

hugleo commented on 2014-01-27 11:18 (UTC)

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

kantras commented on 2014-01-25 21:13 (UTC)

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

discord commented on 2014-01-25 19:39 (UTC)

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

3000 commented on 2014-01-13 18:41 (UTC)

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

michaelharwood commented on 2013-12-30 03:02 (UTC)

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

zman0900 commented on 2013-12-27 16:24 (UTC)

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

3000 commented on 2013-12-27 16:21 (UTC)

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

kantras commented on 2013-12-25 21:30 (UTC)

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

malinas commented on 2013-12-25 13:47 (UTC)

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

malinas commented on 2013-12-21 19:30 (UTC)

@kantras.. np. I have to say I also built in the end fine, just 3 days ago or so. Just want to add, thanks for keeping this updated and man is Xen awesome!!! :)

kantras commented on 2013-12-19 20:21 (UTC)

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

meltfund commented on 2013-12-19 19:15 (UTC)

Similar build problem on this system today http://pastebin.com/nHgDssf2

meltfund commented on 2013-12-19 19:14 (UTC)

Built fine on this system last week http://pastebin.com/AfKiQLrt

thouveng commented on 2013-12-19 16:17 (UTC)

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

kantras commented on 2013-12-19 06:27 (UTC)

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

amber commented on 2013-12-19 03:43 (UTC)

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

kantras commented on 2013-12-18 14:24 (UTC)

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

malinas commented on 2013-12-18 13:15 (UTC)

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

thouveng commented on 2013-12-17 18:13 (UTC)

I still have the same problem. To fix it I commented the following line in function package() in PKGBUILD: mv etc/default/xendomains etc/conf.d/xendomains Now it seems OK but I didn't know what is the impact of this comment? At the end of the log there are two warnings about backup entry file that is not in package. make[1]: Leaving directory '/home/thouveng/builds/xen/src/xen-4.3.1/stubdom' ==> Tidying install... -> Purging unwanted files... -> Removing libtool files... -> Removing static library files... ==> WARNING: backup entry file not in package : etc/conf.d/xendomains ==> WARNING: backup entry file not in package : etc/default/xencommons -> Compressing man and info pages... ==> Creating package "xen"... -> Generating .PKGINFO file... -> Adding changelog file... -> Adding install file... -> Generating .MTREE file... -> Compressing package... ==> Leaving fakeroot environment. ==> Finished making: xen 4.3.1-2 (Tue Dec 17 19:08:40 CET 2013)

Refutationalist commented on 2013-12-12 18:12 (UTC)

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

Refutationalist commented on 2013-12-10 21:36 (UTC)

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

Refutationalist commented on 2013-12-09 20:23 (UTC)

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

thouveng commented on 2013-12-08 17:43 (UTC)

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

kantras commented on 2013-11-25 10:28 (UTC)

AUR packages updated, also included the three latest security patches

Sydney6 commented on 2013-11-25 03:53 (UTC)

Yes, you can.

j-lap commented on 2013-11-25 03:50 (UTC)

@zman0900 - Already installed "bluez", no dice. Build fails because it is looking for dependency "bluez4". Can I simply edit "bluez4" to "bluez" in the PKGBUILD?

zman0900 commented on 2013-11-25 03:40 (UTC)

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

j-lap commented on 2013-11-25 03:00 (UTC)

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

Fidelix commented on 2013-11-09 00:27 (UTC)

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

Fidelix commented on 2013-11-08 23:06 (UTC)

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

Fidelix commented on 2013-11-08 21:08 (UTC)

Morfeo, please add ghostscript as a dependency. I was only able to build it after installing it.

kantras commented on 2013-11-07 21:37 (UTC)

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

Fidelix commented on 2013-11-07 20:55 (UTC)

How do I build xen with UEFI support?

devnull_1337 commented on 2013-11-03 11:38 (UTC)

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

kantras commented on 2013-10-31 22:28 (UTC)

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

Sydney6 commented on 2013-10-23 16:00 (UTC)

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

kantras commented on 2013-10-23 15:54 (UTC)

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

kantras commented on 2013-10-23 08:05 (UTC)

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

Sydney6 commented on 2013-10-22 23:57 (UTC)

Hello Everybody, the 4.3.0-7 build seems to fail with following output. File "caml_startup", line 1: Error: Cannot find file libasmrun.a /tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/ocaml/xenstored/../Makefile.rules:94: recipe for target 'oxenstored' failed make[5]: *** [oxenstored] Error 2 make[5]: Leaving directory '/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/ocaml/xenstored' /tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/ocaml/../../tools/Rules.mk:105: recipe for target 'subdir-install-xenstored' failed make[4]: *** [subdir-install-xenstored] Error 2 make[4]: Leaving directory '/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/ocaml' /tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/ocaml/../../tools/Rules.mk:100: recipe for target 'subdirs-install' failed make[3]: *** [subdirs-install] Error 2 make[3]: Leaving directory '/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/ocaml' /tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/../tools/Rules.mk:105: recipe for target 'subdir-install-ocaml' failed make[2]: *** [subdir-install-ocaml] Error 2 make[2]: Leaving directory '/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools' /tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools/../tools/Rules.mk:100: recipe for target 'subdirs-install' failed make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory '/tmp/yaourt-tmp-sydney/aur-xen/src/xen-4.3.0/tools' Makefile:74: recipe for target 'install-tools' failed make: *** [install-tools] Error 2 Any suggestions?

netskink commented on 2013-10-08 21:26 (UTC)

As of today, I pulled this package down and built it with no problems.

kantras commented on 2013-10-04 07:44 (UTC)

Ok, just released an update - quick changes: added a pre_remove section to handle stopping and disabling systemd services before the package is removed. Also added the latest XSA patches (security advisories) Note: for anyone who was looking into gfx passthrough with a plain nvidia gtx card, I'd suggest checking out the archives at http://www.davidgis.fr/blog/

BenderIsGreat34 commented on 2013-10-03 15:07 (UTC)

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

kantras commented on 2013-09-29 05:39 (UTC)

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

ido commented on 2013-09-29 00:30 (UTC)

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

kantras commented on 2013-09-29 00:13 (UTC)

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

kantras commented on 2013-09-28 23:28 (UTC)

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

kantras commented on 2013-09-28 23:22 (UTC)

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

shanmu commented on 2013-09-28 21:05 (UTC)

Kantras, please take ownership :)

karol_007 commented on 2013-09-28 11:45 (UTC)

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

ironicbadger commented on 2013-09-05 19:24 (UTC)

Comment by zman0900 2013-08-25 23:29 4.3.0-4 with the ATI Passthrough patch works for me for my Windows 8 + ATI HD7850 HVM setup. I had to add 'device_model_version="qemu-xen-traditional"' to my config, but no other changes were necessary. This worked for me too in so far as getting the VGA passthrough working, with the ATI patch applied to 4.3.0-4, with a 7970. It works great until I reboot the domU at which point the GPU is not reinitialized and only VNC access is available. If I reboot the dom0 then all is well. Is there a script I can run that will trick the GPU into resetting once the domU has shutdown?

kantras commented on 2013-08-30 22:44 (UTC)

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

zman0900 commented on 2013-08-28 22:14 (UTC)

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

zootboy commented on 2013-08-27 15:15 (UTC)

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

zman0900 commented on 2013-08-25 23:29 (UTC)

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

zman0900 commented on 2013-08-25 22:11 (UTC)

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

zman0900 commented on 2013-08-25 21:49 (UTC)

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

kantras commented on 2013-08-14 07:20 (UTC)

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

evilsephiroth commented on 2013-08-14 06:22 (UTC)

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

kantras commented on 2013-08-14 04:40 (UTC)

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

kantras commented on 2013-08-14 04:38 (UTC)

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

tritron commented on 2013-08-12 01:39 (UTC)

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

kantras commented on 2013-08-12 00:33 (UTC)

I'm also using qemu-xen-traditional, which is why I guess I wasn't affected. I've just spent an hour or so going back through the history on that patch; it was rejected for multiple reasons, including the mechanism used as well as the change occuring too late in the boot up sequence. A workaround patch was sent to the qemu-devel list but I don't know that it was included in time (my build sources show no sign on the patch http://marc.info/?l=qemu-devel&m=137043414711228&q=raw ) I'm going to work on getting this newer patch into place in my AUR package, and will post here when the new version is uploaded into my web space. I'm also looking into becoming the maintainer of this package, so I can help keep it up to date.

evilsephiroth commented on 2013-08-11 21:59 (UTC)

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

evilsephiroth commented on 2013-08-11 21:52 (UTC)

Thanks. At the moment,I solved the memory issue adding device_model_version = 'qemu-xen-traditional' to the hvm win7 domu conf file... Doing this, I lost completely vnc capabiliities for domU, so the patch would be greatly appreciated... Thanks again...

kantras commented on 2013-08-11 20:31 (UTC)

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

evilsephiroth commented on 2013-08-11 09:09 (UTC)

Hi kantras, I've successfully installed your xen package for 4.3.0 but I'm suffering the 3gb memory limitation when passing gpu to hvm domU(win7). Have you included this patch in the package? http://marc.info/?l=qemu-devel&m=136177475215360&q=raw If not, how can I patch the source and reinstall the package? Thanks a lot for your efforts...

kantras commented on 2013-08-11 05:12 (UTC)

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

commented on 2013-08-11 04:59 (UTC)

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

kantras commented on 2013-08-08 05:59 (UTC)

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

hugleo commented on 2013-07-31 15:06 (UTC)

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

kantras commented on 2013-07-31 07:33 (UTC)

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

zootboy commented on 2013-07-25 13:45 (UTC)

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

commented on 2013-07-25 09:16 (UTC)

I tried to install this with: packer -S xen and received: Dependency 'dev86' of 'xen' does not exist.

kantras commented on 2013-07-20 05:51 (UTC)

Unfortunately this won't build as configure wasn't run: ==> Making package: xen-docs 4.3.0-1 (Sat Jul 20 00:49:05 CDT 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Downloading xen-4.3.0.tar.gz... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 15.6M 100 15.6M 0 0 876k 0 0:00:18 0:00:18 --:--:-- 988k ==> Validating source files with md5sums... xen-4.3.0.tar.gz ... Passed ==> Extracting sources... -> Extracting xen-4.3.0.tar.gz with bsdtar ==> Entering fakeroot environment... ==> Starting package()... make -C docs install make[1]: Entering directory `/home/kantras/aur-builds/xen-docs/src/xen-4.3.0/docs' Makefile:164: *** You have to run ./configure before building docs. Stop. make[1]: Leaving directory `/home/kantras/aur-builds/xen-docs/src/xen-4.3.0/docs' make: *** [install-docs] Error 2 ==> ERROR: A failure occurred in package(). Aborting...

kantras commented on 2013-07-19 21:02 (UTC)

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

hugleo commented on 2013-07-19 19:25 (UTC)

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

kantras commented on 2013-07-19 15:44 (UTC)

I'll look into that one - the xendomains script is supposed to be checking whether /etc/conf.d exists, and then using it for the config file. I'll fix it and upload a new version a little later today (not at my workstation right now). Anything else you noticed? Also, if you are using xendomains and xl, make sure you read the note when installing/upgrading about the change needed to /etc/xen/xl.conf; you have to add the following line (otherwise the script won't understand the format correctly): output_format="sxp"

hugleo commented on 2013-07-19 14:50 (UTC)

It's working perfectly here. Just to note that for the xendomains.service is causing a error due the lack of the file /etc/default/xendomains -- Unit xendomains.service has begun starting up. Jul 19 11:33:15 radiolinux xendomains[1108]: /etc/default/xendomains not existing Jul 19 11:33:15 radiolinux systemd[1]: xendomains.service: main process exited, code=exited, status=6/NOTCONFIGURED Jul 19 11:33:15 radiolinux systemd[1]: Failed to start Xendomains - start and stop guests on boot and shutdown. -- Subject: Unit xendomains.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/catalog/be02cf6855d2428ba40df7e9d022f03d -- -- Unit xendomains.service has failed.

kantras commented on 2013-07-18 21:41 (UTC)

Ok, I've posted an updated version of this package to my website, and it now is using xen-4.3.0 - http://www.kantras.info/xen/xen-4.3.0-1.tar.gz Fixes (highlights) : * No longer conflicts with qemu * Added in template configuration files for xenconsoled and xenstored

kantras commented on 2013-07-18 00:15 (UTC)

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

hugleo commented on 2013-07-11 13:19 (UTC)

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

commented on 2013-07-10 06:58 (UTC)

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

commented on 2013-07-10 06:49 (UTC)

@revellion, I have the same problem with @deviousway. Traceback (most recent call last): File "./tools/layoutrom.py", line 583, in <module> main() File "./tools/layoutrom.py", line 564, in main info16 = parseObjDump(infile16, '16') File "./tools/layoutrom.py", line 501, in parseObjDump relocsection = sectionmap[sectionname] KeyError: '.text.asm.src/smp.c.68' make[6]: *** [out/romlayout16.lds] 错误 1 I have try export LANG=C And I also export LC_ALL=en_US.UTF-8, but it still can't work.

tritron commented on 2013-06-17 12:55 (UTC)

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

Lastebil commented on 2013-06-17 12:39 (UTC)

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

commented on 2013-06-17 12:06 (UTC)

@Lastebil, my HVM config is essentially the one on the Arch Wiki (https://wiki.archlinux.org/index.php/Xen#Configuring_a_hardware_virtualized_.28HVM.29_Arch_domU). I would propose that the package build only require the packages to get a dom0 setup. Packages only required for running either a PV and/or HVM should be _optional_. One could then create xen-pv and xen-hvm dummy packages to load the required packages or we could list these optional packages on the wiki.

Lastebil commented on 2013-06-17 07:49 (UTC)

I am, but I haven't on that machine. I'll build another later and see what the issue is. Can you post your hvm config? I would propose that the packagebuild be set up to put bluez as _optional_ if you need HVM, as it isn't needed for PVM.

commented on 2013-06-14 13:18 (UTC)

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

tritron commented on 2013-06-12 12:29 (UTC)

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

Lastebil commented on 2013-06-12 10:06 (UTC)

It builds perfectly fine without bluez (or bluez4) and if you don't care to have bluetooth, it's not needed. (In my case, I'm a good 8km from the machines with xen - fully remote, serial consoles, etc - so I definately don't need bluetooth. It's range isn't anywhere near 8km (: ) I also am very interested in the xen-api stuff, if we end up setting up a mailing list or whatever, ping me, please.

commented on 2013-06-09 17:14 (UTC)

I was unable to build the package install -d -m0755 -p txt/man pod2text man/xl.pod.1 txt/man/xl.1.txt.tmp man/xl.pod.1 around line 854: Expected text after =item, not a bullet POD document had syntax errors at /usr/bin/core_perl/pod2text line 84. make[2]: *** [txt/man/xl.1.txt] Error 255

kantras commented on 2013-06-08 04:46 (UTC)

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

hugleo commented on 2013-06-07 12:09 (UTC)

Or xen can compile selecting bluez version 5

hugleo commented on 2013-06-07 12:02 (UTC)

Now is needed to replace the bluez dependence with bluez4.

kantras commented on 2013-06-05 15:37 (UTC)

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

tritron commented on 2013-06-05 15:30 (UTC)

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

kantras commented on 2013-06-05 15:29 (UTC)

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

kantras commented on 2013-06-05 15:25 (UTC)

The pod2man "fix" was added to the texi2html.patch file; pod2man is returning an error code when parsing qemu.pod, due to using non-ascii characters when no '=encoding' parameter has been set. The file would still be created, which is why rebuilding the package a second time would work (since it would skip running pod2man as the file already existed) Two ways to fix, either a) add in "=encoding utf8' at the top of the qemu.pod file before you run it through pod2man or b) add the option '--errors=none' into the command line calling pod2man. I opted for the second as it was easier.

tritron commented on 2013-06-05 14:57 (UTC)

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

kantras commented on 2013-06-05 05:59 (UTC)

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

zootboy commented on 2013-06-04 18:20 (UTC)

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

kantras commented on 2013-06-04 16:44 (UTC)

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

zootboy commented on 2013-06-04 15:35 (UTC)

pacman -Ql xen | grep /bin says no.

hugleo commented on 2013-06-04 14:25 (UTC)

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

commented on 2013-06-03 17:06 (UTC)

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

tritron commented on 2013-05-30 00:50 (UTC)

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

tritron commented on 2013-05-30 00:19 (UTC)

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

hugleo commented on 2013-05-29 20:40 (UTC)

Here is building totally normal. No need edit anything. Have it already fixed? Or this error is caused on only some systems... I've founded the files: grep -ilr 'Schütz.' ./* 2>/dev/null ./yaourt-tmp-ths/aur-xen/src/xen-4.2.2/tools/qemu-xen-traditional/Changelog ./yaourt-tmp-ths/aur-xen/src/xen-4.2.2/tools/qemu-xen-traditional/qemu-doc.texi ./yaourt-tmp-ths/aur-xen/src/xen-4.2.2/tools/qemu-xen/Changelog ./yaourt-tmp-ths/aur-xen/src/xen-4.2.2/tools/qemu-xen/qemu-doc.texi While is compiling you can try edit the files qemu-xen-traditional/qemu-doc.texi and qemu-xen/qemu-doc.texi

hugleo commented on 2013-05-28 23:54 (UTC)

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

tritron commented on 2013-05-28 23:32 (UTC)

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

kantras commented on 2013-05-28 18:27 (UTC)

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

3000 commented on 2013-05-28 17:36 (UTC)

@ Kantras: is your solution still working for you? thanks

3000 commented on 2013-05-25 13:56 (UTC)

I also tried xen-git, also not working (yet). Thanks also for the xen-users mailing list idea. I will post my Problem over there shortly. I have to correct myself though regarding my last post: I said I was able to install xen only in legacy boot. Well to be more precise, I was able to boot INTO xen with legacy boot. With UEFI boot, I was still able to successfully install xen, BUT once I tried to boot into Arch Xen, the system would constantly just reboot. That's my real Problem. And once I tried to apply Kantras solution (modifying binutils-multilib before installing xen), installation broke down. I know it's not arch related, I still thought it's worth mentioning. There is a decisive difference to my last post.

tritron commented on 2013-05-25 00:23 (UTC)

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

zootboy commented on 2013-05-24 23:20 (UTC)

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

3000 commented on 2013-05-24 22:31 (UTC)

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

hugleo commented on 2013-05-23 21:35 (UTC)

Here I've compiled perfectly using yaourt. You can try re generate the locales: cat /etc/locale.conf LANG="en_US.UTF8" locale-gen Generating locales... en_US.UTF-8... done en_US.ISO-8859-1... done You can also try on a fresh arch "systemd" installation. uname -a (64 bits) Linux archlocal 3.9.3-1-ARCH #1 SMP PREEMPT Sun May 19 22:50:29 CEST 2013 x86_64 GNU/Linux

zootboy commented on 2013-05-23 21:31 (UTC)

@3000 That's the line. And no, unfortunately, I don't have any UEFI motherboards to test on. Though I find it strange that UEFI would make the difference on that line in particular, I won't rule it out as a possibility. You should definitely try removing that line, as trying can't hurt at this point. Also, there's been some chat on the xen-users mailing list about UEFI stuff recently. Are you trying to compile on a 32-bit kernel?

3000 commented on 2013-05-23 20:59 (UTC)

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

3000 commented on 2013-05-23 18:59 (UTC)

I can't find that line, I just had a look in the "View PKGBUILD" from this page. I can only find this one: "mv etc/{init,rc}.d" Is that the one? @zootboy: are you also having a uefi boot? I will try to download packer and install it with that command of yours.

zootboy commented on 2013-05-23 18:00 (UTC)

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

3000 commented on 2013-05-23 17:53 (UTC)

thanks for the responses. I won't use root again for building packages, thanks! I had already installed base-devel. And in my Xen PKGBUILD there is no line that starts with mv /etc/init.d so I don't know what to do now ...

zootboy commented on 2013-05-23 13:22 (UTC)

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

tritron commented on 2013-05-23 13:15 (UTC)

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

3000 commented on 2013-05-23 10:51 (UTC)

i am having the same error message as SeraphZA any help is hugely appreciated, for me this is the last hurdle to finally build my System for good. this is the Output of the error: make[2]: Leaving directory `/root/xen/src/xen-4.2.2/extras/mini-os' install -d -m0755 -p "/root/xen/pkg/xen/usr/lib/xen/boot" install -m0644 -p mini-os-x86_32-grub/mini-os.gz "/root/xen/pkg/xen/usr/lib/xen/boot/pv-grub-x86_32.gz" make[1]: Leaving directory `/root/xen/src/xen-4.2.2/stubdom' mv: cannot stat âetc/init.dâ: No such file or directory ==> ERROR: A failure occurred in package(). Aborting...

3000 commented on 2013-05-20 17:51 (UTC)

thanks for the fast response! That was it, I was just executing "makepkg --asroot" it's installing right now :)

tritron commented on 2013-05-20 17:40 (UTC)

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

3000 commented on 2013-05-20 17:34 (UTC)

so I have downloaded latest tarball and tried to install it, but it's not building. I must stress, I have been able to use uefi boot, so I don't know, if that's hindering the Installation, anyways I got this error: ... xen.conf ... Passed ==> Extracting sources... -> Extracting xen-4.2.2.tar.gz with bsdtar ==> Starting prepare()... /root/xen/PKGBUILD: line 38: patch: command not found ==> ERROR: A failure occurred in prepare(). Aborting...

commented on 2013-05-17 10:38 (UTC)

I have an EFI motherboard and am running Arch 2013_05 x86_64. I am trying to build xen.efi and I have applied the Python workaround and rebuilt binutils-multilib with --enable-targets=X86_64-pep. The output of ld -V is: GNU ld (GNU Binutils) 2.23.2 Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om elf_k1om i386pep i386pe However when I build xen i get: mv: cannot stat âetc/init.dâ: No such file or directory ==> ERROR: A failure occurred in package(). Aborting... Build logs here: https://dl.dropboxusercontent.com/u/66245999/xen-4.2.2-1-x86_64-prepare.log https://dl.dropboxusercontent.com/u/66245999/xen-4.2.2-1-x86_64-build.log https://dl.dropboxusercontent.com/u/66245999/xen-4.2.2-1-x86_64-package.log Can someone please assist?

zootboy commented on 2013-05-12 20:02 (UTC)

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

kantras commented on 2013-05-12 18:37 (UTC)

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

zootboy commented on 2013-05-12 17:50 (UTC)

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

tritron commented on 2013-05-12 17:06 (UTC)

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

kantras commented on 2013-05-12 17:04 (UTC)

@gtmanfred - No objection from me

gtmanfred commented on 2013-05-12 07:07 (UTC)

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

gtmanfred commented on 2013-05-12 06:40 (UTC)

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

kantras commented on 2013-04-30 05:25 (UTC)

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

kantras commented on 2013-04-29 08:03 (UTC)

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

gtmanfred commented on 2013-04-29 02:59 (UTC)

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

3000 commented on 2013-04-27 11:56 (UTC)

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

shanmu commented on 2013-04-27 09:50 (UTC)

Thanks for the patch, tycho! Released a new version with the patch. If the build fails with the error: /usr/include/python2.7/modsupport.h:27:1: error: 'PyArg_ParseTuple' is an unrecognized format function type [-Werror=format=] PyAPI_FUNC(int) PyArg_ParseTuple(PyObject *, const char *, ...) Py_FORMAT_PARSETUPLE(PyArg_ParseTuple, 2, 3); ^ cc1: all warnings being treated as errors error: command 'gcc' failed with exit status 1 make[3]: *** [build] Error 1 The workaround is to comment line#72 in /usr/include/python2.7/pyconfig.h //#define HAVE_ATTRIBUTE_FORMAT_PARSETUPLE 1 I need to log a new bug against the python package to get it fixed.

zootboy commented on 2013-04-26 13:39 (UTC)

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

3000 commented on 2013-04-26 08:46 (UTC)

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

tycho commented on 2013-04-25 14:23 (UTC)

I've added this patch locally to fix that issue.: --- a/tools/qemu-xen/Makefile.target 2013-04-05 23:39:54.000000000 +0000 +++ b/tools/qemu-xen/Makefile.target 2013-04-25 13:54:59.360000000 +0000 @@ -206,6 +206,7 @@ obj-$(CONFIG_NO_KVM) += kvm-stub.o obj-y += memory.o LIBS+=-lz +LIBS+=-lrt QEMU_CFLAGS += $(VNC_TLS_CFLAGS) QEMU_CFLAGS += $(VNC_SASL_CFLAGS)

fatmike commented on 2013-04-25 10:24 (UTC)

Same for me here. Any solution?

commented on 2013-04-24 06:06 (UTC)

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

zootboy commented on 2013-04-24 01:52 (UTC)

I believe python2 should be added as a dependency.

3000 commented on 2013-04-14 13:23 (UTC)

exactly, I can confirm, working quite nicely. Thanks a lot. You guys rock. :)

commented on 2013-04-14 09:05 (UTC)

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

shanmu commented on 2013-04-13 19:21 (UTC)

Hi jamm, as posted earlier, The error is because of Arch bug FS#34658. The Workaround till it is fixed is to comment line#72 in /usr/include/python2.7/pyconfig.h //#define HAVE_ATTRIBUTE_FORMAT_PARSETUPLE 1

commented on 2013-04-13 14:20 (UTC)

Hi shanmu, make[3]: Entering directory `/home/jamm/build/xen-4.2.1-5/src/xen-4.2.1/tools/python' rm -f "xen/util/path.py".tmp; echo "SBINDIR=\"/usr/sbin\"" >>"xen/util/path.py".tmp; echo "BINDIR=\"/usr/bin\"" >>"xen/util/path.py".tmp; echo "LIBEXEC=\"/usr/lib/xen/bin\"" >>"xen/util/path.py".tmp; echo "LIBDIR=\"/usr/lib\"" >>"xen/util/path.py".tmp; echo "SHAREDIR=\"/usr/share\"" >>"xen/util/path.py".tmp; echo "PRIVATE_BINDIR=\"/usr/lib/xen/bin\"" >>"xen/util/path.py".tmp; echo "XENFIRMWAREDIR=\"/usr/lib/xen/boot\"" >>"xen/util/path.py".tmp; echo "XEN_CONFIG_DIR=\"/etc/xen\"" >>"xen/util/path.py".tmp; echo "XEN_SCRIPT_DIR=\"/etc/xen/scripts\"" >>"xen/util/path.py".tmp; echo "XEN_LOCK_DIR=\"/var/lock\"" >>"xen/util/path.py".tmp; echo "XEN_RUN_DIR=\"/var/run/xen\"" >>"xen/util/path.py".tmp; echo "XEN_PAGING_DIR=\"/var/lib/xen/xenpaging\"" >>"xen/util/path.py".tmp; if ! cmp -s "xen/util/path.py".tmp "xen/util/path.py"; then mv -f "xen/util/path.py".tmp "xen/util/path.py"; else rm -f "xen/util/path.py".tmp; fi PYTHONPATH=/home/jamm/build/xen-4.2.1-5/src/xen-4.2.1/tools/python/../../tools/libxl python2 genwrap.py \ /home/jamm/build/xen-4.2.1-5/src/xen-4.2.1/tools/python/../../tools/libxl/libxl_types.idl \ xen/lowlevel/xl/_pyxl_types.h \ xen/lowlevel/xl/_pyxl_types.c Parsing /home/jamm/build/xen-4.2.1-5/src/xen-4.2.1/tools/python/../../tools/libxl/libxl_types.idl CC="gcc" CFLAGS="-O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -Wno-sizeof-pointer-memaccess -Wformat -D__XEN_TOOLS__ -MMD -MF .build.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls " python2 setup.py build running build running build_py running build_ext building 'xc' extension gcc -DNDEBUG -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -Wno-sizeof-pointer-memaccess -Wformat -D__XEN_TOOLS__ -MMD -MF .build.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls -fPIC -I../../tools/include -I../../tools/libxc -Ixen/lowlevel/xc -I/usr/include/python2.7 -c xen/lowlevel/xc/xc.c -o build/temp.linux-x86_64-2.7/xen/lowlevel/xc/xc.o -fno-strict-aliasing -Werror In file included from /usr/include/python2.7/Python.h:126:0, from xen/lowlevel/xc/xc.c:7: /usr/include/python2.7/modsupport.h:27:1: error: 'PyArg_ParseTuple' is an unrecognized format function type [-Werror=format=] PyAPI_FUNC(int) PyArg_ParseTuple(PyObject *, const char *, ...) Py_FORMAT_PARSETUPLE(PyArg_ParseTuple, 2, 3); ^ cc1: all warnings being treated as errors error: command 'gcc' failed with exit status 1 make[3]: *** [build] Error 1 There are packages installed in the system: kbproto-1.0.6-1 libtasn1-3.2-1 libx11-1.5.0-2 libxau-1.0.7-1 libxcb-1.9-3 libxdmcp-1.1.1-1 libxext-1.3.1-1 libxrender-0.9.7-1 nettle-2.6-1 ocaml-4.00.1-3 p11-kit-0.13-1 perl-error-0.17019-1 python2-2.7.4-1 renderproto-0.11.1-2 sqlite-3.7.16.2-1 xcb-proto-1.8-1 xextproto-7.2.1-1 xproto-7.0.24-1 bin86-0.16.19-1 bluez-4.101-1 dev86-0.16.19-1 git-1.8.2.1-1 gnutls-3.1.10-1 iasl-20130328-1 lib32-glibc-2.17-5 libaio-0.3.109-6 libjpeg-turbo-1.2.1-1 libpng-1.5.15-1 markdown-1.0.1-5 ocaml-findlib-1.3.3-2 sdl-1.2.15-3 vde2-2.3.2-2 yajl-2.0.4-1 fontconfig-2.10.2-1 libxft-2.3.1-1 libxss-1.2.2-1 scrnsaverproto-1.2.2-1 tcl-8.6.0-3 tk-8.6.0-1 What I can do for solve issue?

virtuemood commented on 2013-04-13 13:52 (UTC)

Thanks for update !!

Sydney6 commented on 2013-04-12 23:23 (UTC)

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

shanmu commented on 2013-04-12 23:10 (UTC)

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

Sydney6 commented on 2013-04-12 23:00 (UTC)

Hi shanmuha, tried your suggestions to patch pkgbuild (which have suddely disappeared), build with gcc 4.8 failed with: In file included from /root/xen/src/xen-4.2.1/tools/qemu-xen/fpu/softfloat.c:60:0: /root/xen/src/xen-4.2.1/tools/qemu-xen/fpu/softfloat-specialize.h:92:1: error: initializer element is not constant const floatx80 floatx80_default_nan = make_floatx80(floatx80_default_nan_high, ^ /root/xen/src/xen-4.2.1/tools/qemu-xen/fpu/softfloat-specialize.h:107:1: error: initializer element is not constant const float128 float128_default_nan = make_float128(float128_default_nan_high, ^ make[4]: *** [fpu/softfloat.o] Error 1 make[3]: *** [subdir-i386-softmmu] Error 2 make[3]: Leaving directory `/root/xen/src/xen-4.2.1/tools/qemu-xen-dir' make[2]: *** [subdir-all-qemu-xen-dir] Error 2 make[2]: Leaving directory `/root/xen/src/xen-4.2.1/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/root/xen/src/xen-4.2.1/tools' make: *** [install-tools] Error 2 Now tried your suggestion for the python bindings and the build failed with: In file included from /root/xen/src/xen-4.2.1/xen/include/public/xen.h:33:0, from /root/xen/src/xen-4.2.1/xen/include/xen/time.h:12, from /root/xen/src/xen-4.2.1/xen/include/xen/hypercall.h:9, from memory.c:3: memory.c: In function 'compat_memory_op': /root/xen/src/xen-4.2.1/xen/include/public/arch-x86/xen.h:35:33: error: typedef '__guest_handle_const_compat_memory_exchange_t' locally defined but not used [-Werror=unused-local-typedefs] typedef struct { type *p; } __guest_handle_ ## name ^ /root/xen/src/xen-4.2.1/xen/include/public/arch-x86/xen.h:43:5: note: in expansion of macro '___DEFINE_XEN_GUEST_HANDLE' ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type) ^ /root/xen/src/xen-4.2.1/xen/include/public/arch-x86/xen.h:44:41: note: in expansion of macro '__DEFINE_XEN_GUEST_HANDLE' #define DEFINE_XEN_GUEST_HANDLE(name) __DEFINE_XEN_GUEST_HANDLE(name, name) ^ memory.c:261:13: note: in expansion of macro 'DEFINE_XEN_GUEST_HANDLE' DEFINE_XEN_GUEST_HANDLE(compat_memory_exchange_t); ^ cc1: all warnings being treated as errors make[5]: *** [memory.o] Error 1 make[5]: Leaving directory `/root/xen/src/xen-4.2.1/xen/common/compat' make[4]: *** [compat/built_in.o] Error 2 make[4]: Leaving directory `/root/xen/src/xen-4.2.1/xen/common' make[3]: *** [/root/xen/src/xen-4.2.1/xen/common/built_in.o] Error 2 make[3]: Leaving directory `/root/xen/src/xen-4.2.1/xen/arch/x86' make[2]: *** [/root/xen/src/xen-4.2.1/xen/xen] Error 2 make[2]: Leaving directory `/root/xen/src/xen-4.2.1/xen' make[1]: *** [install] Error 2 make[1]: Leaving directory `/root/xen/src/xen-4.2.1/xen' make: *** [install-xen] Error 2 Any more suggestions, Cheers, S.

shanmu commented on 2013-04-12 22:50 (UTC)

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

luolimao commented on 2013-04-12 21:40 (UTC)

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

3000 commented on 2013-04-12 11:16 (UTC)

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

tritron commented on 2013-04-08 18:28 (UTC)

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

evanlec commented on 2013-04-08 11:06 (UTC)

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

3000 commented on 2013-04-07 10:35 (UTC)

Hi, I can't compile. I get this error message: cc1: all warnings being treated as errors make[5]: *** [memory.o] Error 1 make[5]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen/common/compat' make[4]: *** [compat/built_in.o] Error 2 make[4]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen/common' make[3]: *** [/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen/common/built_in.o] Error 2 make[3]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen/arch/x86' make[2]: *** [/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen/xen] Error 2 make[2]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen' make[1]: *** [install] Error 2 make[1]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/xen' make: *** [install-xen] Error 2 Do I miss something or is there a mistake in PKGBUILD? Thanks, 3000

tritron commented on 2013-03-03 20:48 (UTC)

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

thunderforce commented on 2013-03-01 18:16 (UTC)

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

luolimao commented on 2013-03-01 05:47 (UTC)

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

luolimao commented on 2013-03-01 05:34 (UTC)

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

thunderforce commented on 2013-03-01 00:34 (UTC)

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

tritron commented on 2013-02-26 05:16 (UTC)

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

Anty commented on 2013-02-25 19:39 (UTC)

@tritron Hi, Thanks, disable qemu-doc works perflectly. Regards, anty

tritron commented on 2013-02-25 14:49 (UTC)

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

tritron commented on 2013-02-25 14:45 (UTC)

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

Anty commented on 2013-02-24 02:27 (UTC)

hi, when compiling an error occurs : ./qemu-options.texi:1294: unknown command `list' ./qemu-options.texi:1294: table requires an argument: the formatter for @item ./qemu-options.texi:1294: warning: @table has text but no @item make[3]: *** [qemu-doc.html] Error 1 I think this patch should solve the problem, but i'm not trying. http://patchwork.ozlabs.org/patch/222131/ Thanks.

luolimao commented on 2013-02-17 06:45 (UTC)

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

commented on 2013-02-15 17:57 (UTC)

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

luolimao commented on 2013-02-09 18:06 (UTC)

Updated.

revellion commented on 2013-02-04 09:15 (UTC)

@deviousway, After googling around and sourcing some info from gentoo's bug i've managed to find the problem or atleast a workaround/solution to compiling Xen. Just like you i have a non-english system locale. sv_SE.UTF-8 to be exact. but by doing LANG=C makepkg I'm able to compile it successfully. Maybe the maintainer of this PKGBUILD should add LANG=C to the package() part that initiates the build to avoid this problem. The big problem however seems to reside in python2 which pukes on non-english locales. But python2 afaik is not maintained anymore with python3 being the replacement, so might be hard to get it fixed.

fernando_ccs17 commented on 2013-01-25 20:28 (UTC)

Me too. I need manually create the folder

luolimao commented on 2013-01-12 22:58 (UTC)

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

zootboy commented on 2013-01-12 22:00 (UTC)

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

luolimao commented on 2013-01-11 11:52 (UTC)

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

kantras commented on 2013-01-11 07:26 (UTC)

Download the tarball (or use yaourt to download the files then press Ctrl-C to break out of it - the files will be under something like /tmp/yaourt-tmp-<username>/aur-xen/) If you download the tarball, extract the files into a directory. Go into the directory and download the two files I mentioned into the directory, overwriting the old PKGBUILD file. You can then run "makepkg -i" to build and install

commented on 2013-01-11 06:35 (UTC)

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

commented on 2013-01-11 06:26 (UTC)

i7-3770 8gb RAM 64bit OS Linux localhost 3.6.11-1-ARCH #1 SMP PREEMPT Tue Dec 18 08:57:15 CET 2012 x86_64 GNU/Linux

kantras commented on 2013-01-11 05:54 (UTC)

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

kantras commented on 2013-01-11 04:51 (UTC)

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

commented on 2013-01-11 03:52 (UTC)

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

fernando_ccs17 commented on 2013-01-10 17:41 (UTC)

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

commented on 2013-01-10 02:01 (UTC)

--- a/tools/debugger/gdbsx/xg/xg_main.c +++ b/tools/debugger/gdbsx/xg/xg_main.c @@ -34,6 +34,7 @@ * XGTRC(): generic trace utility */ +#include <sys/types.h> #include <stdio.h> #include <stddef.h> #include <stdarg.h>

luolimao commented on 2013-01-10 00:23 (UTC)

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

commented on 2013-01-09 18:06 (UTC)

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

itsizzy commented on 2013-01-08 13:30 (UTC)

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

luolimao commented on 2013-01-08 10:37 (UTC)

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

commented on 2013-01-08 02:58 (UTC)

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

luolimao commented on 2013-01-07 22:13 (UTC)

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

commented on 2013-01-07 16:04 (UTC)

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

fernando_ccs17 commented on 2013-01-07 11:21 (UTC)

kurokuon and 3000: In PKGBUILD file, the line where have: "./configure PYTHON=/usr/bin/python2" try replacing with: "LIBS += "-librt" ./configure PYTHON=/usr/bin/python2" without quotes. Please give feedback if it works.

commented on 2013-01-07 06:01 (UTC)

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

deviousway commented on 2013-01-03 23:15 (UTC)

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

3000 commented on 2013-01-03 08:29 (UTC)

hi, I somehow can't build this. I already have xen installed on another harddrive with Xen 4.2, but here I get this error message: /usr/bin/ld: vl.o: undefined reference to symbol 'timer_settime@@GLIBC_2.3.3' /usr/bin/ld: note: 'timer_settime@@GLIBC_2.3.3' is defined in DSO /usr/lib/librt .so.1 so try adding it to the linker command line /usr/lib/librt.so.1: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[4]: *** [qemu-dm] Error 1 make[4]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools/qem u-xen-traditional-dir/i386-dm' make[3]: *** [subdir-i386-dm] Error 2 make[3]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools/qem u-xen-traditional-dir' make[2]: *** [subdir-install-qemu-xen-traditional-dir] Error 2 make[2]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/tmp/yaourt-tmp-root/aur-xen/src/xen-4.2.1/tools' make: *** [install-tools] Error 2 ==> ERROR: A failure occurred in package(). Aborting... ==> ERROR: Makepkg was unable to build xen. ==> Restart building xen ? [y/N] I get the same error display when I try to build from source. how can I fix this??

luolimao commented on 2012-12-19 03:58 (UTC)

Thanks, kantras; updated.

kantras commented on 2012-12-18 16:39 (UTC)

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

commented on 2012-12-16 10:19 (UTC)

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

kantras commented on 2012-11-25 21:03 (UTC)

You will also want to add "etc/$pkgname/xl.conf" to the backup section in the PKGBUILD file to avoid changes (such as to the ballooning settings) being clobbered during an upgrade. I also have a couple of template files for /etc/conf.d/xen{console,store}d if needed. Also, wondering it's worth making the name for dom0 to be definable via the conf file, defaulting to Domain-0 if nothing is explicitly set.

luolimao commented on 2012-11-22 18:16 (UTC)

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

paleo9 commented on 2012-11-22 15:14 (UTC)

'thinking aloud' You have demonstrated that the existence of /run/xen allows the module and its successors to load in your guest, which then runs successfully. kantras' tmpfiles.d/xen.conf will create that file, tmpfiles.d is usually used for temporary files created in /tmp or /run - fits the bill. Possible alternative: I have found in the old xencommons script 'mkdir -p /var/run/xen'. It is located before just before xenstored is started. So an equivalent ought to be the same line in ExecStartPre of xenstored.service. Could you try that? There exists systemd-tmpfiles but seems overkill for our purposes. tmpfiles is an established method used specifically for our purpose of creating '/run/xen'. The systemd service file method mimics the old xencommons way, attempting to create '/var/run/xen' @everybody: Any thoughts?

Refutationalist commented on 2012-11-22 13:06 (UTC)

@paleo9 What you are looking at *is* the initramfs loading up the xen_blkfront module in order to find its root. It can't find it's root because the socket which allows the PV to talk xen, which is supposed to exist in /run/xen. If you'll read the rest of the dump, I create said directory, and the PV loads instantly and without problems. Again: kantras' tmpfiles.d solution would appear to be the way to go and should be included.

paleo9 commented on 2012-11-22 12:42 (UTC)

@WaxyMouthfeel Welcome to Finnix! [*] Total memory: 2004MiB, shared ramdisk: 1591MiB [*] Setting up ramdisk... done [*] Loading probed module: [*] Loading probed module: xen_blkfront /* and here it freezes until I destroy the domain */ Xen is starting your pv, but the pv fails on startup when attempting to load xen_blkfront. Arch (for example) as a pv guest needs extra modules in its initramfs. The pv guest needs its initramfs image rebuilt with MODULES = "xen-blkfront xen-fbfront xen-netfront xen-kbdfront" in its /etc/mkinitramfs. Debian doesn't need this additional step to run as a pv guest. See https://wiki.archlinux.org/index.php/Xen#Installation_notes_for_domU_Paravirtualized_guests and 'Common Errors'.

kantras commented on 2012-11-22 04:34 (UTC)

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

aaronfitz commented on 2012-11-22 04:12 (UTC)

Just tried the new package and things seem to go much smoother. I had to create the folder /var/lib/xen/ by hand in order to create a HVM though. Based on the processor usage pattern after I start the HVM Windows 7 is starting, but I'm not getting any display through the video adapter I pass through to the HVM. I never got the dedicated graphics passthrough capability working on 4.1, the graphics was just passed through as a PCI device. Not sure what's going on with the PCI passthrough but I'll keep fiddling with my setup. Anyone here using this for PCI or GFX passthrough yet?

Refutationalist commented on 2012-11-22 01:54 (UTC)

Sorry to insist, but in some supported configurations /run/xen *is* needed: http://pastebin.com/QaqS2Krt kantras' tmpfiles.d solution would appear to be the way to go and should be included.

luolimao commented on 2012-11-21 22:54 (UTC)

fixed.

paleo9 commented on 2012-11-21 22:46 (UTC)

Just tried the modified xenstored.service, doesn't like it. This is the one: tested, works ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS ExecStartPost=/usr/bin/xenstore-write "/local/domain/0/name" "Domain-0" Result: Name ID Mem VCPUs State Time(s) Domain-0 0 1024 2 r----- 24.9

luolimao commented on 2012-11-21 21:50 (UTC)

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

paleo9 commented on 2012-11-21 20:30 (UTC)

Package built with archinit.patch - fail Package built without archinit.patch - successfully created, logged into and shut down a pv of Debian wheezy. created: /run/xenstored /run/xenstored.pid /var/run/xenstored /var/run/xenstored.pid not created (not needed), /run/xen /var/run/xen Using journalctl on the failed build showed xendomains failed at three points, each of which were lines added to xendomains by archinit.patch. The patch adds to xendomains function calls from rc.d/functions, which no longer exists. Previously no effect, but now causes xendomains.service to fail. Also all to do with xend. Conclusion: previously the patch was useless, now it is a liability.

kantras commented on 2012-11-20 20:04 (UTC)

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

paleo9 commented on 2012-11-20 18:09 (UTC)

/var/run/xen is being created on my system, but it is built from the official tarball, with the service files as existed in the 4.2.0-3 arch release. i.e archinit.patch was not used, but otherwise the same as 4.2.0-3. I 'll take a look tomorrow and do a full aur install of the current version.

Refutationalist commented on 2012-11-20 16:58 (UTC)

* Exactly so. /run/xen needs to exist, isn't (apparently) created by anything, and /run is a ramdisk. * Every new machine I've installed this package on won't run pv dom0's until /run/xen (or rather, /var/run/xen) exists. Going through what documentation I can find, this is the expected behavior. It could be differences in what we're using on PVs. * I don't particularly care where it happens, just that it does. :) I initially used && rather than a semi-colon, but it didn't work and systemd documentation said to use a semi-colon, so that's what I did. I am new to systemd. * I've also built it without archinit.patch and xendomains works without a lot of trouble, at least on startup. Haven't tested shutdown yet. I'm pretty sure the patch was originally one I submitted, and it doesn't appear to have much added to it. All it did was make xen's init files work with our sysvinit. I think it's also worth noting that I generally have to compile this package on a clean install with base, base-devel and the packages required by the PKGBUILD only, as the xen build process will link to other packages that I have installed on my build machine, but not on the ones I use the package on.

paleo9 commented on 2012-11-20 16:36 (UTC)

* This will attempt to create '/run/xen' every time Xen is started. * I am not sure what you mean by 'which is necessary for pv domains to run with the XL stack', pv domains run fine under xl. * '/usr/bin/xenstore-write "/local/domain/0/name" "Domain-0"' belongs better in xenstored.service, something like ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS; /usr/bin/xenstore-write "/local/domain/0/name" "Domain-0" or preferably use && instead of semicolon if that is allowed. * I agree with you about the archinit.patch, not sure it's going to break anything but certainly, the first half no longer affects anything and the second half deals with xendomains and probably no longer affects anything (I haven't had a look at things for a week). Either way, I didn't need it to build the official tarball and, if memory serves, I was able to build the Arch package without it too.

Refutationalist commented on 2012-11-20 13:52 (UTC)

Another version of the service file, this time it creates /run/xen, which is necessary for pv domains to run with the XL stack. This was the kind of thing originally handled by xend. It's a simple change, but I've renamed it xen-dom0-env.service: -------- [Unit] Description=Name the Xen Domain0 for use with XL Requires=xenstored.service ConditionPathExists=/proc/xen [Service] Type=oneshot ExecStart=/usr/bin/mkdir /run/xen ; /usr/bin/xenstore-write "/local/domain/0/name" "Domain-0" [Install] WantedBy=multi-user.target

Refutationalist commented on 2012-11-20 11:12 (UTC)

xendomains.service will break on pure systemd dom0s because of archinit.patch. The patch's original purpose was to make the xen rc files work with Arch's sysvinit better, so it should be fairly painless to remove it. Also, I think the xen-dom0-name.service file should have it's type set to oneshot rather than simple.

Refutationalist commented on 2012-11-20 10:50 (UTC)

Here's a service file to rename the dom0. xen-dom0-name.service ---- [Unit] Description=Name the Xen Domain0 for use with XL Requires=xenstored.service ConditionPathExists=/proc/xen [Service] Type=simple ExecStart=/usr/bin/xenstore-write "/local/domain/0/name" "Domain-0" [Install] WantedBy=multi-user.target

Xaseron commented on 2012-11-19 01:55 (UTC)

Typo, .service files won't be copied. for f in ${source[@]}; do [[ $f =~ .mount || $f =~ .fice ]] && install -Dm644 $f "$pkgdir"/usr/lib/systemd/system/$f

Xaseron commented on 2012-11-19 01:39 (UTC)

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

tritron commented on 2012-11-18 19:48 (UTC)

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

luolimao commented on 2012-11-17 17:19 (UTC)

@xaseron fixed

Xaseron commented on 2012-11-16 13:33 (UTC)

> xen-acpi-processor # This module may not work on all machines; try removing this first if it causes issues. Of course this module does not load, because you can't write a comment right after a module. This space is reserved for options.

Refutationalist commented on 2012-11-16 07:03 (UTC)

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

Refutationalist commented on 2012-11-15 15:44 (UTC)

Also, I've compiled and run this on a clean install. The xl toolset doesn't seem to hand proper devices to PV domains, and HVM domains reset the computer without printing anything meaningful beyond: (XEN) HVM8: int13_harddisk: function 02, unmapped device for ELDL=87 (XEN) HVM8: int13_harddisk: function 41, ELDL out of range 88 (XEN) HVM8: int13_harddisk: function 02, ELDL out of range 88 (XEN) irq.c:375: Dom8 callback via changed to Direct Vector 0xf3 To the serial console. This is for a machine that I'm deploying soon, I'll keep Arch on it for as long as I can if someone wants me to try things, otherwise I'm going to have to put something else on it and ship it.

kantras commented on 2012-11-15 07:05 (UTC)

FYI - I just uploaded a modified xenstored.service file and var-lib-xenstored.mount (which mounts /var/lib/xenstored as a tmpfs, since it doesn't need to be persistent between boots) to my temp site. As for libvirt support, I've been tracking xen-devel and its very early stages; see http://lists.xen.org/archives/html/xen-devel/2012-10/msg01853.html for the start of the thread discussing this

Refutationalist commented on 2012-11-15 04:00 (UTC)

fernando_ccs17: You have to create /var/lib/xen as a directory. I've been working on that and some other build-time things.

fernando_ccs17 commented on 2012-11-15 02:26 (UTC)

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

paleo9 commented on 2012-11-12 18:34 (UTC)

I have never used libvirt, and I do not have a hardware-virtual processor (nor any need for one), so anything I can do will be limited to pv. I have just downloaded v1.0.0 and made an initial attempt to build it. I am also checking out the abs build. However, even if it builds, it may not have all features. http://wiki.xen.org/wiki/Fedora_Host_Installation "Starting from Xen 4.2, the default toolstack is libxl. libvirt has a libxl driver, but it (at the time of writing) still lacks many important features... ...There is an on-going effort to fill the gap and render the libvirt libxl driver feature complete and fully functional, although it is yet unclear when that will happen (in particular, whether or not it will make it in time for Fedora 18." On the other hand, the tarball that I downloaded (stable libvirt 1.0.0) has News November 2 2012 at least mentions xen 4.2. So there may be hope. http://libvirt.org/news.html "various improvement and fixes when using QMP QEmu interface Support for Xen 4.2 (Jim Fehlig)" If I have anything more useful to say, I shall put it on some libvirt page and leave a comment here.

loper commented on 2012-11-11 23:09 (UTC)

@ paleo9: thanks, running # xenstore-write "/local/domain/0/name" "Domain-0" manually changed the (null) value. Is there any way to get libvirt for xen to build without error?

kantras commented on 2012-11-11 19:13 (UTC)

Writing something to add the name into xenstore (amongst other things, such as using xl to update my assignable pci devices) is on my todo list; right now I just kick off script on bootup, but that won't work for me once I start using xendomains to auto-start. @fernando_ccs17, my desktop has both an ATI and a Nvidia graphics card in it, and I spend a few hours trying to get the official Nvidia drivers working, only to have to give up for now. The problem is that Nvidia have already stated that they will only support the Quadro series when it comes to virtualization, so i'm waiting for nouveau support to improve. The ATI card, which is passed through to a Windows domU, works much better (although still with quirks at times)

paleo9 commented on 2012-11-11 15:04 (UTC)

Re "Domain-0" and (null), the relevant lines in xencommons are: echo Setting domain 0 name... xenstore-write "/local/domain/0/name" "Domain-0" My thoughts: It appears to be using "xenstore-write" to place an entry "Domain-0" into the 'name' field of its database. There is only one dom0, so there should not be a "/local/domain/1/name" or "Domain-1" etc. It is unlikely that there will be anything to be gained by checking the value of "/local/domain/0/name/", so unless errors happen it was not a high priority for getting the service file to work.

paleo9 commented on 2012-11-11 14:15 (UTC)

Nothing to worry about. In the old xencommons script, which has been replaced by systemd service files, there was a line which gave the name Domain-0. Can't remember off hand, maybe printed a line into the pid file? Anyway, this line wasn't included in the service file. It's not used by anything, just a label for human eyes.

loper commented on 2012-11-11 14:04 (UTC)

any idea why am I having (null) instead of Domain-0?

luolimao commented on 2012-11-11 13:19 (UTC)

@paleo9 Removed the file from the package.

fernando_ccs17 commented on 2012-11-11 13:17 (UTC)

Hmm... So it works only with nouveau. I Need 3D support for my 9800GT. You know...

paleo9 commented on 2012-11-11 13:03 (UTC)

Just for info: My card is nvidia, I have no problems with the nouveau driver.

fernando_ccs17 commented on 2012-11-11 12:59 (UTC)

Ok thanks. I'm also having issues with Nvidia drivers with Xen, but it looks that the problem is with the drivers, not Xen. I'm reporting a bug right now. It appears to be a known issue... http://linuxers.org/howto/how-install-nvidia-driver-xen-kernel-centos-55final

paleo9 commented on 2012-11-11 12:56 (UTC)

Error messages about "'failed to execute /usr/lib/.... xend/udev_event':No such file or directory" (lots of them) are caused by /etc/udev/rules.d/xend.rules xend is (a) deprecated and (b) not used, it is safe to remove xend.rules

fernando_ccs17 commented on 2012-11-11 12:43 (UTC)

failed to execute '/usr/lib/udev/socket:/org/xen/xend/udev_event' 'socket:/org/xen/xend/udev_event': No such file or directory I get dozens of this message on boot and on journalctl. Why's that?

commented on 2012-11-11 11:54 (UTC)

thanks luolimao, it's working now.

luolimao commented on 2012-11-10 20:55 (UTC)

It was a typo. My bad, fixed.

commented on 2012-11-10 19:35 (UTC)

I got an error during build: install: cannot stat 'xendomU.service': no such file or directory.

luolimao commented on 2012-11-08 22:20 (UTC)

I see; added. Thanks :]

kantras commented on 2012-11-08 22:10 (UTC)

@luolimao: the existing 20_linux_xen file won't pick up the kernel as archlinux deploys it, and puts it after the normal boot config so you have to explicitly select the xen boot option whenever you boot up. The 09_xen version can see the archlinux kernel and also puts it above the normal boot option so that booting into xen + dom0 is the default.

kantras commented on 2012-11-08 06:37 (UTC)

Please include the texi2html.patch file from the website I mentioned in the previous comment; it allows xen to be compiled if you have extra/texi2html 5.0-2 installed. I also uploaded 09_xen, a tweaked grub2 configration file to be dropped into /etc/grub.d so that grub-mkconfig will detect and add config to support booting the xen kernel image. If you want the EFI boot image for xen to be built, you have to use a slightly modified version of binutils; I grabbed the PKGBUILD and binutils.install for the latest stable version of binutils-multilib, then edited the PKGBUILD file to add "--enable-targets=x86_64-pep" into the list of options being passed to configure. Once I had built and installed the modified binutils-multilib, the xen.efi image was compiled when I built xen.

luolimao commented on 2012-11-08 00:53 (UTC)

@paleo9 I must have asleep when I edited the PKGBUILD yesterday, my bad. Anyway, fixed.

kantras commented on 2012-11-07 21:45 (UTC)

I just uploaded the work I had started for systemd service files for xen, into a temporary directory at http://www.kantras.info/xen/ - The key differences are that the xenstored and xenconsoled services will only start on a dom0 which has /proc/xen mounted and has the right capabilities. I also include a patch which allows newer versions of texi2html to be installed. The xendomU service is just one that I'm starting to play with, when you only want to start individual domains. I'm currently comparing the PKGBUILD against the one I'm using locally. I'm running mainly HVM domU's (linux and windows) on a test server.

paleo9 commented on 2012-11-07 14:38 (UTC)

Not working just yet, but nearly there. * xendomains is in etc/rc.d but xendomains.service looks in etc/xen/scripts n.b just something to be aware of: etc/rc.d/xendomains is a script but /etc/defaults/xendomains is a config file. * xen.conf is not copied to /etc/modules-load.d With these issues corrected, the package installs and, after configuration, I could create paravirtualised vms. I don't have a hardware virtual capable processor so cannot comment on hardware virtual etc, but have no reason for any doubt. All the best to you luolimao. ================== Other considerations: * package creates a directory in /usr/local (not allowed?) * package creates man files in /usr/share/man/{man1 man8} that are missing from xen-docs. xen-docs provides files missing from xen 4.2.0-04. The two packages combined create all man files from upstream.

luolimao commented on 2012-11-07 00:42 (UTC)

Updated to work with systemd. Much thanks to paleo9 :D

paleo9 commented on 2012-11-06 12:54 (UTC)

Systemd service files and information given in the github link below, are now in the Xen page of Archwiki. The wiki page has been completely revised for Xen 4.2, xenstored and the xl toolstack; it includes bootloader and networking configuration. https://wiki.archlinux.org/index.php/Xen

paleo9 commented on 2012-11-03 17:16 (UTC)

I created a set of systemd service files and notes to integrate with Xen 4.2. They were tested with a virgin install of Arch + Xen4.2 AUR (base, base-devel, xen AUR tarball and dependencies). Hope you find them useful. Full details https://gist.github.com/a2b71e4a17fdf7bbcfc0

paleo9 commented on 2012-11-03 17:15 (UTC)

pyxml texlive-core and transfig are no longer dependencies. They have been replaced by 'markdown'. See the list of prerequisites in README of the current Xen 4.2 download. I have built AUR xen-docs using both methods and the same set of files are created.

luolimao commented on 2012-10-28 23:58 (UTC)

Done.

fernando_ccs17 commented on 2012-10-28 21:19 (UTC)

Please add wget as dep.

luolimao commented on 2012-10-21 15:39 (UTC)

Added your fixes. Btw, the symlinking issue can be fixed by adding PYTHON=/usr/bin/python2 to the configure line (which I have done, obviously). The service file is a bit iffy, b/c it depends on the rc.d script. Will release a service file that's more "systemd-ish" soon.

commented on 2012-10-13 21:35 (UTC)

Wow what a pain to build. I needed it running...I don't have the time to do it right but I had to: remove the dom0 compression patch (looks like it was merged) remove the xen patch (i'm not convinced that made a difference or not, but saved me going through rejects) corrected the arch init patch (hopefully I didn't break the init script...it still seems to work correctly) symlinked python2-config and python2 to python-config and python, respectively. Yikes. Build wouldn't find python2 libs otherwise, and doesn't work with python 3. This needs a better fix. installed yajl, git, and wget (building required them beyond dependencies in PKGBUILD) I put up a github repo so I could share a fixed PKGBUILD and archinit patch if anyone needs to build this https://github.com/iamb/arch-xen

aaronfitz commented on 2012-10-12 11:21 (UTC)

Looks like someone made an attempt to update the PKGBUILD to 4.2. I gave it a quick go and the patching fails. I don't have time to look into it today but wanted to let people know what's going on ==> Starting build()... patching file tools/hotplug/Linux/init.d/xencommons Hunk #2 succeeded at 29 with fuzz 1. Hunk #3 FAILED at 54. Hunk #4 FAILED at 63. 2 out of 4 hunks FAILED -- saving rejects to file tools/hotplug/Linux/init.d/xencommons.rej patching file tools/hotplug/Linux/init.d/xend patching file tools/hotplug/Linux/init.d/xendomains Hunk #4 succeeded at 200 (offset 5 lines). Hunk #5 succeeded at 266 (offset 5 lines). Hunk #6 succeeded at 320 (offset 5 lines). Hunk #7 succeeded at 433 (offset 5 lines). patching file tools/hotplug/Linux/init.d/xen-watchdog ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build xen.

fernando_ccs17 commented on 2012-10-06 17:25 (UTC)

So... nothing yet?

franciscod commented on 2012-10-03 02:27 (UTC)

Please add wget and python2 as deps, the build fails without them.

franciscod commented on 2012-10-03 02:26 (UTC)

Please add wget and python2 as deps, the build fails without them.

commented on 2012-09-29 09:35 (UTC)

Have disowned the package. Life's too busy to get this done and don't want to keep people waiting on 4.2.

kantras commented on 2012-09-29 04:17 (UTC)

I'm about 85% complete on a 4.2 PKGBUILD - have systemd inits + texi2html working, just have to finish cleaning up the other init scripts

commented on 2012-09-26 19:43 (UTC)

If someone wants to write a PKGBUILD for 4.2, I can orphan this package for them. Not sure when I will get time.

fernando_ccs17 commented on 2012-09-26 17:13 (UTC)

when do you plan to update to 4.2?

commented on 2012-09-01 13:17 (UTC)

The error was resolved after installing texi2html version 1.82, as stated by Xaseron. Otherwise there was no problem.

commented on 2012-09-01 10:31 (UTC)

The build process error: *** No rule to make target 'unxz.o', needed by 'built_in.o'. Stop. *** Any ideas about where could be the problem? Thanks

commented on 2012-08-30 19:48 (UTC)

I can only get xen to detect my full memory with this patch. This seems to be a problem of certain UEFI mainboards, see https://bugzilla.redhat.com/show_bug.cgi?id=819235#c3 and http://serverfault.com/questions/342109/xen-only-sees-512mb-of-system-ram-should-be-8gb-uefi-boot: This seems to work fine on my machine, however I can not say anthing about potential side-effects. -----------snip----------------- diff -Naur xen-4.1.3.org/xen/arch/x86/setup.c xen-4.1.3/xen/arch/x86/setup.c --- xen-4.1.3.org/xen/arch/x86/setup.c 2012-08-30 21:15:37.414593798 +0200 +++ xen-4.1.3/xen/arch/x86/setup.c 2012-08-30 21:24:41.801533785 +0200 @@ -661,6 +661,8 @@ if ( ((unsigned long)cpu0_stack & (STACK_SIZE-1)) != 0 ) EARLY_FAIL("Misaligned CPU0 stack.\n"); +#if 0 + /* disable raw e801 and e820 for now in favor of multiboot provided maps */ if ( e820_raw_nr != 0 ) { memmap_type = "Xen-e820"; @@ -676,7 +678,9 @@ e820_raw[1].type = E820_RAM; e820_raw_nr = 2; } - else if ( mbi->flags & MBI_MEMMAP ) + else +#endif + if ( mbi->flags & MBI_MEMMAP ) { memmap_type = "Multiboot-e820"; while ( (bytes < mbi->mmap_length) && (e820_raw_nr < E820MAX) )

commented on 2012-08-13 09:35 (UTC)

Have updated for 4.1.3. Not sure what causes stubdom to break for you guys. Works for me (I need it for pv-grub). If you work out a fix let me know.

Xaseron commented on 2012-08-13 08:49 (UTC)

In order to compile my PKGBUILD of 4.1.3 you need an old version of texi2html, below 5.0. Stubdom still breaks, but i don't need it ;-) #Mantainer: Luceo #Contributor: Revellion #Contributor: Sergej pkgname=xen pkgver=4.1.3 pkgrel=1 pkgdesc="Xen 4 (hypervisor and tools)" arch=(i686 x86_64) url="http://xen.org/" license="GPL" depends=('bin86' 'xz' 'bzip2' 'iproute' 'bridge-utils' 'python2' 'sdl' 'zlib' 'e2fsprogs' 'pkgconfig' 'gnutls' 'lzo2' 'glibc') [ "$CARCH" == "x86_64" ] && depends=(${depends} 'lib32-glibc') optdepends=('xen-docs: Xen Official Documentation') makedepends=('dev86' 'ocaml-findlib' 'iasl') conflicts=('xen-4.2' 'xen-hg-unstable' 'xen-gdbsx' 'xen4-hg' 'xen4' 'xen3' 'xen-hv-tools' 'libxen4') provides=('xen') backup=('etc/xen/xend-config.sxp' 'etc/xen/xend-pci-permissive.sxp' 'etc/xen/xend-pci-quirks.sxp') options=(!strip) optional=('xen-docs: documentation for xen') install=xen.install source=( http://bits.xensource.com/oss-xen/release/${pkgver}/xen-${pkgver}.tar.gz 09_xen archinit.patch dom0_xz_decompression.patch ) build() { cd $srcdir/xen-${pkgver} patch -p1 -i ../archinit.patch patch -p1 -i ../dom0_xz_decompression.patch unset CFLAGS LDFLAGS make PYTHON=python2 DESTDIR=$pkgdir install-xen make PYTHON=python2 DESTDIR=$pkgdir install-tools #make PYTHON=python2 DESTDIR=$pkgdir install-stubdom sed -i 's#XENDOM_CONFIG=/etc/sysconfig/xendomains#XENDOM_CONFIG=/etc/conf.d/xendomains#' $pkgdir/etc/init.d/xendomains sed -i "s#touch /var/lock/subsys/xend#mkdir -p /var/lock/subsys\n touch /var/lock/subsys/xend#" $pkgdir/etc/init.d/xend [ -d $pkgdir/usr/lib64 ] && ( cd $pkgdir/usr && cp -R lib64/* lib/ && rm -R lib64 ) ( cd $pkgdir/etc && mv init.d rc.d ) || return 1 rm -f $pkgdir/usr/share/man/man1/qemu-img.1* \ $pkgdir/usr/share/man/man1/qemu.1* ## First experiment to generate grub2.cfg entry #mkdir -p $pkgdir/etc/grub.d #chmod +x $srcdir/09_xen #cp $srcdir/09_xen $pkgdir/etc/grub.d ############ kill unwanted stuff ############ # stubdom: newlib rm -rf $pkgdir/usr/*-xen-elf # hypervisor symlinks rm -rf $pkgdir/boot/xen-4.1.gz rm -rf $pkgdir/boot/xen-4.gz rm -rf $pkgdir/boot/xen.gz # silly doc dir fun rm -rf $pkgdir/usr/share/doc/xen rm -rf $pkgdir/usr/share/doc/qemu # Pointless helper rm -f $pkgdir/usr/sbin/xen-python-path # qemu stuff (unused or available from upstream) rm -rf $pkgdir/usr/share/xen/man rm -rf $pkgdir/usr/bin/qemu-*-xen for file in bios.bin openbios-sparc32 openbios-sparc64 ppc_rom.bin \ pxe-e1000.bin pxe-ne2k_pci.bin pxe-pcnet.bin pxe-rtl8139.bin \ vgabios.bin vgabios-cirrus.bin video.x openbios-ppc bamboo.dtb do rm -f $pkgdir/usr/share/xen/qemu/$file done # adhere to Static Library Packaging Guidelines rm -rf $pkgdir/usr/lib/*.a } md5sums=( 'bed929d5c5e5135cab40e2a6aab73fa0' '86b98d762ebb43230a038f0a41b0326b' '7a1ed81ecc828037724bb3280058c9fc' '4aebccf16b578ed97aa8bab945011f35' )

robertfoster commented on 2012-08-11 00:47 (UTC)

4.1.3 is out

workdowg commented on 2012-08-06 17:41 (UTC)

@beej175560 - "This package builds correctly for me if I set MAKEFLAGS="-j1" in /etc/makepkg.conf" Didn't see this the first time...I concur.

workdowg commented on 2012-08-05 02:53 (UTC)

i8259.c:66:9: error: initialization from incompatible pointer type [-Werror] (MANY lines in between...) i8259.c:70:5: error: (near initialization for 'interrupt[255]') [-Werror] cc1: all warnings being treated as errors make[4]: *** [i8259.o] Error 1 make[4]: Leaving directory `/tmp/packerbuild-0/xen/xen/src/xen-4.1.2/xen/arch/x86' make[3]: *** [/tmp/packerbuild-0/xen/xen/src/xen-4.1.2/xen/arch/x86/built_in.o] Error 2 make[3]: Leaving directory `/tmp/packerbuild-0/xen/xen/src/xen-4.1.2/xen/arch/x86' make[2]: *** [/tmp/packerbuild-0/xen/xen/src/xen-4.1.2/xen/xen] Error 2 make[2]: Leaving directory `/tmp/packerbuild-0/xen/xen/src/xen-4.1.2/xen' make[1]: *** [install] Error 2 make[1]: Leaving directory `/tmp/packerbuild-0/xen/xen/src/xen-4.1.2/xen' make: *** [install-xen] Error 2 ==> ERROR: A failure occurred in build(). Aborting... The build failed. Anyone else...

miffe commented on 2012-07-31 11:52 (UTC)

This patch to the PKGBUILD makes it build on i686, fixes parallel make and depends on x86_64 --- PKGBUILD.old 2012-07-23 20:30:26.000000000 +0200 +++ PKGBUILD 2012-07-31 13:49:55.524274223 +0200 @@ -12 +12 @@ -[ "$CARCH" == "x86_64" ] && depends=(${depends} 'lib32-glibc') +[ "$CARCH" == "x86_64" ] && depends=(${depends[*]} 'lib32-glibc') @@ -18 +18 @@ -options=(!strip) +options=(!strip !makeflags !buildflags) @@ -28,0 +29 @@ + fix-i8259.patch::http://lists.xen.org/archives/html/xen-devel/2012-01/txto1FW8UIpuq.txt @@ -40,2 +41 @@ - -unset CFLAGS LDFLAGS + patch -p1 -i $srcdir/fix-i8259.patch

commented on 2012-07-27 01:06 (UTC)

This package builds correctly for me if I set MAKEFLAGS="-j1" in /etc/makepkg.conf Apparently it triggers some bug in GNU make when compiled with parallel make.

Mr.Smith1974 commented on 2012-07-24 18:43 (UTC)

@luceo - No problem. http://dpaste.com/774714/

commented on 2012-07-24 11:33 (UTC)

@Mrs.Smith1974 - Can you show more output? That text only shows warnings.

Mr.Smith1974 commented on 2012-07-24 08:02 (UTC)

minios.c: In function ‘minios_detect’: minios.c:15:34: warning: unused parameter ‘a’ [-Wunused-parameter] minios.c: In function ‘minios_init’: minios.c:21:32: warning: unused parameter ‘a’ [-Wunused-parameter] minios.c: In function ‘minios_cleanup’: minios.c:26:35: warning: unused parameter ‘a’ [-Wunused-parameter] rm -f libpci.a ar rcs libpci.a access.o generic.o dump.o names.o filter.o minios.o ranlib libpci.a sed <libpci.pc.in >libpci.pc -e 's,@PREFIX@,/usr/local,' \ -e 's,@INCDIR@,/usr/local/include,' \ -e 's,@LIBDIR@,/usr/local/lib64,' \ -e 's,@IDSDIR@,/usr/local/share,' \ -e 's,@VERSION@,2.2.9,' \ -e 's,@LIBZ@,-lz,' make[3]: Leaving directory `/tmp/yaourt-tmp-user/aur-xen/src/xen-4.1.2/stubdom/pciutils-x86_64/lib' make[2]: Leaving directory `/tmp/yaourt-tmp-user/aur-xen/src/xen-4.1.2/stubdom/pciutils-x86_64' make[1]: Leaving directory `/tmp/yaourt-tmp-user/aur-xen/src/xen-4.1.2/stubdom' make: *** [install-stubdom] Error 2 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build xen. ==> Restart building xen ? [y/N]

commented on 2012-07-23 21:08 (UTC)

I've adopted this package and uploaded a 'working' build. Tested on x64 fresh build.

commented on 2012-07-19 15:55 (UTC)

Mad_Dud: dev86 is part of [multilib] repo which you can enable in /etc/pacman.conf by uncommenting. I have successfully compiled (but not yet tested) this just by changing 'xz-utils' to 'xz' in PKGBUILD.

Mad_Dud commented on 2012-07-15 20:31 (UTC)

Hello, Dependency `dev86' of `xen' does not exist. Which package should be used instead of dev86?

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

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

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.

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.

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

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?

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

commented on 2011-10-07 05:41 (UTC)

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

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

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

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

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

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

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

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.

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

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.

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.

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?

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'

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

commented on 2010-12-17 09:32 (UTC)

python2 should be in x86_64 depends, not python.

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.

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

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

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

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.

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

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?

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

mortzu commented on 2010-06-24 12:38 (UTC)

this package is now without kernel. so please use kernel26-xen-dom0

commented on 2010-04-07 21:32 (UTC)

Xen 4.0 is out