Basic Hardware Info on Linux (Practical Guide): lscpu, lsblk, lspci, lsusb, dmesg

When you’re troubleshooting performance issues, verifying a server build, or just documenting a machine for your inventory, you want fast answers: What CPU is this? Which disks are present and how are they artitioned? What network/storage controllers are in the box? What USB devices are attached? And what did the kernel hink of all of it at boot?

This post walks through five classic Linux commands that every sysadmin uses sooner or later:

lscpu — CPU and virtualization capabilities
lsblk — block devices (disks, partitions, LVM, RAID mappings)
lspci — PCI devices (NICs, HBAs, GPUs, RAID cards)
lsusb — USB devices (UPS cables, dongles, KVMs, webcams)
dmesg — kernel messages about detected hardware (and problems)

All examples are safe read-only checks and work great for “first 10 minutes on a new server” tasks.

1) CPU basics with `lscpu`

lscpu reads CPU topology and features (physical sockets, cores, threads, NUMA nodes, flags), plus virtualization hints.

Quick overview

lscpu

Look for:

Architecture (x86_64, aarch64)
CPU(s) total logical CPUs (threads)
Thread(s) per core (Hyper-Threading / SMT)
Core(s) per socket and Socket(s)
Vendor ID / Model name
Virtualization (VT-x/AMD-V) and hypervisor info

Only the important lines (nice for docs)

lscpu | egrep -i 'Model name|Socket|Core|Thread|CPU\(s\):|NUMA|Virtualization|Hypervisor'

Is this a VM?

lscpu | egrep -i 'Hypervisor|Virtualization'

If you see a “Hypervisor vendor” (like KVM, VMware, Microsoft), you’re likely inside a VM. This matters when you’re chasing “missing” hardware: VMs won’t show host PCI devices unless passed through.

CPU flags: does it support virtualization / AES / AVX?

lscpu | grep -i '^Flags' | fold -w 120

Common flags you might care about:

vmx (Intel VT-x) / svm (AMD-V)
aes (hardware crypto acceleration)
avx, avx2 (useful for some workloads)

2) Disks and partitions with `lsblk`

lsblk is your go-to for understanding storage layout quickly: disks, partitions, LVM volumes, RAID mappings, mount points, and filesystem types.

Readable storage tree

lsblk

The key columns are usually:

NAME (sda, nvme0n1, dm-0, md0)
SIZE
TYPE (disk, part, lvm, raid)
MOUNTPOINTS

Best “sysadmin view”: filesystem type + UUID + mount

lsblk -o NAME,SIZE,TYPE,FSTYPE,FSVER,UUID,MOUNTPOINTS

This is super handy when you need to confirm what’s actually mounted where (and what’s not mounted at all).

Show the underlying model/serial (useful for inventory)

lsblk -d -o NAME,SIZE,MODEL,SERIAL,TRAN,ROTA

Notes:

-d shows only whole disks (not partitions).
TRAN may show sata, nvme, usb.
ROTA is 1 for rotational HDDs, 0 for SSD/NVMe (usually).

Find “what is taking space” quickly (mounted filesystems)

df -hT

lsblk tells you structure; df tells you usage.

Common gotchas

LVM: You’ll see /dev/sda2 feeding into dm-* devices. That’s normal.
RAID: Software RAID often appears as md* devices.
Cloud disks: You may see vda (virtio) instead of sda.

3) PCI devices with `lspci`

lspci lists PCI/PCIe hardware: network cards, storage controllers (SAS/HBA/RAID), GPUs, chipset bridges, etc. If you’re troubleshooting missing NICs or identifying a RAID controller, this is your tool.

Full list

lspci

More detail per device

lspci -nn

-nn includes vendor/device IDs (great for searching compatibility or driver mapping).

Show kernel driver in use (very useful)

lspci -k

Look for lines like “Kernel driver in use:” and “Kernel modules:”. This quickly answers: “Is the right driver loaded?”

