Mon, 23 Mar 2015
Backward Compatibility
One of the alleged advantages of certain family of operating systems from Redmond is backward compatibility. They say they support interfaces and applications back to the DOS era, and they sometimes even use this feature as an excuse for some doubtful technical choices they made. Yesterday I have discovered that it is not as good as they often say.
I wanted to install The Neverhood, an old 1996 adventure game. The result was the perfectly working game under WINE and Linux, and partly-working game under Windows 8.1: the gameplay was OK, but the in-game video sequences and their sound were too sluggish, as if it required 5 to 10 times more powerful hardware. According to the discussion forum posts about this topic, it is a common problem in newer versions of Windows. The recommended solution is to run the game under ScummVM, which is a rewrite of many ancient game engines.
Remember this the next time you hear an exaggerated statement about the backward compatibility of Windows.
Thu, 19 Mar 2015
Libvirt Dependencies
Welcome to Yenya's rant about software "features". Today we will have look at libvirt in Fedora and its dependencies. But firstly let me show you a funny picture:
Anyway. I teach a seminar on Linux administration, where one of the tasks is to compile and use one's own kernel. The task for the following week is to create a virtual machine. One of my students had an interesting problem with the second task - virsh refused to start his KVM-based virtual machine with the "command timeout" message.
Digging into the issue, we discovered that it works with the distribution kernel, but not with his custom kernel. Then we found that virsh tries to do a RPC call over D-Bus, which then times out, because the D-Bus object in question was not present. This object is supposed to be provided by a daemon called systemd-machined, which describes itself with the following headline:
This is a tiny daemon that tracks locally running Virtual Machines and Containers in various ways.
This is in fact an understatement, with the real situation being that this
daemon is a core part of the virtualization subsystem, and it is not even
possible to start a libvirt-managed guest without it. We have tried to start
the daemon from the command line, but it immediately exited without a meaningful
message anywhere. The only message in the syslogjournal was
that systemd-machined failed to start when the system was booted.
Long story short, my lucky guess was that systemd-machined could have something to do also with containers, and it might have needed a container support in the kernel. After enabling about five namespaces-related kernel config options and booting a recompiled kernel, we were able to start systemd-machined, and only then we managed to start the VM using virsh.
This spaghetti-structured unstraceable mess of interconnected daemons communicating over D-Bus and providing no meaningful error messages, which is masqueraded under a collective name "systemd", makes me sick quite often.