hw-probe: turning a machine's hardware state into a shareable diagnosis

A probe is a hardware snapshot plus a permanent URL

hw-probe is described as a tool to probe for hardware, check operability and find drivers with the help of the Linux hardware database at linux-hardware.org, with a separate site for BSD users at bsd-hardware.info.

A probe, by the project's own definition, is a snapshot of your computer's hardware state and logs. The tool checks operability of devices by analysis of logs, and returns a permanent URL to view that probe. That last part is the design decision that separates this from a local diagnostic dump. A local dump helps you once; a permanent URL lets you hand the same evidence to a forum, a maintainer or a colleague without asking them to install anything or reproduce your hardware.

The intended use is explicitly collaborative. The README asks users to share probes and logs with Linux and BSD developers in order to debug and fix problems, and to simplify hardware inventory in a company. There is a public sample probe linked as an example of what the output looks like.

Two secondary functions come from the same collection pass. If a device does not work because of a missed driver, the tool suggests a proper Linux kernel version according to the LKDDb or third-party drivers. And every probe contributes to a hardware reliability study for drives, hosted in a separate repository.

Nothing is installed into your system by the collection itself. The tool is a single Perl file, hw-probe.pl, and the Makefile in the repository does nothing more than copy it into a bin directory.

The Docker image bundles every tool a probe needs

The container route is the most complete way to run the tool, because the Dockerfile assembles the entire dependency set from scratch on an Alpine base.

The image starts from alpine:3.16 and installs the probe inputs in one layer: dmidecode, pciutils, usbutils, smartmontools, hdparm, sysstat, util-linux, lm_sensors, acpi, iasl for ACPI analysis, wireless-tools, libxrandr, alsa-utils, xrandr, xdpyinfo, xinput, i2c-tools, hwinfo, eudev-libs, libusb, libdrm and perl-libwww.

Two dependencies are compiled from source rather than taken from the package manager. edid-decode is cloned and built for monitor EDID parsing, and ddcutil is checked out at tag 1.2.2-release and built with NOCONFIGURE=1 NO_CONFIGURE=1 sh autogen.sh. Everything else comes from apk. A build-deps virtual package is installed and then removed with apk del build-deps at the end, and the image strips a list of helper binaries that are not needed at runtime.

Running the container needs four host paths mounted read-only plus privileged access:

sudo -E docker run -it \
-v /dev:/dev:ro \
-v /lib/modules:/lib/modules:ro \
-v /etc/os-release:/etc/os-release:ro \
-v /var/log:/var/log:ro \
--privileged --net=host --pid=host \
linuxhw/hw-probe -all -upload

Read-only mounts keep the container from writing to your device nodes, but the privileged flag with host networking and the host PID namespace is a genuine privilege grant. The documentation also notes you may need to run xhost +local: before the container so that X11 information such as xrandr and xinput output can be collected.

Snap and Flatpak sandboxes limit what the probe can see

The packaged installers trade completeness for isolation, and the documentation is candid about it.

The snap is described as a strict snap that runs in a sandbox with limited functionality. SMART attribute checks are blocked until you explicitly enable Access to disk block devices in Permissions, or connect the interface from the command line:

sudo snap connect hw-probe:block-devices :block-devices

Installing it is a single command, and if the binary does not appear on the path you may need to add the snap bin directory to it.

sudo snap install hw-probe
export PATH=$PATH:/snap/bin

The Flatpak path needs a remote added first and then the package installed:

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak install flathub org.linux_hardware.hw-probe
flatpak run org.linux_hardware.hw-probe -all -upload

The Flatpak documentation adds a further condition about running it as root if you want to check hardware more deeply, though the visible text is cut off at that point.

This is the trade-off to weigh before choosing a package format. The Docker image has the widest coverage because it builds and installs the full toolchain, while a sandboxed package installs cleanly on almost any distribution but will report less. A probe that silently omits SMART data because an interface was not connected is a probe that looks thinner than the machine really is.

AppImage, live images and native packages cover the rest

The AppImage route needs no installation at all. The portable app runs anywhere with glibc >= 2.17, and the documented sequence is to make the file executable and run it under sudo:

