Arch Linux User Repository

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 -

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?

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.

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

@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 :)

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

@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

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

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

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