So I’m still trying to come up with a decent way to parse those logs. Actually I lost a whole batch of them because I forgot to rename them before processing, but that made me realize that the best thing I can do is process the logs outside of the tinderbox itself. But this is a topic for another time.
Another thing I’m trying to set up is a virtual machine to test the new x32 ABI that Mike has made available in Gentoo. This is important for the tinderbox as well as for FATE (which is already being run for a standard Gentoo Hardened setup on that very same hardware). Unfortunately I can’t use this via LXC, yet — simply because the kernel currently running does not support the x32 executables yet.
This means that I have to use KVM and go full-virtualisation. Thanks to Tim, I’ve got a modified SysRescueCD ISO that should let me take care of the install. Unfortunately, this is not easy to deal with for a number of reasons, still.
The first is that virt-manager is just slow, and painful, as some kind of slow and painful death. The whole idea of using a frontend that connects through SSH is that you don’t want to “feel” the lag… but virt-manager makes you feel the lag even more than a command-line SSH connection. I’m under the impression that the guys who work on that kind of stuff only ever tried this on a local connection, and never from the other side of the world. I mean, I understand you might have concurrency issues, but do you really have to make me wait for two minutes to switch from CPU settings to Memory settings to Disk setting when editing the VM?
The second issue is that even though I was able to set up a testing VM for x32… qemu doesn’t like the additional instruction sets (SIMD) that Bulldozer comes with; something within the C library causes every x32 binary to be killed with SIGILL (Illegal Instruction). The problem is likely in some of the indirect-binding functions that are being used — my guess based on the NEWS file of the 2.15 release is strcasecmp() which has been optimised through the use of SSE4.2 and AVX (both of which are available on that server) — I have a 3⁄4 written, half drawn post about this kind of optimisations in my queue, I’ll see if I can post it over the weekend.
The end result is that I spent the most part of three hours on virt-manager before accepting that the way to go is to update the host’s kernel and just run the usual container. Just so you know, the final step that “creates” the VM (which is not the LVM allocation step!) took me over half an hour. This is silly, what the heck was it doing during that time?
Oh and yes, two years afterwards virt-manager still keeps defunct ssh processes around because it never reaps them (check the comments).
Right now I’m trying to get this to work with LXC, but I’m not having much luck with it either; and yes I did update the init script to handle correctly the x32 containers, that didn’t work correctly before… it might have some problems if you’re going to use this on SPARC, because I’m not handling those properly yet, but this is (again) a topic for another time.