Trying out Xen
I love my “homelab” but you know what’d make me like it better? If I could run <2010s SW entirely hehe. Why? because I am fucking stupid and want to subject myself to hell. I’m talking Xen hypervisor, CentOS 5 guests running Cherokee, SMBD, maybe even LDAP and eventually my own PKI infrastructure.
At first I decided to use openSUSE, I installed Leap 15.6 and realized it’s kernel is too old for my Intel Core Ultra 7 265k, which ok, makes sense. I proceeded to install the backported linux kernel repo and update to that. Fine works great, however the issue came when I wanted to do VLAN tagging in libvirt. Turns out you need libvirt version >11 to do that nicely in the XML of your appliances. So like any sane person I said let me go get the Virtualization backports from OBS for that too!
Then I hit a huge problem, a cascade of failures…
My favorite part was when it said “nothing provides %{primary_python}” hello? LOL did someone not setup their rpm macros right???
I said fuck it lemme go install Debian 13, I hear it has excellent Xen support and Debian should just work yk? HAHAHAHAHAAHHA either I’m stupid or something is very wrong with their packaging of Xen…
Excuse me what the actual FUCK is this? the xen.service it uses to start the Xen services wraps /etc/init.d/xen which uses start-stop-daemon as a safe wrapper to start xenstored/oxenstored, and start-stop-daemon is a wrapper that DOES NOTHING IT JUST EXITS AAAAAAAAAAAAAAAAAAAAAAAAAAA
I’m gonna lose it. Maybe my installation got fucked up somehow? I don’t know… anyway, I compiled this https://github.com/daleobrien/start-stop-daemon and replaced the wrapper with it and all was well.
I did however notice that libvirtd would need be restarted after boot since it couldn’t initialize it’s Xen backend, this happens because libvirtd starts before xen.service.
I fixed it by adding an After= statement in libvirtd.service, on my install it has an After= statement that contains xencommons.service but I have xen.service only.
For people who stumble upon this issue, I’ll place the kernel dmesg keyphrases below so if Google decides to send their botswarm here it’s searchable.
Tags: xenbus_probe:205 blocked for more than seconds xs_talkv __pfx_autoremove_wake_function xs_watch register_xenbus_watch
