1

Background

dmidecode utility is able to create a raw binary dump using --dump-bin option:

root@here:~$ dmidecode --dump-bin foo.dump

which can be re-used on another machine, producing effect as if dmidecode is running on the original machine:

me@elsewhere:~$ dmidecode --dump-bin foo.dump
# dmidecode 2.12
SMBIOS 2.7 present.
68 structures occupying 2688 bytes.
Table at 0xBAE9D000.
[...]

I do have these binaries from some machines and use them for testing a script that wraps around dmidecode (hence, I need to simulate dmidecode behavior as if the hardware setup was different).

Problem

But from a several machines, I don't have the raw binary, but do have copy of /sys/firmware/dmi/tables as exposed by 4.* kernel. Docs at kernel.org say:

[...] The dmi/tables provides raw SMBIOS entry point and DMI tables through sysfs as an alternative to utilities reading them from /dev/mem. The raw SMBIOS entry point and DMI table are presented as binary attributes and are accessible via:

/sys/firmware/dmi/tables/smbios_entry_point
/sys/firmware/dmi/tables/DMI

The complete DMI information can be obtained using these two tables.

Question

Is it possible to use the /sys/firmware/dmi/tables files to re-construct (in a Bash/Python/Perl/... script) the raw binary dump so that it can be re-used as in first example?

I tried to just cat the files together but I was not successful (Invalid entry length (0). DMI table is broken! Stop.).

  • In my Lamobo R1 I am fortunate enough to also have the tables. However I am considering buying hardware in a near future, and I am aware of this problem. Just to be sure, are you talking about ARM SBCs with closed design where the vendor hacked some kernel by hand? – Rui F Ribeiro Dec 21 '15 at 9:19
  • @RuiFRibeiro I'm "harvesting" the data from a Beaker testing repo. The set is relatively diverse; there are various types of machines (even a laptop). I'd guess they were collected using some recent RHEL or Fedora version. ... did that answer your question? – Alois Mahdal Dec 21 '15 at 14:06
0

If you compare a hex dump of smbios_entry_point with the binary output of dmidecode, you'll see it is similar to bytes 0-31 of dmidecode's output. Likewise, DMI matches bytes 32+. Byte 32 is missing; I assume it's always null.

It looks close enough that I had hopes of it working.

echo -en '\0' >NUL
sudo cat /sys/firmware/dmi/tables/smbios_entry_point NUL /sys/firmware/dmi/tables/DMI >table
dmidecode --from-dump table

However, dmidecode crashes with the following output:

# dmidecode 2.12-dmifs
Reading SMBIOS/DMI data from file table.
SMBIOS 2.8 present.
Bus error (core dumped)

The SMBIOS/DMI spec is available on the internet (pdf); it shouldn't be too hard to determine acceptable dummy values for the header. I'm leaving that as an exercise for the reader, at least for the moment ;)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.