Auditing a machine that has no operating system

A second-hand computer arrives with no reliable account of what is inside it. Somebody has to establish the processor, memory, storage, screen and battery, and then — if the drive is to be reused — destroy whatever the previous owner left on it.

The obvious way to collect that information is an agent running on the device. That is useless here. Most machines arrive already wiped, with no operating system to run an agent on. The only way in is to bring your own: boot a live Linux environment from USB, read the hardware directly, and act on it.

That much is ordinary. What was not obvious, before building one, is how much of the difficulty is procedure rather than tooling. The commands to read a DMI table or issue a sanitise are a weekend's work. The rules below took considerably longer, and each one exists because something went wrong without it.

1. The instrument excludes itself

The first version enumerated block devices and took the first one as the machine's drive. The first device was the stick it had booted from, so every audit recorded the characteristics of the USB rather than the laptop.

The fix people reach for is a warning: check the drive carefully before you erase it. That is not a fix, it is a transfer of the problem to whoever is holding the screwdriver.

The rule is structural instead: the boot medium is never present in the target list. Not greyed out, not labelled dangerous — absent. An operator cannot select it by accident because it is not offered, and the invariant holds whether or not anyone is paying attention.

Generalised: an instrument that can act on the thing it is running from has a failure mode no amount of care removes.

2. Read-only before destructive, always

The audit path and the erase path share an environment, a device enumeration and a network connection. If any of those are wrong, the audit will reveal it harmlessly.

So the order is fixed: capture first, erase second — not because capture is more important, but because it is the free test of everything the destructive step depends on. A procedure that erases before it has proved its own footing is spending a drive to discover a typo.

3. Collect; do not verify

The first version tried to do both: capture the machine and check it against what was expected. Reworking it so the tool simply captures made both jobs better. The audit states what is there. Reconciling that against an expectation is a separate concern, done later, by something that can see both sides.

Mixing them meant a capture failure and a mismatch produced the same output, and neither could be investigated without untangling the other.

4. A missing prerequisite says "missing"

Some functions depend on something that may simply not be present — an image, a tool, a network. The tempting behaviour is to fall back to a default and carry on.

Everything learned on this project argues against it. A function whose prerequisite is absent reports "missing", in those words, and does nothing. It does not substitute, and it does not silently succeed at a reduced version of the job.

This is the same discipline as the false-absence class: a failed observation and a genuine negative must not produce the same sentence. A missing prerequisite and a satisfied one must not produce the same outcome.

5. Configuration values are never read back

The configuration file carries credentials. Two rules apply to it, and the second is the one usually missed.

It is excluded from version control — routine. And its values are never read or printed by the tool's own diagnostics: only their presence and format. A status screen can say a field is set and well-formed. It cannot say what it contains.

The reason is that diagnostics get screenshotted, pasted into messages, and attached to bug reports by people trying to be helpful. A tool that will print a credential on request will eventually print one into a group chat.

6. Capture into a shape that can grow

The profile was built as an extensible structure rather than a fixed set of columns, on the reasoning that what is worth recording about a machine grows.

That has held better than any other decision here. Drive health, lock detection, operating-system capture and functional testing were all added inside the original structure without a schema change — four features that did not exist when the shape was chosen.

The cost of guessing the columns is paid every time you guess wrong. The cost of an extensible shape is paid once, in the slightly worse ergonomics of reading it.

The practical one

One detail is too specific to be a principle and too useful to leave out.

When writing a live Linux ISO to a USB stick, choose the imaging mode that leaves the stick writable afterwards. The toolchain that runs on top of the live environment then updates by copying files onto the medium, rather than by rebuilding and re-flashing the whole image.

The difference between a two-minute update and a twenty-minute one decides how often a fix actually reaches the bench.

---

None of this is exotic. Every rule is the kind of thing that reads as obvious once written down, and none of them were obvious while the thing was being built. They are recorded here in the order they were learned, which is also roughly the order of how much each one cost.