Dmidecode System Serial Number

[Kemal Allan]

dmidecodeis a software tool that enables extraction of detailed hardware information from a system by decoding the DMI (Desktop Management Interface) table. It provides valuable insights into the system's hardware configuration as described in SMBIOS (System Management BIOS). With dmidecode, you can retrieve information such as the system's BIOS vendor, version, release date, and revision, as well as details about the system's manufacturer, product name, serial number, UUID, SKU number, family, baseboard information, chassis details, processor family, manufacturer, version, and frequency.

If dmidecode is not available or inaccessible, there are alternative methods to retrieve BIOS information. In addition to the previously mentioned tips, you can also utilize systemd commands to access relevant data. Some of the systemd commands for retrieving BIOS info include:

If you are unable to launch dmidecode as usual or do not have root privileges, there are alternative methods to read DMI (Desktop Management Interface) information. Please note that some information, such as serial numbers, may require root privileges to access.

One option is to access the DMI information under the directory /sys/class/dmi/id/ as a regular user. This directory contains various files that provide DMI-related information. However, please be aware that the following options require root access:

The interesting part of this is that you DO get the serial number, however you also get a bunch of text that basically screws up any string scripts that you might be using. Another way to get this information as the serial number only is the following:

dmidecode released with CentOS (or RHEL) 6.4 and earlier is version 2.11 which does not support the 2.8 version of SMBIOS. So you'll not *quite* get the answer you want when using the "dmidecode -s system-serial-number" version of this string. You need dmidecode version 2.12 or later to get the latest ROM BIOS reads from HP Gen8 Gear.

Personally I'm trying to see if there is a newer version of dmidecode out there for either centos 6.4 or 6.5 or on the updates that handles the newer SMBIOS 2.8.0 standard (its been published since April 2013, but only recently implemented by HP).

If dmidecode is replying with junk, then your system serial number is junk. I believe you need to go into the BIOS/UEFI and change it. Look on the case of your machine and get its true serial number, then reboot, go into your BIOS, and modify it.

However, in some Linux/Unix system, it may require root permission in order to run dmidecode command, like the present Linux system which is being used to run the following command require root privilege.

dmidecode is a tool for dumping a computer's DMI (some say SMBIOS) table contents in a human-readable format. This table contains a description of the system's hardware components, as well as other useful pieces of information such as serial numbers and BIOS revision. Thanks to this table, you can retrieve this information without having to probe for the actual hardware. While this is a good point in terms of report speed and safeness, this also makes the presented information possibly unreliable.

As you run it, dmidecode will try to locate the DMI table. It will first try to read the DMI table from sysfs, and next try reading directly from memory if sysfs access failed. If dmidecode succeeds in locating a valid DMI table, it will then parse this table and display a list of records like this one:

Note: on Linux, most of these strings can alternatively be read directly from sysfs, typically from files under /sys/devices/virtual/dmi/id. Most of these files are even readable by regular users.

Do not decode the entries, dump their contents as hexadecimal instead. Note that this is still a text output, no binary data will be thrown upon you. The strings attached to each entry are displayed as both hexadecimal and ASCII. This option is mainly useful for debugging.

Please note in case of dmidecode is run on a system with BIOS that boasts new SMBIOS specification, which is not supported by the tool yet, it will print out relevant message in addition to requested data on the very top of the output. Thus informs the output data is not reliable.

Additionally, type 126 is used for disabled entries and type 127 is an end-of-table marker. Types 128 to 255 are for OEM-specific data. dmidecode will display these entries by default, but it can only decode them when the vendors have contributed documentation or code for them.

