Skip to content
Oznog

5.7 · power and environment · as-is

A BMC that reported fabricated power and thermal readings

date
20260901 (approximate, from repository history)
what happened
On these Supermicro boards the BMC's Redfish Power and Thermal resources return static, plausible-looking wrong values rather than real telemetry or an error. A host genuinely running with fans at 9,300 to 9,500 RPM was reported as drawing 18 watts, with all fans at 0 RPM and no temperature readings at all.
what it cost
A near miss. The false reading nearly produced the conclusion that a power-on command had failed, on a host that was running correctly at that moment.
what changed
ipmitool, which reported the truth from the same BMC at the same moment, was adopted as the only trusted path for anything sensor-related on these boards, and a standing rule says fleet monitoring is never wired to Redfish Thermal here.
the check now
ipmitool chassis status and its fan and temperature sensor readings, cross-checked against Redfish's PowerState field, which is accurate in both directions; only Power and Thermal lie.

Redfish is the modern, well-documented HTTP API for server management. IPMI, reached through the ipmitool command, is the older one it was meant to replace. On this Supermicro board family the newer API’s power and thermal endpoints are effectively unimplemented stubs, and they do not say so.

Asked for Power, the BMC returned 18 watts. Asked for Thermal, it returned every fan at 0 RPM and no temperatures at all. That is a coherent picture of a machine that failed to power on, which is exactly what someone was checking for. The machine was running, with its fans at 9,300 to 9,500 RPM, and ipmitool said so from the same BMC, over the same network, at the same moment.

The specific trap is that the failure mode is not an error. An unlicensed or unpopulated Redfish resource here returns a confident-looking zero, which automation reads as a measurement. Worse, the same API is not uniformly wrong. The PowerState field on that very board was accurate in both directions throughout. Any spot check that happened to use PowerState alone would have concluded the API was trustworthy.

The generalisable habit, for anyone automating against unfamiliar server management hardware, is this. A newer, better-documented interface is not automatically more truthful than the old one it replaced. Before you wire power-on verification or thermal alerting to any endpoint, confirm at least one reading against a second, independent tool while the machine is in a known state. Zero fans and no temperature on a running server is a reading you can catch this way in one minute, and it is a reading no alert rule will ever question on its own.

Source: node0 lessons v0.1, lesson 5.7. Sanitized: checklist v0.1, 20260921; names pass only; voice pass 20260921. Part of oznog.com/node0.