Arch Linux User Repository

* Exactly so. /run/xen needs to exist, isn't (apparently) created by anything, and /run is a ramdisk. * Every new machine I've installed this package on won't run pv dom0's until /run/xen (or rather, /var/run/xen) exists. Going through what documentation I can find, this is the expected behavior. It could be differences in what we're using on PVs. * I don't particularly care where it happens, just that it does. :) I initially used && rather than a semi-colon, but it didn't work and systemd documentation said to use a semi-colon, so that's what I did. I am new to systemd. * I've also built it without archinit.patch and xendomains works without a lot of trouble, at least on startup. Haven't tested shutdown yet. I'm pretty sure the patch was originally one I submitted, and it doesn't appear to have much added to it. All it did was make xen's init files work with our sysvinit. I think it's also worth noting that I generally have to compile this package on a clean install with base, base-devel and the packages required by the PKGBUILD only, as the xen build process will link to other packages that I have installed on my build machine, but not on the ones I use the package on.

* This will attempt to create '/run/xen' every time Xen is started. * I am not sure what you mean by 'which is necessary for pv domains to run with the XL stack', pv domains run fine under xl. * '/usr/bin/xenstore-write "/local/domain/0/name" "Domain-0"' belongs better in xenstored.service, something like ExecStart=/usr/sbin/xenstored --pid-file /var/run/xenstored.pid $XENSTORED_ARGS; /usr/bin/xenstore-write "/local/domain/0/name" "Domain-0" or preferably use && instead of semicolon if that is allowed. * I agree with you about the archinit.patch, not sure it's going to break anything but certainly, the first half no longer affects anything and the second half deals with xendomains and probably no longer affects anything (I haven't had a look at things for a week). Either way, I didn't need it to build the official tarball and, if memory serves, I was able to build the Arch package without it too.

Another version of the service file, this time it creates /run/xen, which is necessary for pv domains to run with the XL stack. This was the kind of thing originally handled by xend. It's a simple change, but I've renamed it xen-dom0-env.service: -------- [Unit] Description=Name the Xen Domain0 for use with XL Requires=xenstored.service ConditionPathExists=/proc/xen [Service] Type=oneshot ExecStart=/usr/bin/mkdir /run/xen ; /usr/bin/xenstore-write "/local/domain/0/name" "Domain-0" [Install] WantedBy=multi-user.target

xendomains.service will break on pure systemd dom0s because of archinit.patch. The patch's original purpose was to make the xen rc files work with Arch's sysvinit better, so it should be fairly painless to remove it. Also, I think the xen-dom0-name.service file should have it's type set to oneshot rather than simple.

Here's a service file to rename the dom0. xen-dom0-name.service ---- [Unit] Description=Name the Xen Domain0 for use with XL Requires=xenstored.service ConditionPathExists=/proc/xen [Service] Type=simple ExecStart=/usr/bin/xenstore-write "/local/domain/0/name" "Domain-0" [Install] WantedBy=multi-user.target

Typo, .service files won't be copied. for f in ${source[@]}; do [[ $f =~ .mount || $f =~ .fice ]] && install -Dm644 $f "$pkgdir"/usr/lib/systemd/system/$f

Remove the instruction of addin xenfs to fstab from xen.install. This is not needed because proc-xen.mount does that and it disables the possibility to boot the system without hypervisior.