There is some ambiguity about how to interpret the UUID fields prior to SMBIOS specification version 2.6. There was no mention of byte swapping, and RFC 4122 says that no byte swapping should be applied by default. However, SMBIOS specification version 2.6 (and later) explicitly states that the first 3 fields of the UUID should be read as little-endian numbers (byte-swapped). Furthermore, it implies that the same was already true for older versions of the specification, even though it was not mentioned. In practice, many hardware vendors were not byte-swapping the UUID. So, in order to preserve compatibility, it was decided to interpret the UUID fields according to RFC 4122 (no byte swapping) when the SMBIOS version is older than 2.6, and to interpret the first 3 fields as little-endian (byte-swapped) when the SMBIOS version is 2.6 or later. The Linux kernel follows the same logic.

2 - if the board documentation serve the information how to read the serial number directly:You may be able to read e.g. the content of an onboard eeprom which holds the serial number.this may be possible throught the /sys filesystem , too.to see, whats possible - an Example from a HP Laptop:

This looks like what you are querying is from the BIOS. The BIOS would contain a table of information about your hardware, serial numbers, etc.. this can be queried according to the SMBIOS standard. dmidecode reads this information from the table using this standard.

So alternatively, you may want to look into the standard and write code for reading the required information or serial numbers etc. or ask your hardware/firmware vendor if they have any libraries or hooks available for this purpose.

The DMI table decoder is a command-line tool for Linux systems. It is commonly used to translate a machine's DMI table (System Management BIOS, or SMBIOS) into a human-readable format. This tool allows you to see additional information about a system's hardware configuration, and even gives information not directly related to the current build. Information like the maximum supported amount of memory or the fastest-supported CPU type can be found by using a few key flags.

From a practical standpoint, you might run into situations where you need a serial number or a key piece of hardware information during troubleshooting. In my time as a storage engineer, I ran into multiple instances where a customer would purchase a virtual edition server and then try to run massive amounts of data backups or replication to this machine. Depending on the size of the jobs, they would sometimes overload the memory included and exceed the swap space. In turn, this issue would cause Out-of-Memory (OOM) Killer to have a field day with the system. So, rather than looking up hardware specs in a manual, I could use dmidecode to grab this information.

First off, all of the following information can be found in the man-pages for the tool by running man dmidecode. Feel free to follow along there. At the most basic level, each record has one of the following (as listed in the man page):

Size - Each record has a 4-byte header (2 for the handle, 1 for the type, 1 for the size), the rest is used by the record data. This vaule does not take the text strings into account (these are placed at the end of the record), so the actual length of a record may be (and is often) greater than the displayed value

There are many options that can be used to create a more precise output. I will not cover all of these here, but they are laid out plainly using the man page. What I will talk about are the DMI type codes that are included with the command to make specific information rapidly accessible. Going back to my previous example, you will remember that we routinely had issues with OOM errors. To gather information about a system's memory configuration, you can use the following command:

where x is equal to the numeric type code you wish to gather. For this example, the codes 5, 6, 16, and 17 would all be helpful to gather. See the man page's full chart below for all the available type codes:

Keywords can be used with the --type flag to pull all associated type codes into the command. From the example below, you can see that all of the information associated with using numerical type codes 16 and 17 is supplied:

I hope that this quick rundown of the DMI Decoder tool has been helpful. Let us know when you have used this command or had need of it. Hopefully, you now have a better strategy or reference point for the next hardware issue you run into.

Tyler is the Sr. Community Manager at Enable Sysadmin, a submarine veteran, and an all-round tech enthusiast! He was first introduced to Red Hat in 2012 by way of a Red Hat Enterprise Linux-based combat system inside the USS Georgia Missile Control Center. More about me

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. The content published on this site are community contributions and are for informational purpose only AND ARE NOT, AND ARE NOT INTENDED TO BE, RED HAT DOCUMENTATION, SUPPORT, OR ADVICE.

Processor serial numbers were basically only in Pentium III processors. Intel removed it from later models due to the privacy concerns that were raised. As such, unless you're on a PIII AND your BIOS settings let you read the serial number, all you'll get are 0's.

It's because of recent comment. Happened long time ago, so can't explain now why these ID were taken as machine identifier. Got actual Processor ID fromn Processor Information section. Extracted on Debian OS.

3a8082e126