Monday Jul 06, 2009

I've talked about the SourceJuicer before. If you often grab source tarballs and compile them on Solaris, check it out. And better yet - contribute. It's really not very involved. Today I put the dmidecode utility into the juicer.

Part of the x86gentopo project is adding OEM-specific SMBIOS structures. In searching around to find out if the structure types we were proposing would conflict with already existing OEM extensions, I stumbled upon dmidecode. Quite a nice utility. The /usr/sbin/smbios CLI is the Solaris equivalent. A minor annoyance with dmidecode is that it must be run as root since it directly reads the /dev/xsvc device, whereas smbios uses the /dev/smbios device. But execution aside, both report the same basic information:

Some slight field label differences, but the set of information one would expect. And, the listing of contained object handles from dmidecode is something missing from /usr/sbin/smbios. That's an enhancement the x86gentopo project is working on.

Although, dmidecode has some nice additions that make scripting simpler. For example, to fetch the system serial number (residing in the Type 1 SMBIOS strucure):

While one gets the same result, it's obvious which approach is simpler and more maintainable in a script. And that's the primary reason it prompted me to port the utility. I'd suspect that many administrators have built scripts around dmidecode for basic system inventories. If moving to Solaris, having dmidecode around means one less script to port.

It's available in the /pending repository. /pending is an unstable repository, although dmidecode is about as benign as things get, so there's little risk in using it. It's behaved fine on my two systems running OpenSolaris b117 (one Sun system, one Toshiba laptop). If you do download it and use it, I'd really appreciate it if you let me know how it's working. I want to get the package moved to the more stable /contrib repository, and any reports of dmidecode working "in the wild" would certainly help.