I was reading fairly recently about somebody (No attribution because I really can't remember who it was or where I read it. Sorry) who has a setup where he can do automatic bisect runs on the linux kernel by building the kernel, copying the built files across to a second machine and causing the second machine to reboot. The build was then considered bad if the second machine hadn't come up within 10 minutes, and the entire process was automatic except for needing to reboot the machine by hand if it didn't come up.
This got me to thinking about ways that this can be improved. I haven't tested this yet, but in theory this would work just as well but be more streamlined.
The first thought was to use a virtual machine - something like VMWare or VirtualBox - instead of a physical machine then the script can also be responsible for killing the machine if it doesn't come up.
It then occured to me that this can be taken a step further by having a virtual machine booting off of a live CD - one that was specially crafted using the newly built kernel. This way, there's no requirement to have the machine be able to boot in order to install the new kernel. The entire process would be something like:
** Build kernel
** Master a new Live CD image featuring the kernel
** Fire up the virtual machine using the newly mastered Live CD
** Test if it worked
** Kill the virtual machine
** Repeat
Testing if it worked is a slightly tricky one - I think the article I read used a serial console to do this, but I'm not sure if that's possible on a virtual machine. What is possible though is if the script was to run up a network server on a well known IP/Port - the script already knows these details and so can build it into the Live CD - and the Live CD run a program that connects to this network server during startup. It could even go so far as to make the only process that is loaded in startup - after all of the required networking stuff is loaded, obviously - be the client that connects to this server. The script can then determine success/failure by if the server gets a connection from the virtual machine within a known period of time - 10 minutes works, but can probably be cut down quite a lot since the virtual machine is doing very little now. I'd like to think with the amount that is being done, a boot up time of 2 minutes is slow...
As I said - I've not even considered how to go about making this a reality, but it's an interesting thought that could streamline bisecting of kernels to see which ones boot with zero user intervention.
