Bare-Metal Server Hardware Acceptance Audit
Claude Fable 5
Runs a provider- and architecture-agnostic hardware acceptance audit on a new bare-metal server over SSH - drive wear, ECC RAM, CPU thermals - and delivers a KEEP or REJECT verdict.
Prerequisites
- SSH key access to the server Keys already configured for root or a sudo-capable user.
- Data disks are wipeable The performance test erases drives it proves empty; skip that section if anything on the box must survive.
- Outbound internet on the server Needed to install the diagnostic packages (nvme-cli, smartmontools, fio, stress-ng).
Variables
Edits here and in the highlighted fields inside the prompt stay in sync.user@address or SSH alias of the new server.
What the provider promised: CPU, RAM size and speed, drive models and count, NIC speed.
You have SSH access (keys already configured) to a brand-new bare-metal server I just acquired. Connect to: {{host}}
Advertised specs to verify against: {{advertised_specs}}
GOAL: run a full hardware acceptance audit BEFORE this server enters service, while the provider's replacement window is still open. Priorities: (1) drive wear and health, (2) RAM configuration, speed, and ECC, (3) full inventory plus CPU/thermal stability under load, (4) confirm the delivered hardware matches what was advertised. SSH in, run everything yourself, interpret the results, and produce a written report with a clear KEEP / REJECT verdict.
═══ SAFETY (read carefully) ═══
- Default to READ-ONLY, non-destructive commands.
- Installing diagnostic packages is fine (it is a fresh box).
- The ONLY destructive action permitted is the drive performance test in section 5, and ONLY on drives you FIRST prove are empty: no partitions, no filesystem signatures, no mountpoints, no RAID membership, no LVM or dm-crypt use. Verify with `lsblk -f`, `cat /proc/mdstat`, and `pvs`. If ANY drive shows any sign of use, SKIP the destructive test for it and report read-only health only. When in doubt, skip and tell me.
- Never run a write, erase, or format against a mounted or in-use disk.
- Make no other system changes. Do not install an OS, do not reconfigure anything.
═══ HOW TO WORK: DETECT, THEN RUN ═══
This box could be any distro, any CPU vendor (AMD, Intel, ARM/Ampere), and any drive type. Do NOT assume. Run PHASE 0 first, build a short platform profile, and for every later step choose the command variant that matches what you detected. If a tool or data source does not exist on this platform, use the stated fallback; if even the fallback yields nothing, say so explicitly in the report rather than skipping silently. Never let one missing tool abort a whole section.
═══ PHASE 0. DETECT THE PLATFORM ═══
Run these and record the answers as your working profile:
- Distro and package manager: cat /etc/os-release (apt-get on Debian/Ubuntu, dnf on RHEL/Fedora/Alma/Rocky, zypper on SUSE, pacman on Arch)
- Architecture and CPU vendor: uname -m ; nproc ; lscpu | grep -iE "Architecture|Vendor ID|Model name|Socket|NUMA" (AuthenticAMD, GenuineIntel, or an ARM implementer such as Ampere/ARM)
- Firmware tables (decides the RAM path): test -d /sys/firmware/dmi/tables && echo "DMI present" || echo "no DMI (expect ARM; use the /sys + EDAC RAM path)"
- Drives present: lsblk -d -o NAME,TYPE,ROTA,TRAN,MODEL ; ( command -v nvme >/dev/null && nvme list ) ; ( command -v smartctl >/dev/null && smartctl --scan ) (note which are NVMe, which are SATA/SAS SSD (ROTA=0), which are HDD (ROTA=1))
- Thermal source: ( command -v sensors >/dev/null && sensors ) ; ls /sys/class/thermal/thermal_zone*/type 2>/dev/null (use lm-sensors if it reports chips, otherwise the thermal_zone sysfs path)
- EDAC/ECC path: ls /sys/devices/system/edac/mc 2>/dev/null ; dmesg | grep -i edac | head
State the profile in one short block before proceeding.
═══ SETUP ═══
Install with the package manager you detected: nvme-cli smartmontools dmidecode edac-utils rasdaemon stress-ng lm-sensors fio ethtool util-linux pciutils
(Package names vary slightly per distro. If one package has no install candidate, install the rest and adapt: e.g. mcelog is often uninstallable on Debian, so use rasdaemon plus journalctl for machine-check evidence. dmidecode is meaningless on DMI-less ARM; that is fine, the RAM section has a sysfs path.)
═══ 1. INVENTORY + DELIVERY CHECK ═══
lscpu
lsblk -o NAME,SIZE,ROTA,TYPE,FSTYPE,MOUNTPOINT,MODEL,SERIAL
nvme list 2>/dev/null ; smartctl --scan
lspci -nnk 2>/dev/null | grep -iA2 -E "non-volatile|nvme|ethernet|raid|sas"
cat /proc/mdstat 2>/dev/null ; free -h
Board/BIOS identity by platform:
- DMI present: dmidecode -t system -t baseboard -t bios | grep -iE "Manufacturer|Product|Version|Serial Number|Release Date"
- No DMI (ARM): read /proc/device-tree/model, /sys/firmware/devicetree, and lshw -short (install lshw if needed)
INTERPRET: build the inventory table, then compare it line by line against the advertised specs above: CPU model and core count, total RAM, drive count/models/capacities, NIC speed. Report any delivery mismatch prominently - a wrong CPU, less RAM, or a different drive model is exactly what the acceptance window exists to catch.
═══ 2. RAM - population, speed, ECC (PRIORITY) ═══
Choose the path from PHASE 0:
- DMI PRESENT (typical x86 AMD/Intel):
dmidecode -t memory | grep -iE "Locator|Size|Configured Memory Speed|^\s+Speed|Rank|Manufacturer|Part Number|Error Correction Type" | grep -v "No Module\|Unknown"
dmidecode -t memory | grep -c "Size: [0-9]* [GM]B" # populated DIMM count
- NO DMI (typical ARM): per-DIMM part numbers and configured speed are usually unavailable in firmware; report what IS exposed:
lshw -class memory 2>/dev/null ; cat /proc/meminfo | head -1
for d in /sys/devices/system/edac/mc/mc*/dimm*; do echo "$d"; cat "$d/dimm_label" "$d/size" "$d/dimm_edac_mode" 2>/dev/null; done
State plainly that per-DIMM speed/part detail is not firmware-exposed on this platform.
ECC status, then errors (both paths):
modprobe amd64_edac 2>/dev/null # AMD; Intel: sb_edac / skx_edac / i10nm_edac (pick by CPU gen); ARM: usually firmware-first GHES, already active
edac-util -v 2>/dev/null ; ras-mc-ctl --status ; ras-mc-ctl --error-count
grep -H . /sys/devices/system/edac/mc/mc*/ce_count /sys/devices/system/edac/mc/mc*/ue_count 2>/dev/null
journalctl -k | grep -iE "edac|ecc|machine check|chip select" | head -40
INTERPRET: report the per-DIMM count, sizes, ranks, part numbers, and Configured Memory Speed for every value the platform exposes; where a value is not exposed (common on ARM), say so rather than guessing. Determine the memory channel count from the CPU model, judge whether the population is channel-balanced, and explain the bandwidth implication of asymmetric population (capacity/VM-density workloads are largely unaffected; bandwidth-bound ones are not). Where speed IS available, flag hard if it is below both the module rating and the platform maximum, and explain the likely cause (mixed speed grades, two DIMMs per channel, or asymmetric population). ECC must be present and active with 0 corrected / 0 uncorrected.
═══ 3. DRIVE WEAR AND HEALTH (PRIORITY) - every drive ═══
Audit each block device by the type you detected.
NVMe, per controller/namespace:
nvme id-ctrl <ctrl> | grep -iE "^mn |^sn |^fr " # model, serial, firmware
nvme smart-log <dev> ; nvme error-log <dev> | head -20
nvme device-self-test <dev> -s 0x2 ; then POLL nvme self-test-log <dev> until it completes (do not fixed-sleep)
host TB written = data_units_written x 512000 / 1e12
SATA/SAS SSD: smartctl -a <dev> - wear attributes (Media_Wearout_Indicator, Wear_Leveling_Count, Percent_Lifetime_Remain, Total_LBAs_Written) plus Reallocated/Pending/Uncorrectable sectors; run smartctl -t long <dev> and poll smartctl -l selftest.
HDD (if any): smartctl -a <dev> - Reallocated_Sector_Ct, Current_Pending_Sector, Offline_Uncorrectable, Load_Cycle_Count, Power_On_Hours; smartctl -t long and poll.
INTERPRET: identify each drive model, look up its endurance rating (TBW or DWPD) and whether it has power-loss protection (enterprise vs consumer SKU - name which). Apply skeptical cross-checking: provider stock often carries heavy prior write history. A large host-writes figure is NOT a failure if the spare pool is untouched and media errors are zero - firmware-measured wear (NVMe percentage_used or the SATA wear attribute) corroborated by a 100% available spare is the real longevity signal. Compute consumed life BOTH ways and show the gap: (a) the firmware wear figure, and (b) host TB written divided by rated TBW. Decorrelated wear between drives is fine (good for a future mirror). Per-drive REJECT triggers: media errors > 0, any critical warning, available spare at or near its threshold, a failed self-test, or (SATA/HDD) nonzero reallocated or pending sectors.
═══ 4. CPU + THERMAL under sustained load ═══
Idle baseline, by the thermal source from PHASE 0:
- lm-sensors reports chips: sensors
- otherwise (common on ARM): for z in /sys/class/thermal/thermal_zone*; do echo "$(cat $z/type): $(cat $z/temp)"; done
Load and sample:
stress-ng --cpu $(nproc) --cpu-method all --timeout 180s --metrics-brief &
for i in 1 2 3 4 5; do sleep 35; echo "--- sample $i ---";
( sensors 2>/dev/null | grep -iE "Tctl|Tdie|Package|Composite|temp1" ) || for z in /sys/class/thermal/thermal_zone*; do echo "$(cat $z/type): $(cat $z/temp)"; done;
grep MHz /proc/cpuinfo | sort | uniq -c | head -3 ; done
wait
ras-mc-ctl --error-count ; journalctl -k | grep -iE "mce|machine check|thermal|throttl" | tail
INTERPRET: know the throttle point for the identified CPU family and report whether the temperature plateaus with headroom, whether sustained all-core clocks hold near the rated speed, that ECC counters stayed 0/0 under load, and that there are NO machine-check or thermal-throttle events. (Note: `watch` may fail with "Error opening terminal" over SSH; use the sampling loop above. sysfs thermal_zone temps are in millidegrees C - divide by 1000.)
═══ 5. DRIVE PERFORMANCE - DESTRUCTIVE, ONLY ON DRIVES PROVEN EMPTY IN SECTION 1 ═══
# Gate: re-verify the drive is unpartitioned and unmounted immediately before each run.
For each verified-empty drive:
fio --name=seqw --filename=<dev> --rw=write --bs=1M --iodepth=32 --numjobs=1 --direct=1 --runtime=30 --time_based --group_reporting
fio --name=randw --filename=<dev> --rw=randwrite --bs=4k --iodepth=64 --numjobs=4 --direct=1 --runtime=30 --time_based --group_reporting
fio --name=randr --filename=<dev> --rw=randread --bs=4k --iodepth=64 --numjobs=4 --direct=1 --runtime=30 --time_based --group_reporting
Afterwards TRIM the tested SSDs back to fresh: blkdiscard <dev> (never on HDDs)
INTERPRET: compare results against the identified model's rated spec - do not flag a result that simply matches a read-optimized SKU's modest write rating. Watch for a sustained-write throughput cliff or thermal throttling. Note that psync-style engines cap effective queue depth, so low-QD random-read numbers are expected and not a defect.
═══ 6. NIC ═══
IF=$(ip -o link show up | awk -F': ' '!/lo/{print $2; exit}')
ethtool $IF | grep -E "Speed|Duplex|Link detected"
ethtool -S $IF 2>/dev/null | grep -iE "err|drop|crc" | head
INTERPRET: link speed and duplex must match what was advertised (1G / 10G / 25G); error and drop counters should be zero or negligible.
═══ OUTPUT ═══
Save a Markdown report to ./server-audit-<hostname>-<date>.md AND print a summary, containing:
- The detected platform profile (distro, arch, CPU vendor, DMI yes/no, drive types).
- Full inventory (CPU, board/BIOS, RAM, drives with models and serials, NIC) plus a delivered-vs-advertised table with any mismatches flagged.
- A per-drive health table (model, PLP yes/no, firmware wear, available spare, media errors, host TB written, power-on hours, self-test result) plus the dual-lens life-consumed comparison.
- The RAM table (DIMM count/size/rank/part number/configured speed for every value the platform exposes), channel-balance judgment, and ECC result (idle AND under load).
- CPU stress and thermal result, NIC link, and fio numbers (or a clear note that the perf test was SKIPPED for drives not proven empty).
- A final KEEP / REJECT verdict against the reject triggers in sections 2-4, with borderline items flagged rather than silently passed.
- An explicit list of anything that warrants a support ticket with the provider (defective drive or DIMM, hardware differing from the order, RAM configured below advertised speed), and an explicit list of any check that could not be run on this platform and why.
If a credential or connection issue, or a genuinely ambiguous disk state, blocks you: ask me ONE focused question; otherwise proceed and state your assumptions. Begin by SSHing in and running PHASE 0 plus the section 1 inventory and mount-state check before anything destructive.
Why this works
It detects the platform first - distro, CPU vendor, firmware tables, drive types, sensor and EDAC stack - then runs the command variant that fits, so the same prompt works on any Linux server across AMD, Intel, and ARM instead of assuming one layout. The audit is gated so the only destructive step is provably safe, and the dual-lens wear analysis (firmware wear vs host writes over rated TBW) defends against refurbished drives whose SMART looks cosmetically fine. Verifying delivered hardware against the advertised specs catches provider mistakes while the replacement window is still open, and every check that a given platform cannot support is reported explicitly rather than skipped silently.