Linux Hardware and Firmware Inventory Basics

Hello! In the previous lesson, you used POST indicators, firmware messages, and logs to narrow a startup fault. Those observations become more useful when you have a record of what the machine looked like before something changed.

This lesson shows how to collect that baseline from Linux: the processor and memory, connected devices and storage, platform identity, and reported firmware versions. You will also learn what each utility can—and cannot—establish. Allow about 40 minutes if you have a Linux system available; you can follow the interpretation without running the commands.

Start with what Linux can see

An inventory is not a single definitive list. Linux can report devices it has enumerated; firmware can provide descriptions of the platform; and a firmware-update service may recognize still other components. Keeping those sources distinct helps when a device later seems to disappear.

Watch selected demonstrations from Akamai Developers’ Linux Hardware Commands. The presenter uses a mixture of virtual and physical systems. Focus on which question each command answers, rather than expecting your output to look the same.

On your system, begin with these read-only commands:

lscpu
free -h
lspci -nnk
lsusb
lsblk -o NAME,TYPE,SIZE,MODEL,TRAN,FSTYPE,MOUNTPOINT

lscpu gives the CPU architecture, model, and the processor resources visible to Linux. Its logical-CPU count need not equal its physical-core count. free -h reports memory available to the running OS, not the number or specifications of installed memory modules.

lspci -nnk lists enumerated PCI devices, including many internal controllers. The numeric IDs (-nn) remain useful when a displayed product name is vague; -k can show the kernel driver associated with a device. lsusb lists USB devices, which may include built-in laptop components as well as external peripherals. Neither list proves that every listed device works correctly: enumerated is a narrower claim than healthy.

In lsblk, look first at TYPE: a disk entry represents a block device, while part entries beneath it are partitions. SIZE and MODEL help establish which disk you are looking at; TRAN may indicate its transport, but can be blank. FSTYPE and MOUNTPOINT describe what Linux currently recognizes and has mounted. Loop, device-mapper, or other virtual entries can also appear, so do not count every row as a physical drive. Device names such as sda can change; retain the model and size when comparing inventories.

If installed, sudo lshw -short is a useful cross-check that condenses several hardware categories into one view. It does not replace the focused commands when you need to establish precisely which device or disk Linux reported.

Add the platform’s own description

The OS view does not by itself tell you the platform model or installed firmware revision. For those, dmidecode reads SMBIOS/DMI tables supplied by the platform firmware. Read the DESCRIPTION and the --string and --type entries under OPTIONS in the Debian dmidecode(8) manual.

These targeted queries form a practical platform baseline:

sudo dmidecode -s system-product-name
sudo dmidecode -s baseboard-product-name
sudo dmidecode -s bios-vendor
sudo dmidecode -s bios-version
sudo dmidecode -s bios-release-date
sudo dmidecode -t 17

Here, “bios” is the tool’s historical name for platform firmware; it does not mean the machine necessarily boots using legacy BIOS. Type 17 records describe memory devices, often including their capacity and slot designation. Compare those records with free -h: one describes what firmware reports about modules, while the other describes memory visible to the running OS. A small difference in totals alone is not proof of a missing module.

SMBIOS entries can be incomplete, generic, or wrong. A reported release date is not evidence that an update is available, and a slot recorded as empty does not establish that its circuitry is sound. Treat these values as reported platform identity. If they conflict with another observation, preserve both rather than silently choosing one.

You can also record whether this Linux session reached the OS through a UEFI interface:

if [ -d /sys/firmware/efi ]; then
    printf 'UEFI interface present for this boot\n'
else
    printf 'UEFI interface not present for this boot\n'
fi

An absent directory does not, by itself, prove that the hardware lacks UEFI support. For example, the same capable machine might have started the current environment differently. The distinction between boot methods comes later in the course.

Check which firmware devices are discoverable

fwupdmgr offers a different view: devices that the Linux firmware-update service discovers, sometimes with firmware-version information. Read its OPTIONS → Interacting With Discovered Devices description of get-devices. Also locate get-bios-settings in the settings portion of OPTIONS, but do not use any setting-changing command for this inventory.

If fwupdmgr is installed, run:

fwupdmgr get-devices

Record the device names and versions it actually reports. It may not discover every firmware-bearing component, and it may not be installed or usable in every Linux environment. Missing from this list does not mean missing from the laptop. Likewise, a dmidecode platform-firmware version and a fwupdmgr version for another component may both be correct: check which component each version labels before comparing them.

Save a baseline you can compare later

A useful baseline has a collection time, the running Linux context, and the outputs kept in a private location. The following creates a new directory in your home directory; it makes no firmware or disk-configuration changes. Run the first block, and proceed only if it prints a valid directory path:

umask 077
dir=$(mktemp -d "$HOME/hw-baseline.XXXXXXXX")
printf 'Inventory directory: %s\n' "$dir"

Then save the core observations:

date -u > "$dir/collected-utc.txt"
uname -r > "$dir/kernel.txt"
lscpu > "$dir/cpu.txt"
free -h > "$dir/memory-os.txt"
lspci -nnk > "$dir/pci.txt"
lsusb > "$dir/usb.txt"
lsblk -o NAME,TYPE,SIZE,MODEL,TRAN,FSTYPE,MOUNTPOINT > "$dir/storage.txt"

sudo dmidecode -s system-product-name > "$dir/platform-model.txt"
sudo dmidecode -s bios-vendor > "$dir/firmware-vendor.txt"
sudo dmidecode -s bios-version > "$dir/firmware-version.txt"
sudo dmidecode -s bios-release-date > "$dir/firmware-date.txt"
sudo dmidecode -t 17 > "$dir/memory-slots.txt"

The sudo commands read firmware-supplied tables; the > operator writes their displayed output to files in the new directory. If a command fails or a utility is unavailable, note that limitation rather than treating an empty file as a negative hardware finding. You can save the boot-interface result and fwupdmgr get-devices output separately if available.

Keep the raw directory private. Hardware reports can contain serial numbers, identifiers, and details about attached devices or mounted filesystems. Before sharing a service report, extract only the relevant fields and remove identifiers that are not needed for diagnosis.

Finally, compare like with like. Suppose an earlier baseline shows an internal disk in lsblk, but a later Linux session does not. That is evidence of a change in OS-visible storage, not yet proof that the disk failed. Check whether both sessions ran on the same platform and boot environment, and compare the firmware’s detection of the drive. This is the value of a baseline: it turns “I think it used to be there” into a dated observation while leaving room for competing explanations.

Key takeaways

Build the inventory from complementary views: Linux enumeration for CPU resources, devices, and disks; SMBIOS for reported platform, firmware, and memory-module details; and fwupdmgr, when available, for discoverable firmware devices. Record what each source actually reports, its collection time, and any missing or conflicting evidence. An inventory is a reference point, not a hardware-health certificate.

Next, you will use this evidence-first approach to plan low-level diagnostic work that protects user data and preserves rollback options.