Custom boot volume

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

Tools

https://github.com/organizations/freegeek-seattle http://en.wikipedia.org/wiki/SUSE_Studio SuSE Studio

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
4. 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
   1. Name
   2. not sure what else
2. Unique-ish human readable name
   1. 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:
      1. Anna
      2. Ahab
      3. Alec
      4. Arid
      5. ... up to Azaz, and then
      6. Bubba
      7. Barb
      8. Boinc
      9. Brad
      10. ... and so on down the line. They don't have to be 4 letters, I just made those up.
   2. 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?
3. Tester information
   1. Name or ID
      1. 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