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.071098
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2025-03-13 08:19 (UTC)

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 .. 76 77 78 79 80 81 82 83 84 85 86 .. 101 Next › Last »

kantras commented on 2012-12-18 16:39 (UTC)

4.2.1 has been released. The exist PKGBUILD can be used (once the shasum's are updated) or I just uploaded a modified copy to http://www.kantras.info/xen/PKGBUILD (It also has a fix so that updates won't clobber the /etc/xen/xl.conf file.) I've just built the new version and have it running on a workstation.

<deleted-account> commented on 2012-12-16 10:19 (UTC)

Custom backend network device name seems not working. When I tried vif = ['ip=192.168.1,2, vifname=vif1.0, backend=networkvm'] in the client domU config file, the backend device in driver domain (networkvm) was named according to default vifDOMID.DEVID and not vif1.0 as specified in the script - resulting in different names every time I restarted the client domU. Any idea what could cause this strange behaviour?

kantras commented on 2012-11-25 21:03 (UTC)

You will also want to add "etc/$pkgname/xl.conf" to the backup section in the PKGBUILD file to avoid changes (such as to the ballooning settings) being clobbered during an upgrade. I also have a couple of template files for /etc/conf.d/xen{console,store}d if needed. Also, wondering it's worth making the name for dom0 to be definable via the conf file, defaulting to Domain-0 if nothing is explicitly set.

luolimao commented on 2012-11-22 18:16 (UTC)

Used tmpfiles method, and added the tmpfiles service to requires/after of xenstored.service

paleo9 commented on 2012-11-22 15:14 (UTC)

'thinking aloud' You have demonstrated that the existence of /run/xen allows the module and its successors to load in your guest, which then runs successfully. kantras' tmpfiles.d/xen.conf will create that file, tmpfiles.d is usually used for temporary files created in /tmp or /run - fits the bill. Possible alternative: I have found in the old xencommons script 'mkdir -p /var/run/xen'. It is located before just before xenstored is started. So an equivalent ought to be the same line in ExecStartPre of xenstored.service. Could you try that? There exists systemd-tmpfiles but seems overkill for our purposes. tmpfiles is an established method used specifically for our purpose of creating '/run/xen'. The systemd service file method mimics the old xencommons way, attempting to create '/var/run/xen' @everybody: Any thoughts?

Refutationalist commented on 2012-11-22 13:06 (UTC)

@paleo9 What you are looking at *is* the initramfs loading up the xen_blkfront module in order to find its root. It can't find it's root because the socket which allows the PV to talk xen, which is supposed to exist in /run/xen. If you'll read the rest of the dump, I create said directory, and the PV loads instantly and without problems. Again: kantras' tmpfiles.d solution would appear to be the way to go and should be included.

paleo9 commented on 2012-11-22 12:42 (UTC)

@WaxyMouthfeel Welcome to Finnix! [*] Total memory: 2004MiB, shared ramdisk: 1591MiB [*] Setting up ramdisk... done [*] Loading probed module: [*] Loading probed module: xen_blkfront /* and here it freezes until I destroy the domain */ Xen is starting your pv, but the pv fails on startup when attempting to load xen_blkfront. Arch (for example) as a pv guest needs extra modules in its initramfs. The pv guest needs its initramfs image rebuilt with MODULES = "xen-blkfront xen-fbfront xen-netfront xen-kbdfront" in its /etc/mkinitramfs. Debian doesn't need this additional step to run as a pv guest. See https://wiki.archlinux.org/index.php/Xen#Installation_notes_for_domU_Paravirtualized_guests and 'Common Errors'.

kantras commented on 2012-11-22 04:34 (UTC)

I have a Windows 7 domU with an ATI 6770 passed through as a secondary adaptor, along with a USB 2.0 root hub and USB 3.0 root hub. Its been working well, except that I can't install the PV drivers without the ATI driver appearing to cause a blue screen on bootup. Still runs well without them. This is on a ASUS Sabertooth 990FX motherboard with an AMD Phenom II x4 965 processor and a total of 12Gb on board (6Gb assigned to the Windows domU)

aaronfitz commented on 2012-11-22 04:12 (UTC)

Just tried the new package and things seem to go much smoother. I had to create the folder /var/lib/xen/ by hand in order to create a HVM though. Based on the processor usage pattern after I start the HVM Windows 7 is starting, but I'm not getting any display through the video adapter I pass through to the HVM. I never got the dedicated graphics passthrough capability working on 4.1, the graphics was just passed through as a PCI device. Not sure what's going on with the PCI passthrough but I'll keep fiddling with my setup. Anyone here using this for PCI or GFX passthrough yet?

Refutationalist commented on 2012-11-22 01:54 (UTC)

Sorry to insist, but in some supported configurations /run/xen *is* needed: http://pastebin.com/QaqS2Krt kantras' tmpfiles.d solution would appear to be the way to go and should be included.

« First ‹ Previous 1 .. 76 77 78 79 80 81 82 83 84 85 86 .. 101 Next › Last »