Package Details: xen 4.19.1pre-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.67
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2024-09-20 00:31 (UTC)

Dependencies (63)

Sources (7)

Pinned Comments

Refutationalist commented on 2024-05-22 22:08 (UTC) (edited on 2024-05-23 00:07 (UTC) by Refutationalist)

As of now (2024-22-05) Xen with stubdom doesn't build because of a problem in the imported code. Been this way for about two weeks. Anyone else seeing this behavior?

Also, there is a lot of work happening on Xen in my development repo, thanks to @Serus. Check it out at: https://github.com/refutationalist/saur

Latest Comments

« First ‹ Previous 1 .. 38 39 40 41 42 43 44 45 46 47 48 .. 101 Next › Last »

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

« First ‹ Previous 1 .. 38 39 40 41 42 43 44 45 46 47 48 .. 101 Next › Last »