Package Details: xen-docs 4.19.1pre-1

Git Clone URL: https://aur.archlinux.org/xen.git (read-only, click to copy)
Package Base: xen
Description: Xen hypervisor documentation and man pages
Upstream URL: https://xenproject.org/
Keywords: hypervisor virtualization xen
Licenses: GPL2
Submitter: sergej
Maintainer: Refutationalist
Last Packager: Refutationalist
Votes: 185
Popularity: 0.46
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2024-09-20 00:31 (UTC)

Pinned Comments

Refutationalist commented on 2024-12-06 01:37 (UTC)

Please Note: Per best-practices by upstream this package follows the git stable branch. Minor releases do not require a version bump and the PKGBUILD will provide the appropriate version number.

stubdom is still broken.

Latest Comments

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

zir_blazer commented on 2015-04-08 18:09 (UTC)

I can confirm the last post. The syntax of the dom0_mem option provided in the efi-xen.cfg file is wrong, the correct one is with a : instead of a = in the max parameter. If you're using UEFI Boot, you will eventually notice it. Also, an issue popped where if creating an Arch Linux DomU, installing Xorg and a Desktop Manager, the Mouse cursor is invisible. At least some other guy had the same issue: http://lists.xenproject.org/archives/html/xen-users/2015-04/msg00033.html I can confirm it. I don't know if its a Xen issue, or any other of the upgraded Arch Linux packages related to it (xorg-server 1.17.1 comes to mind). I'm using the xf86-video-vesa Driver. Finally, I made public an english installation guide for Arch Linux and Xen, which I suppose some people here may find interesing: http://lists.xenproject.org/archives/html/xen-devel/2015-04/msg00709.html

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

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