Package Details: xen-stubdom 4.20.0-2

Git Clone URL: https://aur.archlinux.org/xen.git (read-only, click to copy)
Package Base: xen
Description: Xen hypervisor stubdom files
Upstream URL: https://xenproject.org/
Keywords: hypervisor virtualization xen
Licenses: GPL2
Submitter: sergej
Maintainer: Refutationalist
Last Packager: Refutationalist
Votes: 184
Popularity: 0.069676
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2025-03-13 08:19 (UTC)

Dependencies (42)

Required by (3)

Sources (13)

Pinned Comments

Refutationalist commented on 2025-03-12 12:06 (UTC) (edited on 2025-03-13 08:23 (UTC) by Refutationalist)

We've moved to the newly-stable 4.20.0 branch. There are also other changes:

  • stubdom is fixed by disabling the vtmp and vtpmmgr components. This gets rid of a few source files and our remaining patches.
  • Debug files are only removed if the debug option is not set in makepkg.cfg (or the PKGBUILD itself)
  • pygrub has been removed
  • optdepends are adjusted for the upcoming xen-grub split package for the various Xen flavored builds.

If you're still using pygrub note that it is deprecated. The solution is to build PV grub instead, which used to be in AUR but is now missing. I am asking a couple questions on the mailing list, and I intend to put my current build of xen-grub (which supersedes xen-pvhgrub) on AUR as soon as possible. If you need to build it before that occurs, you can find it in my PKGBUILD repo.

EDIT: 4.20.0-2 adds support for the xen-edk2 package, which has a fixed UEFI for xen

Latest Comments

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

kantras commented on 2015-04-18 02:16 (UTC)

Already fixed in my local copy, will be uploading once I get back to that machine

daniel_shub commented on 2015-04-17 14:50 (UTC)

I am having the same problem that @ArthurBorsboom is having with makepkg not being able to find tmpfiles.d-xen.conf when I build in a clean chroot. I am pretty sure install -Dm644 ../../tmpfiles.d-$pkgname.conf usr/lib/tmpfiles.d/$pkgname.conf is making an assumption about the location of $srcdir relative to $pkgdir. I think it should be install -Dm644 $srcdir/tmpfiles.d-$pkgname.conf usr/lib/tmpfiles.d/$pkgname.conf If I am correct, there are a couple of other lines immediately afterwards that also need the change. I think to be totaly robust, $srcdir should be wrapped in quotes throughout the PKGBUILD.

tritron commented on 2015-04-08 19:07 (UTC)

How is video passing with this xen ? I tried xen efi aur and could not get this working. I had switched to kvm from xen 4.4 and kvm is so much better.

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.

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