Search Criteria
Package Base Details: xen
Package Actions
| Git Clone URL: | https://aur.archlinux.org/xen.git (read-only, click to copy) |
|---|---|
| Keywords: | hypervisor virtualization xen |
| Submitter: | sergej |
| Maintainer: | Refutationalist |
| Last Packager: | Refutationalist |
| Votes: | 185 |
| Popularity: | 0.39 |
| First Submitted: | 2009-11-09 11:22 (UTC) |
| Last Updated: | 2024-01-19 23:00 (UTC) |
Latest Comments
« First ‹ Previous 1 2 3 4 5 6 7 .. 11 Next › Last »
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.
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.patchNeeds 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.patchin 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)
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_sourcesas it's not for stubdom, set rundir, and then added a hook to extract firmware fromintel-ucodeso 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.gzto/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:
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)
Ah, thanks.
Thanks! Please post a link when you do :)
JohnTh commented on 2020-04-04 19:20 (UTC)
Hey FF,
Great to see progress.
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.servicewill 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-622244Yes, 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=yin 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)
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.
Fixed (locally).
Will add before moving to the repos.
Can you explain exactly what is the issue here?
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:
Worth cleanup of
usr/lib/modules-load.d/xen.confto 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/;};' {} \;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.
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-xenare 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.xcto 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
I cannot use the current Arch system QEMU:
Tested with: domU.cfg options
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:
For
backup=(), this is probably the list of configuration file: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:
Xen could not use OVMF's code.fd and vars.fd separately. It would be very simple to split Arch's OVMF package to ship the unified file in another package. The Arch bug has been ignored for years https://bugs.archlinux.org/task/58635
QEMU seems to need to be built with Xen headers in place for Xen backend support Debian installs libxen-dev before building QEMU https://salsa.debian.org/qemu-team/qemu/-/blob/debian-unstable/debian/control-in https://salsa.debian.org/xen-team/debian-xen/-/blob/master/debian/control Xen uses --enable-xen for the in-tree copy https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/Makefile;h=c10946e3b15a5a14aa83e4bbfda759b3681692de;hb=HEAD#l241
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:
Fix up the current 4.12.1 build like so: https://github.com/invisiblek/xen-aur/commits/4.12.1-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
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.
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:
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.
<deleted-account> 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:
Fix requires removing debug in the PKGBUILD:
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:
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
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.cfgfor Xen EFI cannot use theintel-ucode.imgmicrocode binary produced by theintel-ucodesystem 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:
And then change
xen.cfgto use this new patched ramdisk.You can verify the fix with:
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
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 todsdt_anycpu' util.c:(.text+0x1b65): undefined reference todsdt_15cpu' ovmf.o: In functionovmf_acpi_build_tables': ovmf.c:(.text+0xf8): undefined reference todsdt_anycpu_qemu_xen' seabios.o: In functionseabios_acpi_build_tables': seabios.c:(.text+0x25a): undefined reference todsdt_anycpu_qemu_xen' rombios.o: In functionrombios_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.patchis 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.
Notice the
--with-system-ovmfdoesn't have a path. So Xen tries to access the fileyeswhen 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:
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.
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.patchis 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):
« First ‹ Previous 1 2 3 4 5 6 7 .. 11 Next › Last »