Package Base Details: xen

Git Clone URL: https://aur.archlinux.org/xen.git (read-only)
Keywords: hypervisor virtualization xen
Submitter: sergej
Maintainer: mbroemme
Last Packager: mbroemme
Votes: 178
Popularity: 0.032085
First Submitted: 2009-11-09 11:22
Last Updated: 2019-04-29 22:03

Packages (2)

Latest Comments

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

linuxninja commented on 2019-07-19 07:50

fresh install of arch

attempted to install xen - failed

removed gcc v9, installed gcc-8

symlinked gcc -> gcc-8

re-tried install of xen - failed

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

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

Installed python (python v3)

re-tried install of xen - failed

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

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

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

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

CyrIng commented on 2019-06-29 09:38

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

aiyuchan commented on 2019-06-18 21:14

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

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

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

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

Sam12 commented on 2019-04-17 05:50

the http://google.com

dhlk commented on 2019-03-02 21:09

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

Error looks something like this:

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

Fix requires removing debug in the PKGBUILD:

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

CyrIng commented on 2018-12-06 13:08

Works like a charm, Thank you.

eduncan911 commented on 2018-10-31 15:46

@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

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

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

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