Travis Paul

Thoughts no one asked for and more.

Trying to Shake UUIDs out of a Lunch Box

Lunch Box Chassis

I recently decided to repurpose some existing hardware and spin up a local instance of Triton Data Center. I had two Intel Atom-based SuperMicro motherboards at my disposal (A1SRI-2758F and A1SAI-2750F.) They both booted and ran SmartOS well and so they seemed like good candidates for testing. What these boards lack in CPU power, they make up by being small and quiet, plus they support ECC memory! These boards had served me well for both NetBSD and FreeBSD and can often be found well priced on eBay.

I got the Triton head node setup and then booted the other as a compute node. After booting the compute node I noticed there was only one server listed in Admin UI. It seemed that CNAPI had confused the two servers as one because both servers were returning "00000000-0000-0000-0000-000000000000" as their UUID when queried via sysinfo(8) (which invokes smbios(8).) Oddly enough, ipmitool returned unique UUIDs for both servers, but smibios and even dmidecode on Linux would not. This was a complete blocker for running Triton so I first tried my hand at modifying sysinfo such that it would fall back to ipmitool in the event smbios returned a UUID of all zeros.

diff --git a/src/sysinfo b/src/sysinfo
index 13a60163..22680511 100755
--- a/src/sysinfo
+++ b/src/sysinfo
@@ -122,16 +122,17 @@ function get_smbios_system_info()

+    # If smbios returns an empty UUID, try IPMI this works for some SuperMicro
+    # boards.
+    if [ "$UUID" = "00000000-0000-0000-0000-000000000000" ]; then
+        UUID=$(ipmitool mc guid | grep 'System GUID' | sed -e 's/.*:\ //')
+    fi
     # overwrite UUID if config dictates otherwise
     tmp_uuid=$(/usr/bin/bootparams | grep "^override_uuid=" | cut -f2 -d'=')
     if [[ -n $tmp_uuid ]]; then

I made the change and built a new image for SmartOS but at the time wasn't sure how to build a new Triton platform image from my modified SmartOS image. That also seemed a bit too heavy-handed and I wanted to actually "fix my bios."

While searching for a way to set the UUID correctly in the BIOS, I first tried Supermicro Update Manager (SUM). This tool is provided by SuperMicro and according to the web page, would allow me to "Get/Change/Edit DMI Information." That sure sounded like what I needed so I downloaded it. The utility has support for Windows, Linux, FreeBSD, and UEFI so I booted a live Ubuntu USB and when running the utility I was greeted by an error complaining about not having a kernel module loaded:

"BIOS does not support virtual driver and Driver sum_bios.ko does not exist."

From the live CD I built and loaded the kernel module only to then be greeted by a new error message:

"One of the node product key (SFT-OOB-LIC or SFT-DCMS-SINGLE) should be activated to execute this task."

Deciding to ignore how ridiculous it is that I need some license key to use my own hardware, I wondered "How does one acquire one of these licenses?" Well, according to the manual you have to email SuperMicro which was not agreeable to my timeline. I wanted this working today. So after a bit of searching, a fine gentleman by the name of Peter Kleissner helped me out. If you're in a similar pickle you might Google his name and his blog may help you out too.

Now equipped with licensed BIOS and a kernel module I should be able to set my system UUID right? Nope. The utility now failed with:

"Get wrong completion code CC (Invalid data field in Request) Instruction: To reboot the managed OS/system and try execution again"

I tried the reboot suggestion and the error still occurred, I even tried updating my BIOS to the latest versions to no avail. Looking closer at the SUM webpage I noticed the following in the description:

"...used for managing and configuring the BIOS/BMC firmware for Supermicro X9 generation motherboards and above."

I don't know anything about SuperMicro's motherboard generations, so maybe these boards are a different generation? The board's manual and info web page don't mention what generation they are but there is an "x10" in the link to the motherboard manual:


Either way, I decided not to give up just yet and tried the UEFI version of SUM. This was also unsuccessful and errored out with:

