Reconstructing dmidecode binary dump from /sys/firmware/dmi/tables
Clash Royale CLAN TAG#URR8PPP
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.).
sysfs dmidecode
asked Dec 16 '15 at 14:59
Alois MahdalAlois Mahdal
1,88252948
add a comment |
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.).
sysfs dmidecode
asked Dec 16 '15 at 14:59
Alois MahdalAlois Mahdal
1,88252948
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
add a comment |
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.).
sysfs dmidecode
asked Dec 16 '15 at 14:59
Alois MahdalAlois Mahdal
1,88252948
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.).
sysfs dmidecode
sysfs dmidecode
asked Dec 16 '15 at 14:59
Alois MahdalAlois Mahdal
1,88252948
asked Dec 16 '15 at 14:59
Alois MahdalAlois Mahdal
1,88252948
asked Dec 16 '15 at 14:59
Alois MahdalAlois Mahdal
1,88252948
asked Dec 16 '15 at 14:59
Alois MahdalAlois Mahdal
1,88252948
asked Dec 16 '15 at 14:59
Alois MahdalAlois Mahdal
1,88252948
1,88252948
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
add a comment |
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
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
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
@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
add a comment |
1 Answer
1
active
oldest
votes
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 '' >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 ;)
answered Sep 27 '16 at 17:10
MarkMark
1313
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f249734%2freconstructing-dmidecode-binary-dump-from-sys-firmware-dmi-tables%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 '' >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 ;)
answered Sep 27 '16 at 17:10
MarkMark
1313
add a comment |
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 '' >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 ;)
answered Sep 27 '16 at 17:10
MarkMark
1313
add a comment |
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 '' >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 ;)
answered Sep 27 '16 at 17:10
MarkMark
1313
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 '' >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 ;)
answered Sep 27 '16 at 17:10
MarkMark
1313
answered Sep 27 '16 at 17:10
MarkMark
1313
answered Sep 27 '16 at 17:10
MarkMark
1313
answered Sep 27 '16 at 17:10
MarkMark
1313
1313
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f249734%2freconstructing-dmidecode-binary-dump-from-sys-firmware-dmi-tables%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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