Custom boot volume

This is the boot image that we will run on test boxes in the context of Inventory tracking database.

=Current participants=

=Tools=


 * https://github.com/organizations/freegeek-seattle
 * http://en.wikipedia.org/wiki/SUSE_Studio SuSE Studio
 * https://launchpad.net/ubuntu-builder/

=Requirements=
 * 1) small enough boot image to work on older hardware
 * 2) kernel with full module set to detect as much hardware as possible
 * 3) one image, updatable, that can be used to generate PXE images or ISO
 * X, basic desktop environment, hardware testing suite

=Components=

init scripts
I'm envisioning a script that fires once X is up and running, prompts the user for a few things and then runs lshw and / or live hardware testing (could just run dmesg, but lshw gives us nice structured output.) Output from all these is then sent to curl for upload. If X fails then the script should still run at whatever level userland falls back to. It might be useful to make a separate frontend for X so that the tester can see if things are working ok.

Prompts

 * 1) Donor information
 * 2) Name
 * 3) not sure what else
 * 4) Unique-ish human readable name
 * 5) This serves to identify individual boxen in a way that doesn't require people to memorize UUIDs. I envision a series of names cycling through the alphabet at the first letter and last letter as follows:
 * 6) Anna
 * 7) Ahab
 * 8) Alec
 * 9) Arid
 * 10) ... up to Azaz, and then
 * 11) Bubba
 * 12) Barb
 * 13) Boinc
 * 14) Brad
 * 15) ... and so on down the line. They don't have to be 4 letters, I just made those up.
 * 16) This may be more trouble than it's worth. If we use it, it should be automated. The scheme as shown only generates 436 unique names; it might be better just to assign names from a long list of place-names or something- MySQL wordlist tables are easy to find and download. I regard this as an optional feature, so won't try to implement it until I get core functions working. Maybe we could use something like shelf locations instead?
 * 17) Tester information
 * 18) Name or ID
 * 19) Presumably the testing volunteer should know his or her ID. Is this a realistic expectation?

I think this should be enough information for the tester to enter. My idea is to automate as much as possible. Probably the interactive part should come last among the information-gathering steps. That way the tester can enter a description of any problems observed which the other tests didn't catch.

What the script will launch

 * 1) lshw or hwinfo to gather structured hardware data
 * 2) Checkbox or other hardware tester
 * 3) interactive prompts for non-automated data gathering (as described above_
 * 4) curl or other non-interactive uploader to push data to server