"[ERROR] Invalid vector subscript"

In all of my attempts, all I was trying to do was get the DMI information so that I could then, hopefully, edit it:

sum -c GetDmiInfo --file dmi.txt

I hadn't tried to even update anything yet. At least not in any way I expected to succeed.

A colleague also sent me over a SUM command known to successfully set UUIDs on SuperMicro boards remotely so I didn't even need the kernel module or UEFI. It is entirely possibly I was just holding it wrong and I was hopeful it would be what I needed.

sum -i $ipmi_ip -u ADMIN -p $ipmi_password -c EditDmiInfo \
  --file mydmifile.txt --shn SYUU --value SOME-UUID-HERE

Sadly, that too failed with the same error as when running it locally as well.

At this point, I had one other tool to try: IPMICFG which was also available from SuperMicro. While looking through the settings trying to find something that resembled a UUID, I saw the FRU: Chassis Type. Which could be set to one of the following values:

01h = Other
02h = Unknown
03h = Desktop
04h = Low Profile Desktop
05h = Pizza Box
06h = Mini Tower
07h = Tower
08h = Portable
09h = LapTop
0Ah = Notebook
0Bh = Hand Held
0Ch = Docking Station
0Dh = All in One
0Eh = Sub Notebook
0Fh = Space-saving
10h = Lunch Box
11h = Main Server Chassis
12h = Expansion Chassis
13h = SubChassis
14h = Bus Expansion Chassis
15h = Peripheral Chassis
16h = RAID Chassis
17h = Rack Mount Chassis
18h = Sealed-case PC
19h = Multi-system Chassis
1Ah = CompactPCI
1Bh = AdvancedTCA
1Ch = Blade
1Dh = Blade Enclosure
1Eh = Tablet
27h = Blade

I was wondering this entire time if I could update anything so naturally I tried to set my chassis to "Pizza Box" and it worked. It even showed in the IMPI web console.

Pizza Box

Neat. Neat.

Setting it to "Lunch Box" worked too and since I've got two servers to update, it only seemed appropriate to make one a Lunch Box and the other a Pizza Box.

I first thought these chassis types were easter eggs or jokes like the HTTP status code: 418: I'm a teapot but couldn't help but wonder "Maybe there is in fact, a Pizza Box form factor chassis?" I was not alone as someone had already asked on Server Fault. That Server Fault question also proves that we live in a small world. It's entirely coincidental that the same colleague that pointed me to the SUM commands, also commeted on that post in 2013! Another interesting coincidence is that the Sun SparcStation form factor was considered a "Pizza Box" and I noticed this oddity the same time as while working with an Illumos based system (who's hertiage goes back to the OS running on those Sparc Boxes.)

Were any actually made of cardboard and limited to 550 copies, much like Horse: The Band's Pizza EP?

Anyway, back to my UUID issue. At some point, far too late in this quest I thought to search SuperMicro's site and found someone asking a question about UUID errors in VMWare. While the question wasn't asking about my problem, the answer had a very helpful clue:

"You can modify the UUID as thy want by AMIDEDOS or 3rd party SMBIOS edit tool."

AMIDEDOS? Never heard of it but these boards do have an AMI BIOS, and having already created a FreeDOS USB in order to update the BIOS (hoping that might alleviate my issues, which it didn't) I was ready to give it a try. After frustratingly trying to find the tool on AMI's website I found a copy on Silicon Mechanics website. It presented me with a list of options, one of them was to generate a UUID. I ran it and bam! I have my UUIDs!

C:\>AMIDEDOS.EXE /SU AUTO Initializing the SMBIOS interface. Please wait a moment......

I guess if I can say I learned anything out of this experience it is:

  1. DOS surprisingly still has a purpose.
  2. Computers used to come in pizza and lunch box shapes.

Update 2022-09-29: I have found the AMIDEDOS.EXE utility capable of changing a UUID for "GigaByte Dual BIOS" as well.