Filter to the stuff you usually care about

# Network controllers 
lspci | grep -i ethernet 
# Storage / RAID / SATA / NVMe controllers 
lspci | egrep -i 'sata|raid|sas|scsi|nvme|storage' 
# GPUs (even on servers, iGPU/BMC can show up) 
lspci | egrep -i 'vga|3d|display'

4) USB devices with `lsusb`

lsusb lists USB buses and devices. On servers this often includes UPS interfaces, license dongles, KVM devices, or USB NICs.

Quick list

lsusb

Detailed view (when you need “what exactly is this?”)

lsusb -v

Tip: lsusb -v is noisy. Pipe through less and search inside:

lsusb -v | less

Map USB device to kernel messages

If you just plugged something in and want to see what happened:

dmesg --follow

Plug the device, then watch the output live. Press Ctrl+C to stop.

5) Hardware detection and boot logs with `dmesg`

dmesg prints the kernel ring buffer: hardware detection, driver initialization, link status, filesystem issues, and a ton of clues when something fails (timeouts, resets, bad sectors, firmware problems).

Human-friendly output (recommended)

dmesg -T | less

-T attempts to show human-readable timestamps. Scroll/search in less using /.

Only warnings/errors (great first step)

dmesg -T --level=err,warn | less

Common “what to search for” patterns

# Disk / I/O trouble 
dmesg -T | egrep -i 'error|fail|timeout|reset|I/O|nvme|ata|scsi' | tail -n 50 
# Network link changes / driver messages 
dmesg -T | egrep -i 'eth|enp|link up|link down|firmware' | tail -n 50 
# USB plug/unplug 
dmesg -T | egrep -i 'usb|xhci|ehci' | tail -n 50

Pro move: keep `dmesg` open while testing

dmesg --follow

This is one of the fastest ways to confirm whether the kernel even sees the hardware and what driver it picked.

A practical “first-login hardware checklist” (copy/paste)

If you want a quick baseline report after provisioning a server, run:

# CPU + virtualization hints 
lscpu | egrep -i 'Model name|Socket|Core|Thread|CPU\(s\):|NUMA|Virtualization|Hypervisor' 
# Storage layout 
lsblk -o NAME,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS 
lsblk -d -o NAME,SIZE,MODEL,SERIAL,TRAN,ROTA 
# PCI inventory with driver mapping 
lspci -nnk | less 
# USB devices (if relevant) 
lsusb 
# Kernel warnings/errors that might bite later 
dmesg -T --level=err,warn | tail -n 200

Drop the outputs into your documentation, ticket, or CMDB entry, and you’ve got a solid hardware snapshot without installing anything extra.

Troubleshooting scenarios (real-life examples)

Scenario 1: “Disk is missing”

Start with lsblk to confirm it’s absent.
Use lspci to see if the storage controller exists and which driver is loaded (lspci -k).
Check dmesg for SATA/NVMe errors, resets, or timeouts.

Scenario 2: “Network interface doesn’t come up”

Confirm the NIC exists: lspci | grep -i ethernet
Confirm driver: lspci -k
Check kernel logs for firmware/driver issues: dmesg -T --level=err,warn

Scenario 3: “We’re documenting the server”

CPU: lscpu
Disk models/serials: lsblk -d -o ...
Controllers/NICs: lspci -nn

Security and hygiene notes

These commands are read-only and safe for production.
Be careful when sharing outputs publicly: disk serials, hostnames, PCI IDs, and kernel messages can leak environment details.
For long-term auditing, consider storing hardware snapshots in your inventory system instead of pasting raw logs into public docs.

Wrap-up

Knowing how to pull basic hardware info quickly is one of those “small skills” that saves hours over a year. With lscpu, lsblk, lspci, lsusb, and dmesg, you can confidently answer: what hardware is here, what drivers are active, and what the kernel is complaining about—without installing heavy tooling.

1) CPU basics with lscpu