Read IBM and Lenovo VPD Safely with vpddecode

vpddecode pulls vital product data straight off a supported IBM or Lenovo board, which beats hunting for a sticker on a rack you cannot reach.

This guide inspects VPD on a supported machine, selects one field for a script, and preserves a raw dump for diagnosis when decoding is uncertain. The examples match dmidecode 3.5, installed here as package version 3.5-3ubuntu0.1. Allow about ten minutes.

These commands only read hardware data. They do not change firmware, files, services or boot settings.

1. Confirm the installed version

Start by recording the program version. This keeps later troubleshooting tied to the tool that actually produced the output:

$ vpddecode --version
3.5

On a Debian-family system, the package revision can be useful as well:

$ dpkg-query -W -f='${Package} ${Version}\n' dmidecode
dmidecode 3.5-3ubuntu0.1

If vpddecode is missing, install dmidecode through your normal package-management process. Do not copy a binary from another machine: this utility reads a platform-specific memory interface.

2. Try the normal decoded report

Run the command without options first:

$ vpddecode
# vpddecode 3.5
BIOS Build ID: XXXXXXXX
Box Serial Number: XXXXXXXX
Motherboard Serial Number: XXXXXXXX
Machine Type/Model: XXXXXXXX

The field values above are representative placeholders, not output to expect literally. Depending on the machine, the report can also contain a BIOS release date or a default flash image file name. The manpage warns these additional labels are inferred rather than documented by IBM, so treat them as clues and confirm important inventory data elsewhere.

If your command says Can't read memory from /dev/mem, the read did not complete. That is a permission or platform-access problem, not proof the machine has no VPD.

3. Retry only when access requires it

Elevated access is a boundary, not a default. If the unprivileged command failed because it could not read /dev/mem, retry with your system's approved privilege mechanism:

$ sudo vpddecode
# vpddecode 3.5
BIOS Build ID: XXXXXXXX
Box Serial Number: XXXXXXXX
Motherboard Serial Number: XXXXXXXX
Machine Type/Model: XXXXXXXX

Checkpoint: capture the result immediately if another command will follow:

$ sudo vpddecode
$ status=$?
$ printf 'vpddecode exit status: %s\n' "$status"

A successful exit status means the read and decode completed. It does not certify guessed labels are correct or that every possible field is defined.

4. Request one known field

For inventory or a pre-flight check, select one keyword with --string. The installed 3.5 manpage documents five values:

$ sudo vpddecode --string machine-type-model
ThinkPad T14 Gen 4

The exact value depends on the machine. A keyword may be valid but undefined on a particular VPD-enabled system, so handle an empty or absent value rather than substituting a guess. The option can be used once only.

Do not pass a field name copied from the report unless it is one of the documented keywords. An invalid keyword prints the accepted list and exits with status 2 on this version:

$ vpddecode --string not-a-keyword
Invalid string keyword: not-a-keyword
Valid string keywords are:
  bios-build-id
  box-serial-number
  motherboard-serial-number
  machine-type-model
  bios-release-date
$ printf '%s\n' "$?"
2

5. Dump the record when decoding is unclear

Use --dump when you need evidence for a bug report or want to compare the raw record with a decoded result:

$ sudo vpddecode --dump
# vpddecode 3.5
0000: 49 42 4d 20 56 50 44 20  ...
0010: 53 4e 20 20 20 20 20 20  ...

The precise bytes vary by system. This is still text output: the command prints hexadecimal bytes and an ASCII equivalent where possible. It does not write a binary file. The dump is mutually exclusive with --string, so choose either a decoded field or raw diagnostic output.

Warning: store sensitive output deliberately. If you need to attach it to a support ticket, remove serial numbers first or use the provider's approved secure channel. A raw dump can expose the same identifiers as the decoded report.

6. Keep scripts strict and boring

Use a documented keyword, check the exit status, and do not parse the full report when one value is enough:

set -eu

machine_type=$(sudo vpddecode --string machine-type-model) || {
    printf '%s\n' 'Could not read machine type/model VPD' >&2
    exit 1
}

printf 'Machine type/model: %s\n' "$machine_type"

This example assumes the script is allowed to invoke sudo non-interactively. If it is not, arrange the approved access policy before deploying the script. Do not put a password in the script or grant broad access to /dev/mem. If the field is missing, make the script report that state rather than treating an empty value as a valid serial number.

Done means