How-To
Programmatically Obtaining BIOS Information
I recently had to get the warranty information for hundreds of Intel NUC systems used as thin clients to connect to VMware Horizon virtual desktops, and the Intel Warranty Information web site made it very easy to do so.
The web site reports back if the device in question is still under warranty or not.
The form requires a serial number (SN) and a stocking ID (SA or AA), which can be found on a sticker at the bottom of the device.
Going to each device and manually entering the information would be time-consuming and error-prone. This information is also stored in the BIOS, so when a device is powered on, you can press the F2 key and get the same information from the device's SMBIOS page.
I will show how I captured this data on a running system in this article. Although this article is specific to Intel NUC systems running a thin client OS (Stratodesk), the code could be modified to work for other manufacturers and Linux-based systems.
Gathering the SN and SA
Stratodesk is a highly secure thin client OS based on Linux. As such, it does not have many tools that I usually use, such as hwinfo or lshw, to gather information about a device. I needed to use a tool that would even be on a highly secure version of Linux.
The SN and SA are stored in the BIOS, which is surfaced to Linux via the /proc filesystem. Because Grokking the /proc filesystem is complex, I used the Linux command dmidecode, which displays the system BIOS (DMI) in a human-readable format.
The amount of information that dmidecode outputs is tremendous. In fact, running dmidecode and piping it through wc (word count) showed 901 lines of data. Trying to parse through these lines of code would be difficult, but using the -t (type) switch only displays the system information, which contains the SN and SA (version).
I extracted the lines of information I needed using grep and used awk to extract the fields of text I needed. I then assigned them to variables by using the following commands:
MySA=`dmidecode -t system | grep Version | awk '{ print $2}'`
MySN=`dmidecode -t system | grep Serial | awk '{ print $3}'`I
echo "The Serial Number is $MySN"
echo "The SA is $MySA"
I could have also used the -s switch to extract the information.
If I were to use the -s switch, the code would be:
MySA=`dmidecode -s system-version
MySN=`dmidecode -s system-serial-number
echo "The Serial Number is $MySN"
echo "The SA is $MySA"
With this information, I was able to use Intel's web site to then gather warranty the information that I needed.
I couldn't find an API for the warranty information. I also tried to use screen-scraping to get the information programmatically, but since the web site has a drop-down menu for the product type, I could not do so.
Other BIOS Information
Once I got the SN and SA using dmidecode, I wondered what other information it could provide. To get a list of the different types, I entered dmidecode -t.
This showed what switches could be used to obtain other information. For example, when I entered dmidecode -t processor, it displayed information pertaining to the processor, which flags it supports, its max and current speed and so on.
The baseboard switch displayed some interesting information about the manufacturer and the onboard devices (NIC, GPU, wireless devices and so on) on the system.
The other switches contain pertinent pieces of information as well.
Conclusion
Dmidecode allowed me to obtain information from the BIOS. I then submitted this information via Intel's warranty web site for information about the device. It would have been nice to automate the process further, but the lack of an API and the drop-down menu on the web site prevented me from doing so.
Dmidecode is a powerful tool that system administrators should be aware of.
About the Author
Tom Fenton has a wealth of hands-on IT experience gained over the past 30 years in a variety of technologies, with the past 20 years focusing on virtualization and storage. He previously worked as a Technical Marketing Manager for ControlUp. He also previously worked at VMware in Staff and Senior level positions. He has also worked as a Senior Validation Engineer with The Taneja Group, where he headed the Validation Service Lab and was instrumental in starting up its vSphere Virtual Volumes practice. He's on X @vDoppler.