chmod +x ./hw-probe-1.6.5-189-x86_64.AppImage
sudo -E ./hw-probe-1.6.5-189-x86_64.AppImage -all -upload

You may need the fuse-libs or libfuse2 package if your distribution does not ship it. If the newest image fails to run, the documentation points to an older AppImage, hw-probe-1.4-135-x86_64.AppImage, which runs on 64-bit distributions with Glibc >= 2.14, a list that reaches back to Ubuntu 12.04, Debian 8, openSUSE 12.0, RHEL 7, CentOS 7 and Arch Linux.

For machines where the tool cannot be installed at all, there are live images with hw-probe pre-installed from Debian, ArcoLinux and OpenMandriva. You write the image to USB or CD, boot from it and create the probe. That is the fallback the documentation recommends when a dependency such as hwinfo is missing from your distribution's repository, which is exactly the situation that makes a probe useful in the first place.

Native RPM, Deb and Pkg packages, installation from source, and separate BSD instructions live in INSTALL.md and INSTALL.BSD.md. Note that the README heading reads HW PROBE 1.6.6 while the AppImage download it links is named 1.6.5, so the patch level of the shipped artefact is worth confirming against the releases page rather than assumed from the heading.

Reviewing a probe: correcting statuses and exporting a forum template

A probe is not the end of the workflow. The documentation describes a review step where you adjust device statuses in your probe and leave comments, and it tells you to look for a big green REVIEW button on the probe page.

That review mechanism is the answer to a fair objection. Automated log analysis will sometimes mislabel a device, and a human who recognises their own hardware can correct the status. The adjustment then feeds back into the database, so the next person searching for the same model benefits.

For forum use, the probe page carries an Export template to forum link that generates a BBCode review template, and the project asks that reviews be posted to the Linux Hardware Review forum rather than left only on the probe page.

The documentation's table of contents also lists sections for Inventory, Monitoring, Periodic run, Offline view, ACPI dump, Operability and Disable logs. The visible text of the README does not explain the commands behind those headings, so the flags and behaviours they cover are not something to guess at. What is clear is the shape of the tool: it can run on a schedule through the periodic directory in the repository, it can produce a view that works offline, and it can dump ACPI data.

Licence, BSD coverage and a release line that has gone quiet

The licence field on the repository says Other, a custom licence GitHub cannot classify, with a pointer to the LICENSE file. The repository actually carries LICENSE.md alongside a LICENSES/ directory, which is where a multi-licence or non-standard arrangement is usually spelled out. Anyone planning to redistribute the tool or its output should read those files directly, because the classification on the repository page does not tell you what the terms are.

BSD is treated as a first-class target rather than an afterthought. There is a dedicated INSTALL.BSD.md, the database has a BSD counterpart at bsd-hardware.info, and the Docker route is described as working on any Linux distribution.

The release history is the weak point. The newest tagged release is 1.6, Hardware Probe Tool 1.6, dated 2021-09-21, preceded by 1.6-beta on 2020-05-20 and 1.5 on 2020-01-15. The last push was on 2026-08-14, so the tree is still being worked on, but no new tag has been cut since 2021. The README heading naming 1.6.6 tells you the working version has moved past the 1.6 tag without a corresponding release, which makes the version numbers in download links and the ones in the documentation easy to mix up.

The project is written in Perl, with hw-probe.pl at the top level, and the Makefile is almost empty: all it does is echo Nothing to build and install the script as an executable into the prefix bin directory.

Editorial conclusion

hw-probe suits a Linux or BSD user whose device misbehaves and who wants a link they can paste into a forum thread, and it suits an administrator who wants to simplify a hardware inventory across a fleet. It does not suit a machine where uploading device logs to a public site is not acceptable, and it does not replace a driver package manager, since it suggests a kernel version according to LKDDb or third-party drivers rather than installing anything. Before running it, check the privacy and disable logs sections of the README, confirm the distribution is on the supported list for the packaging you choose, and note that the newest tagged release is 1.6 from 2021-09-21 while the last push was on 2026-08-14.

Frequently asked questions

Official sources

1. Issues
2. linuxhw/hw-probe on GitHub
3. Project website
4. README
5. Releases