Package Details: xen-docs 4.12.0-1

Git Clone URL: (read-only)
Package Base: xen
Description: Virtual Machine Hypervisor documentation
Upstream URL:
Keywords: hypervisor virtualization xen
Licenses: GPL2
Provides: xen-docs-4.12.0
Submitter: sergej
Maintainer: mbroemme
Last Packager: mbroemme
Votes: 178
Popularity: 0.030199
First Submitted: 2009-11-09 11:22
Last Updated: 2019-04-29 22:03

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


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:

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.

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:

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


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.


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