Stops systems booting up degraded, makes xendomains work.

Some things start up that systemd suspects but xen breaks using the current Arch xen package from AUR¹⁾. Anyway, xen module name have been prepended with xen- and this is not reflected in one udev rule.

in file /etc/udev/rules.d/xen-backend.rules

a line says:
KERNEL=="evtchn", NAME="xen/%k"

*should* read:
KERNEL=="xen-evtchn", NAME="xen/%k"

in file /usr/lib/modules-load.d/xen.conf:

• change evtchn to xen-evtchn
• change gntdev to xen-gntdev
• remove netbk entirely, it is not a module
• change xen-scsibk to xen-scsiback
• remove pciback
• remove usbbk
• remove blktap and blktap2

Keep in mind, most of the modules referenced are from old xen kernels, or are just things that don't exist. If you're running into this problem, you aren't losing anything by removing these lines.

Final file, for your copypasta pleasure:

xen-evtchn
xen-gntdev
xen-gntalloc
xen-blkback
xen-netback
xen-pciback
xen-evtchn
xen-gntdev
xen-scsiback
xen-acpi-processor

And that fixes that annoyance, system doesn't start degraded.

I use LVM and netctl because both libvirtd and machined are piles that I just don't fucking need to deal with right now. Added a wait for a device using a perl script and told it to not start until my netctl stuff was done, and we were good. the top of my xendomains unit file looked something like this:

[Unit]
Description=Xendomains - start and stop guests on boot and shutdown
Requires=proc-xen.mount xenstored.service
After=proc-xen.mount xenstored.service xenconsoled.service xen-init-dom0.service
After=netctl@out0.service 
After=remote-fs.target
ConditionPathExists=/proc/xen/capabilities

[Service]
Type=oneshot
RemainAfterExit=true
ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
ExecStartPre=/usr/local/bin/waitfor /dev/flG0/brainguy

Eventually, I'd like to come up with some unit files that work directly with the xl tools. I try to keep my levels of abstraction when admining systems to single digit numbers, for some reason.