Learn › BMC & Server Management › OpenBMC on Real Firmware
Drive a real power state machine from four hundred miles away. POST ComputerSystem.Reset against live OpenBMC firmware, read the 204 it answers with, catch PowerState moving through PoweringOn, then bring the same machine down with ipmitool and prove both planes agree.
The machine in Bay 3 is powered down. Nobody is in the building. The work order says bring it up, confirm it came up, then put it back the way you found it.
You have no hands on that chassis and no power button to press. What you do have is a service processor that is awake, on standby power, and holding the power rail of the machine it lives inside.
Most of Redfish is nouns: objects you read, fields you sometimes change. Power is different. Power is a verb, and Redfish models verbs as actions.
An action is a URL you POST to, with a JSON body naming what you want. The one that controls a host is ComputerSystem.Reset, and it lives under the system object you already know.
/redfish/v1/Systems/system/Actions/ComputerSystem.Reset
The body carries a ResetType. On powers up, GracefulShutdown asks the operating system to stop politely, ForceOff cuts the rail, and ForceRestart slams it off and on. Choosing between them is the whole skill.
Before you change any state, record the state. This is not paperwork, it is how you prove afterwards that you caused what you claim you caused.
prompt: ops@dc-east-fw01:~$ answer: curl -sk -u root:0penBmc "$BMC_URL/redfish/v1/Systems/system" | jq -r '.PowerState' ||| curl -sk -u root:0penBmc $BMC_URL/redfish/v1/Systems/system | jq -r '.PowerState' output: Off hint: The ComputerSystem object at /redfish/v1/Systems/system carries a top-level PowerState field
Off. That is your before picture, on the record.
Before you press anything, decide what you expect the machine to say back. Most people get this one wrong, and then misread a success as a failure.
>>> A bare 204 No Content. The action was accepted, and there is no resource to hand back, so the correct answer is a status code and no body. That trips people up: they pipe the response into jq, get nothing, and think it failed. It did not. The way you confirm a power action is to read PowerState afterwards, never to read the reply.
Because the useful part of the reply is the status code and not the body, ask curl for exactly that. -o /dev/null drops the body, -w '%{http_code}' prints the code.
prompt: ops@dc-east-fw01:~$ answer: curl -sk -u root:0penBmc -o /dev/null -w '%{http_code}\n' -X POST -H 'Content-Type: application/json' -d '{"ResetType":"On"}' "$BMC_URL/redfish/v1/Systems/system/Actions/ComputerSystem.Reset" output: 204 hint: POST to /redfish/v1/Systems/system/Actions/ComputerSystem.Reset with the body {"ResetType":"On"}, and print only %{http_code}
If the code that comes back is 503 and not 204, your command is not wrong. A BMC brings its services up in stages, and the one that owns power is among the last to arrive, so the action URL answers before anything is listening behind it. Wait a few seconds and send the identical POST again, as many times as it takes. Get the accepted code on the record, because > overwrites your file and you do not want an early refusal sitting there as your evidence.
Here is that same response with its headers, exactly as the firmware sent them.
HTTP/2 204
allow: POST
odata-version: 4.0
strict-transport-security: max-age=31536000; includeSubdomains
pragma: no-cache
cache-control: no-store, max-age=0
x-content-type-options: nosniff
date: Fri, 31 Jul 2026 10:17:01 GMTallow: POST is the service telling you this URL only ever accepts a POST. cache-control: no-store is it telling every proxy in the path never to remember this. The date line is from the run this was captured on, so yours will read your own clock.
Power is not instant. There is a real sequence: rails come up, the service processor releases the host, firmware starts. Redfish exposes that sequence, and if you read fast enough you can watch it move.
Read the state again a few seconds after the action.
prompt: ops@dc-east-fw01:~$ answer: curl -sk -u root:0penBmc "$BMC_URL/redfish/v1/Systems/system" | jq -r '.PowerState' ||| curl -sk -u root:0penBmc $BMC_URL/redfish/v1/Systems/system | jq -r '.PowerState' output: PoweringOn hint: Exactly the same read as your baseline. The value is what changed, not the command
Eight seconds after the action, this machine reported PowerState: PoweringOn with Status.State: Starting. A HostWatchdogTimer object also appeared on the system, which had not existed while the host was off. Objects can come into being when hardware changes state.
Give it around three minutes. This service processor is emulated, so every stage of the sequence runs slower than it would on a real board, and the climb is not tidy. On the way up the power state can read PoweringOn, then Off, then PoweringOff, before it lands. Reading Off a minute in does not mean the action failed, it means you caught a state machine still doing its work. Read it again.
When it stops moving, read the state field that tracks the machine rather than the rail.
prompt: ops@dc-east-fw01:~$ answer: curl -sk -u root:0penBmc "$BMC_URL/redfish/v1/Systems/system" | jq -r '.Status.State' ||| curl -sk -u root:0penBmc $BMC_URL/redfish/v1/Systems/system | jq -r '.Status.State' output: Quiesced hint: Status is an object on the ComputerSystem, and the field inside it is State
On this run PowerState reached On while Status.State read Quiesced. Powered, but not running anything.
That is correct behavior here, and it is the honest boundary of this module. The firmware you are driving emulates the service processor only. There is no host processor behind it to finish booting, so the BMC drives the full power state machine and the machine then sits quiet.
Do not skip past that. It teaches the thing beginners get wrong about BMCs: a BMC controls power, it does not perform the boot. It can hold the rail, force a boot device and watch the console, and it still cannot make a dead CPU start. When a host will not come up, PowerState: On narrows the fault, it does not clear it.
Redfish is not the only way in. This firmware also answers IPMI, the older standard, over RMCP+ on UDP port 623. Same machine, same power state machine, different protocol.
ipmitool speaks it. -I lanplus selects the encrypted network interface, and your endpoint is already in the shell.
prompt: ops@dc-east-fw01:~$ answer: ipmitool -I lanplus -H $BMC_HOST -p $BMC_IPMI_PORT -U root -P 0penBmc power off output: Chassis Power Control: Down/Off hint: ipmitool -I lanplus with -H $BMC_HOST -p $BMC_IPMI_PORT -U root -P 0penBmc, then the words power off
One line back, and the rail is gone. Two protocols, thirty years apart in design, driving one state machine on one machine.
chassis status is the IPMI question that predates Redfish by decades, and it is still the fastest way to see the electrical picture.
prompt: ops@dc-east-fw01:~$ answer: ipmitool -I lanplus -H $BMC_HOST -p $BMC_IPMI_PORT -U root -P 0penBmc chassis status output: System Power : off Power Overload : false Power Interlock : inactive Main Power Fault : false Power Control Fault : false Power Restore Policy : always-off Last Power Event : Chassis Intrusion : inactive Front-Panel Lockout : inactive Drive Fault : false Cooling/Fan Fault : false Sleep Button Disable : not allowed Diag Button Disable : not allowed Reset Button Disable : allowed Power Button Disable : allowed Sleep Button Disabled: false Diag Button Disabled : false Reset Button Disabled: false hint: Same ipmitool connection flags as the power command, but ask for chassis status
System Power : off agrees with the action you just took. Power Restore Policy : always-off is worth knowing on any real machine: it decides what happens after a facility power cut, and always-off means the machine stays down until someone tells it otherwise.
On this firmware ipmitool often prints Error: no response from RAKP 1 message and Error: Received an Unexpected RAKP 2 message before the output you asked for. That is the encrypted handshake timing out once and being retried, and the command then completes normally. A slow BMC produces exactly this noise on real hardware too. Read under it, do not panic at it.
One last thing to fix in your head before the work order, because it is the difference between pressing buttons and diagnosing.
>>> You have cut the problem in half. The BMC accepted the actions, the rail came up, and the state machine moved, so power delivery and the service processor are both fine. The fault lives above them: firmware, boot device, operating system, or network. That is why an engineer reads PowerState after every action instead of trusting the click. It is not confirmation, it is a measurement that narrows the search.
Work Order FW-03, six objectives. Leave the machine off when you are done, the way you found it.
1. Baseline. Record the starting power state in ~/power-before.txt. 2. Power on. Save the status code the action returns to ~/reset-status.txt. 3. Catch the transition. Capture the state while it is moving, in ~/power-transition.txt. 4. Let it settle. Capture where it lands, in ~/power-after.txt. 5. Cross planes. Power it back down with IPMI and log the result to ~/ipmi-power.txt. 6. The challenge. Put both planes in one report, ~/power-report.txt.
The grader does not take your word for it. For the power tasks it queries the BMC itself and checks that the machine really is in the state your file claims.
Your workstation is booting below with the OpenBMC instance beside it. Real firmware needs about two minutes before Redfish answers, and the power state machine takes its own seconds after that. Open Work Order FW-03 and drive it.
Practice Power Control and the State Machine in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.