Learn › BMC & Server Management › OpenBMC on Real Firmware
Run ipmitool against real firmware and learn which numbers on a BMC you can trust. Pull mc info, the System Event Log and the 135-entry sensor catalog, then confirm from both protocols that this machine publishes names without readings, and write down why.
While you were powering that machine up and down in FW-03, something was keeping notes. Every threshold crossing, every power event, stamped with the moment it happened and stored on standby power.
Redfish told you the state right now. This lesson is about the record of what already happened, and about a harder lesson underneath it: knowing which numbers on a BMC are real.
Before you trust a log, identify the thing that wrote it. mc info asks the management controller to describe itself: mc is short for management controller, the IPMI name for the BMC.
prompt: ops@dc-east-fw01:~$ answer: ipmitool -I lanplus -H $BMC_HOST -p $BMC_IPMI_PORT -U root -P 0penBmc mc info output: Device ID : 0 Device Revision : 0 Firmware Revision : 3.01 IPMI Version : 2.0 Manufacturer ID : 0 Manufacturer Name : Unknown Product ID : 0 (0x0000) Product Name : Unknown (0x00) Device Available : yes Provides Device SDRs : yes Additional Device Support : Sensor Device SEL Device FRU Inventory Device Chassis Device hint: Same ipmitool connection flags you used in FW-03, then mc info
The bottom block is the useful part. Additional Device Support is the controller listing what it implements: a sensor device, a SEL device, a FRU inventory, and chassis control. That list is your map of what to ask for next.
Manufacturer Name : Unknown is honest, not broken. The open firmware does not claim a vendor identity here, where a Dell or an HPE would stamp its own. It is a fingerprint worth recognising in the field.
The SEL, the System Event Log, is the BMC black box recorder. It survives the host being off, because the BMC is on standby power and keeps writing regardless.
Read the first few entries.
prompt: ops@dc-east-fw01:~$ answer: ipmitool -I lanplus -H $BMC_HOST -p $BMC_IPMI_PORT -U root -P 0penBmc sel list | head -3 output: 1 | 07/31/26 | 10:15:14 UTC | System Event #0x90 | Undetermined system hardware failure | Asserted 2 | 07/31/26 | 10:15:22 UTC | System Event #0x90 | Undetermined system hardware failure | Asserted 3 | 07/31/26 | 10:17:07 UTC | System Event #0x90 | Undetermined system hardware failure | Asserted hint: The same ipmitool connection, then sel list, piped through head -3
Read a row left to right: entry number, date, time, the sensor that fired, what happened, and whether the condition asserted or cleared.
Those timestamps are the point. Entry 3 lands at 10:17:07, seconds before a power action was issued at 10:17:01 on the capture run. The log is genuinely recording events on this machine, not replaying a canned file.
On a real incident the SEL is the first thing you pull and the last thing you clear. Save it to a file before anyone runs sel clear, because that command is instant and there is no undo.
Now the SDR, the Sensor Data Repository. It is the catalog of every sensor the controller knows about, generated from the machine inventory. On this machine it holds 135 entries.
Look at the first four.
prompt: ops@dc-east-fw01:~$ answer: ipmitool -I lanplus -H $BMC_HOST -p $BMC_IPMI_PORT -U root -P 0penBmc sdr list | head -4 output: BootProgress | 0x00 | ok occ0 | disabled | ns cpu0 | disabled | ns dimm0 | disabled | ns hint: The same ipmitool connection, then sdr list, piped through head -4
Three columns: the sensor name, its reading, and its status. ns means no reading available.
The names are real inventory. cpu0 and dimm0 are the processor and memory slots this platform was designed with, and further down the list are twenty four cores per socket across two sockets. The catalog describes a genuine POWER9 server.
Look at that middle column again before you read on, and commit to an explanation for it. This is the most important judgement call in the whole module.
>>> There is nothing behind the names. This firmware is running on an emulated service processor, and an emulator models the BMC chip, not the twenty four cores and sixteen memory modules the BMC would normally be wired to. The catalog is completely real, generated from the platform inventory the way it is on a physical machine. The readings are absent because the silicon that would produce them does not exist here. That distinction, a real catalog with no live values, is exactly what you are about to confirm from the other protocol.
If IPMI has names without readings, Redfish should agree. Modern Redfish puts readings in a Sensors collection under the chassis.
Every Redfish collection publishes how many members it holds, in a field named [email protected]. Ask for the count.
prompt: ops@dc-east-fw01:~$ answer: curl -sk -u root:0penBmc "$BMC_URL/redfish/v1/Chassis/chassis/Sensors" | jq -r '."[email protected]"' ||| curl -sk -u root:0penBmc $BMC_URL/redfish/v1/Chassis/chassis/Sensors | jq -r '."[email protected]"' output: 0 hint: The collection is /redfish/v1/Chassis/chassis/Sensors and the field is "[email protected]"
Zero. Both protocols, independently, tell you the same true thing: this BMC has no live readings to give. The ThermalSubsystem next door exists and reports itself healthy, and its Fans collection is empty for the same reason.
There is an older schema for the same job, called Thermal. Ask for it and watch what happens.
prompt: ops@dc-east-fw01:~$ answer: curl -sk -u root:0penBmc "$BMC_URL/redfish/v1/Chassis/chassis/Thermal" | jq -r '.error.code' ||| curl -sk -u root:0penBmc $BMC_URL/redfish/v1/Chassis/chassis/Thermal | jq -r '.error.code' output: Base.1.19.ResourceNotFound hint: Request /redfish/v1/Chassis/chassis/Thermal and pull .error.code out of the reply
A Redfish error is a structured object, not a wall of HTML, so you can pull the machine-readable code straight out with jq. Base.1.19.ResourceNotFound is the registry name of the error.
And this 404 is correct. Thermal was deprecated in favour of ThermalSubsystem and Sensors. Its absence means this firmware is current, not that it is missing something.
Two more limits on this build, so you know them before you go looking. IPMI Serial over LAN fails here with Error requesting SOL parameter 'Set In Progress (0)': Invalid data field in request, and the Redfish VirtualMedia resource returns 404. The console has another route, which you will use in the capstone.
You have confirmed the limit from both protocols. The last question is what changes when this same code runs on real silicon.
>>> The names stay and the readings arrive. The catalog is built from the platform inventory either way. What is missing here is the hardware underneath: the temperature sensors, voltage regulators and fan tachometers a real board wires into the service processor. Put the same code on real silicon and cpu0 reports a temperature, the Sensors collection fills with members, and the fan collection lists real fans. Knowing which layer a missing number comes from is a diagnostic skill, and you just practiced it on both protocols.
One more read, and no shape given for it. You have seen the top of the sensor catalog. Get the bottom of it.
prompt: ops@dc-east-fw01:~$ answer: ipmitool -I lanplus -H $BMC_HOST -p $BMC_IPMI_PORT -U root -P 0penBmc sdr list | tail -3 output: p1_core23_temp | disabled | ns AttemptsLeft | 0x01 | ok OperatingSystemS | 0x00 | ok hint: The same sdr list, but take the end of the output instead of the start
p1_core23_temp is processor 1, core 23. Two sockets with twenty four cores each is a real POWER9 configuration, and the catalog names every one of them.
Work Order FW-04, six objectives.
1. Identify the controller. Save mc info to ~/mc-info.txt. 2. Pull the log. Save the event log to ~/sel.txt. 3. Pull the catalog. Save the sensor catalog to ~/sdr.txt. 4. Check the modern plane. Save the Redfish sensor collection to ~/sensors.json. 5. Record the 404. Put what Thermal returns in ~/thermal-404.txt. 6. The challenge. Write the honest report in ~/sensor-report.txt.
The grader re-runs the sensor and thermal queries against the BMC itself, so your files have to match what the firmware actually says.
Your workstation is booting below with the OpenBMC instance beside it. Open Work Order FW-04, read the machine honestly, and write down what it can and cannot tell you.
Practice The Event Log and ipmitool in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.