Learn › BMC & Server Management › First Day on the Floor
Prove what hardware is in the box before an OS ever installs. Read the FRU and SPD chips through the BMC, capture Dell-shell inventories into audit files, and pull vendor-neutral FRU records with ipmitool on a real machine.
It is 08:40 at the DC-EAST facility in Ashburn, Virginia. The Dell PowerEdge R750xs in Bay 14, Row 7 is the same box you brought online in Work Order DC-EAST-WO-1001. It has power, a verified BMC, and as of this morning it is switched on and burning in. It still has no operating system.
It also has a problem: asset management has blocked it from the production pool. No intake audit on file, no production traffic. Work Order DC-EAST-WO-1003 is on your tablet: prove what hardware is actually in the box, from the BMC. Every processor, every DIMM, every drive, every serial that matters, filed.
Why so strict? Picture month six. A DIMM in this server dies. If its part number and the chassis serial are on file from day one, the warranty claim is a five-minute form. If they are not, someone has to take the box down, open it, and argue with a vendor. Data centers run on this paperwork, and today you learn to produce it straight from the hardware.
This is a Practice Zone. The diagrams below react to you: click the boxes, flip the switches. The real machine comes at the end, under Ready to practice.
Where does hardware inventory actually live? Not in a spreadsheet, and not in the operating system. It is written on the parts themselves.
A FRU (Field Replaceable Unit) is any component a technician can swap in the field: the system board, a power supply, a drive backplane. Each one carries a tiny memory chip called an EEPROM (electrically erasable programmable read-only memory), and the factory burns the part's identity into it: manufacturer, model, part number, serial. DIMMs carry the same idea in an SPD chip (Serial Presence Detect): part number, size, and speed, stored on the module itself.
The BMC reads every one of those chips over I2C, a slow two-wire sideband bus that runs on standby power. No OS involved, no host CPU involved. The ledger is on the parts, and the BMC is the clerk who can read it at any time.
{ "height": 440, "caption": "The inventory is stored on the parts themselves. Flip the host power and see what survives.", "nodes": [ { "id": "you", "label": "You (dc-east-ws01)", "kind": "admin", "x": 0, "y": 230, "detail": "Your workstation on the management network. Every read in this lab starts here." }, { "id": "bmc", "label": "BMC", "kind": "bmc", "x": 300, "y": 140, "detail": "The always-on management computer. It reads every component EEPROM over the I2C/SMBus sideband, on standby power, with the host in any state." }, { "id": "fru", "label": "Board FRU EEPROM", "kind": "sensor", "x": 620, "y": 20, "detail": "A tiny memory chip on the system board holding manufacturer, model, and serial, burned in at the factory." }, { "id": "spd", "label": "DIMM SPD chips", "kind": "sensor", "x": 620, "y": 120, "detail": "Every DIMM carries its own SPD chip with part number, size, and speed. The BMC reads it without any OS." }, { "id": "bkpln", "label": "Drive backplane", "kind": "sensor", "x": 620, "y": 220, "detail": "The board the drives plug into. It knows slots, models, and firmware." }, { "id": "psu", "label": "PSU FRUs", "kind": "psu", "x": 620, "y": 320, "detail": "Each power supply carries its own FRU EEPROM: model, wattage, firmware." }, { "id": "eth0", "label": "eth0", "kind": "nic", "x": 300, "y": 400, "detail": "The host's network port. It only answers while an OS is up, and there is no OS on this box yet." }, { "id": "host", "label": "Host OS", "kind": "host", "x": 620, "y": 420, "detail": "The in-band road to inventory (dmidecode, lsblk) needs a booted OS. This box does not have one." } ], "edges": [ { "from": "you", "to": "bmc", "label": "IPMI / SSH", "kind": "oob" }, { "from": "bmc", "to": "fru", "kind": "mgmt" }, { "from": "bmc", "to": "spd", "kind": "mgmt" }, { "from": "bmc", "to": "bkpln", "kind": "mgmt" }, { "from": "bmc", "to": "psu", "label": "I2C sideband", "kind": "mgmt" }, { "from": "you", "to": "eth0", "label": "in-band (needs a running OS)", "kind": "inband" }, { "from": "eth0", "to": "host", "kind": "inband" } ], "toggle": { "label": "Host power:", "on": "Powered ON", "off": "Powered OFF", "dimOff": ["host", "eth0", "e:you-eth0", "e:eth0-host"] } }
Click through the chips, then flip the host power off. Every EEPROM edge survives. Inventory is a management-plane job, not an OS job.
>>> Yes. You just flipped the toggle that proves it: kill the host power and the BMC's sideband edges to every EEPROM stay lit. The moment the rack feeds the box standby power, the whole parts ledger is readable. That is why intake audits happen before an OS ever installs.
In WO-1001 you stood inside this BMC's Dell shell and ran getsysinfo, the identity readout: model, hostname, firmware, and the Service Tag, Dell's name for the chassis serial number. On this box it reads SVC1234567. Remember it. That one string ties every audit file you produce today to this exact chassis.
The shell has a deeper readout built for exactly this work order. SSH into the BMC like last time, and at the /admin1-> prompt, run hwinventory:
prompt: /admin1-> answer: hwinventory output: Hardware Inventory ============================================================
Processors ------------------------------------------------------------ Socket Model Cores Threads Speed -------------------------------------------------------- CPU0 Intel Xeon Gold 5416S 16 32 2.0 GHz CPU1 Intel Xeon Gold 5416S 16 32 2.0 GHz
Memory (DIMMs) ------------------------------------------------------------ Slot Manufacturer Part Number Size Speed Type ------------------------------------------------------------- A1 Samsung M393A4G43BB4-CWE 32 GB 4800 MHz DDR5 A2 Samsung M393A4G43BB4-CWE 32 GB 4800 MHz DDR5 B1 Samsung M393A4G43BB4-CWE 32 GB 4800 MHz DDR5 B2 Samsung M393A4G43BB4-CWE 32 GB 4800 MHz DDR5
Total Installed Memory: 128 GB
Storage ------------------------------------------------------------ Slot Manufacturer Model Capacity Type Firmware --------------------------------------------------------- 0 Samsung PM9A3 1920 GB NVMe SSD GXA7602Q 1 Samsung PM9A3 1920 GB NVMe SSD GXA7602Q
Network Adapters ------------------------------------------------------------ Slot Manufacturer Model Speed Ports -------------------------------------------------- Integrated Broadcom BCM57416 25GbE 2
Power Supplies ------------------------------------------------------------ Slot Model Max Watts Firmware -------------------------------------------- 1 Dell DPS-1100FB 1100 W 00.1D.6C 2 Dell DPS-1100FB 1100 W 00.1D.6C hint: One word, no flags: hwinventory
Read it like an auditor. Two sockets of Intel Xeon Gold 5416S, 16 cores and 32 threads each. Four DIMM slots filled with 32 GB Samsung DDR5-4800 modules, 128 GB total. Two 1.92 TB Samsung PM9A3 NVMe drives on the same firmware. A dual-port 25GbE Broadcom adapter. Two 1100 W power supplies, so the box survives losing one. That is the whole machine, read off the parts, with no OS anywhere in the story.
A readout on your screen dies at shift change. Asset management wants files. So how do you get a BMC shell's output into a file on your workstation?
This BMC's shell reads its commands from standard input, the stream of text flowing into a program. That means you can feed it a command through a pipe instead of typing it interactively, and catch everything it prints with a redirect. The pattern:
echo hwinventory | sshpass -p ADMIN ssh -o StrictHostKeyChecking=no admin@$BMC_IP > ~/hw-audit.txtecho writes the word hwinventory to its output, the pipe | feeds that into the SSH session as if you had typed it at the prompt, and > sends the whole session transcript into the file. One line, no interactive shell, done.
The shorter form ssh admin@$BMC_IP hwinventory, with the command as an SSH argument, works here too, exactly like a production iDRAC. The shell runs that one command and returns just its output, no banner, no prompts. So why learn the pipe? The pipe form captures the whole session transcript, banner and prompts included, and an intake audit file wants exactly that: the readout plus proof of where it came from. Use the argument form for a quick look; use the pipe-and-redirect form when the paperwork needs the full picture.
Watch it work with the shorter firmware readout, version, first without the redirect so you can see exactly what would land in the file:
ops@dc-east-ws01:~$ echo version | sshpass -p ADMIN ssh -o StrictHostKeyChecking=no admin@$BMC_IP
Pseudo-terminal will not be allocated because stdin is not a terminal.
Dell Remote Access Controller 9
Firmware Version: 6.10.30.00
Last login: Wed Jul 01 08:52:11 2026
Type 'help' for a list of available commands.
/admin1->
Firmware Version Information
============================================================
BMC Firmware: 6.10.30.00
BIOS Version: 1.9.1
CPLD Version: 1.0.6
Backplane FW: 3.52
PSU1 FW: 00.1D.6C
PSU2 FW: 00.1D.6C
/admin1->
Disconnecting...That Pseudo-terminal line at the top is SSH being chatty on standard error, a separate stream from the output you are capturing. It shows on your screen, but a > redirect only captures standard output, so the warning never lands in your audit file.
That version table is a component firmware audit in one shot: the BMC, the BIOS, the CPLD (complex programmable logic device, the small chip that sequences power and signals on the system board), the drive backplane, and both power supplies. Add > ~/firmware-audit.txt to the end and it is on file.
>>> The whole transcript. The redirect captures everything the remote shell printed: banner, prompts, table, disconnect line. And that is fine. Audit files are searched, not framed; a grep CPLD ~/firmware-audit.txt finds the line it needs no matter what surrounds it.
hwinventory is a Dell-style command. Walk one row over to an HPE or Supermicro rack and that shell, that syntax, that banner are all gone. What survives is the standard: IPMI, and its FRU inventory command works against any vendor's BMC. Run it from your workstation, no SSH session anywhere in this one:
prompt: ops@dc-east-ws01:~$ answer: ipmitool -I lanplus -C 3 -H $BMC_IP -U ADMIN -P ADMIN fru print output: FRU Device Description : Builtin FRU Device (ID 0) Chassis Type : Rack Mount Chassis Chassis Part Number : 0CNCJWA08 Chassis Serial : SVC1234567 Board Mfg Date : Unspecified Board Mfg : Dell Inc. Board Product : PowerEdge R750xs Board Serial : CN7792215B0031 Board Part Number : 0PPYFVA03 Product Manufacturer : Dell Inc. Product Name : PowerEdge R750xs Product Version : 1.9.1 Product Serial : SVC1234567
SDRR successfully erased Err in cmd get sensor sdr info Get SDR 0000 command failed: Requested sensor, data, or record not found Get SDR 0000 command failed: Requested sensor, data, or record not found Get SDR 0000 command failed: Requested sensor, data, or record not found Get SDR 0000 command failed: Requested sensor, data, or record not found Get SDR 0000 command failed: Requested sensor, data, or record not found hint: Same flags you have used since WO-1001 (-I lanplus -C 3, then host, user, password), and the subcommand is: fru print
Same flags since WO-1001: -I lanplus for the IPMI 2.0 network interface, -C 3 for the cipher suite, then host and credentials. The subcommand fru print asks the BMC to read its FRU EEPROM and decode the standard areas stored on it: a Chassis area (enclosure type, part number, serial), a Board area (who made the system board, its serial and part number), and a Product area (the name, version, and serial the whole system ships under). Those serials and part numbers are exactly what a warranty claim asks for.
Read the reply like an auditor. The service tag appears twice more, as the chassis serial and the product serial: one identity, every lens. The board carries its own serial and part number, read off the chip on the board itself. And the board mfg date reads Unspecified on this box; production Dell iron stamps the factory build date there.
A physical server usually exposes several FRU devices, because PSUs and backplanes carry EEPROMs of their own. That is what the noisy tail of the readout is about: after printing the builtin device, ID 0, ipmitool goes hunting for records of extra FRU devices in the BMC's sensor data repository. This BMC keeps that repository empty, so the hunt comes back with a few Get SDR complaints and gives up. Nothing failed: every record you came for printed in full, above the noise. Ops tools are chatty, and reading past harmless noise without flinching is part of the job.
{ "height": 400, "caption": "Three doors, one set of chips. Flip the fleet view.", "nodes": [ { "id": "you", "label": "You (dc-east-ws01)", "kind": "admin", "x": 0, "y": 190, "detail": "Same workstation, three protocols into the same controller." }, { "id": "sshdoor", "label": "SSH :22", "kind": "net", "x": 300, "y": 40, "detail": "The Dell-style shell. Richest tables (hwinventory, getsysinfo), but the syntax only exists on Dells." }, { "id": "ipmidoor", "label": "IPMI :623/udp", "kind": "net", "x": 300, "y": 190, "detail": "The universal standard. fru print speaks the same wire protocol on any vendor's BMC." }, { "id": "rfdoor", "label": "HTTPS Redfish", "kind": "net", "x": 300, "y": 340, "detail": "The modern JSON API over HTTPS. You will drive it in Module 3." }, { "id": "bmc", "label": "BMC", "kind": "bmc", "x": 620, "y": 190, "detail": "One controller answers all three doors." }, { "id": "chips", "label": "Component EEPROMs", "kind": "sensor", "x": 900, "y": 190, "detail": "The FRU and SPD chips from earlier. Every door ends at the same silicon." } ], "edges": [ { "from": "you", "to": "sshdoor", "label": "hwinventory", "kind": "mgmt" }, { "from": "you", "to": "ipmidoor", "label": "fru print", "kind": "oob" }, { "from": "you", "to": "rfdoor", "label": "Module 3", "kind": "plain" }, { "from": "sshdoor", "to": "bmc", "kind": "mgmt" }, { "from": "ipmidoor", "to": "bmc", "kind": "oob" }, { "from": "rfdoor", "to": "bmc", "kind": "plain" }, { "from": "bmc", "to": "chips", "label": "one read, three answers", "kind": "mgmt" } ], "toggle": { "label": "Fleet view:", "on": "This Dell only", "off": "Any vendor (HPE, Supermicro...)", "dimOff": ["sshdoor", "e:you-sshdoor", "e:sshdoor-bmc"] } }
Flip the fleet view. The Dell shell door dims on every non-Dell rack in the building; the IPMI door stays lit on all of them. Vendor lenses are rich, standard lenses are portable, and a working auditor uses both.
The BMC here is a standards-faithful emulator: real IPMI 2.0 on the wire, a Dell-style shell over SSH, and the same commands you would type on physical iron. A production iDRAC returns far deeper inventory, including per-component serial numbers for every DIMM and drive.
>>> The IPMI one. fru print speaks the IPMI standard, and every server-class BMC on the floor implements it: Dell, HPE, Supermicro, all of them. The vendor shell is the part that changes under your feet. That is why the standard lens is the one fleets script against.
Last question: where does all this paperwork go, and why does anyone care?
Every serious facility runs a CMDB (Configuration Management Database), the master record of every asset it owns: what it is, where it sits, what parts are inside it, which serials. Your audit files feed it at intake. Capacity planning reads it to know how much memory the floor really has. Warranty tracking reads it the day a part dies.
{ "height": 340, "caption": "Why the paperwork exists. Flip the audit and watch the claim path.", "nodes": [ { "id": "bmc", "label": "Bay 14 BMC", "kind": "bmc", "x": 0, "y": 40, "detail": "The source of truth: serials and part numbers read straight off the hardware." }, { "id": "you", "label": "You (dc-east-ws01)", "kind": "admin", "x": 300, "y": 40, "detail": "Today's job: pull the records and file them." }, { "id": "cmdb", "label": "CMDB / asset database", "kind": "host", "x": 620, "y": 40, "detail": "Configuration Management Database. Capacity planning, warranty tracking, and incident response all feed from intake records." }, { "id": "dimm", "label": "DIMM B1, dead in month 6", "kind": "sensor", "x": 300, "y": 260, "detail": "Hardware fails on its own schedule. The only question is whether the paperwork is ready when it does." }, { "id": "claim", "label": "Warranty claim", "kind": "net", "x": 620, "y": 260, "detail": "Serial and part number on file: the RMA (return merchandise authorization) is a five-minute form. Nothing on file: a fight." } ], "edges": [ { "from": "bmc", "to": "you", "label": "inventory pulls", "kind": "oob" }, { "from": "you", "to": "cmdb", "label": "audit files filed", "kind": "mgmt" }, { "from": "cmdb", "to": "claim", "label": "serial + part number", "kind": "plain" }, { "from": "dimm", "to": "claim", "label": "RMA request", "kind": "plain" } ], "toggle": { "label": "Intake audit:", "on": "Filed at intake", "off": "Skipped", "dimOff": ["cmdb", "e:you-cmdb", "e:cmdb-claim"] } }
Flip the intake audit to Skipped and watch the claim path die with it. The DIMM does not care either way; it fails in month six on its own schedule. The only thing you control is whether the records are already waiting when it does. And the service tag is the key that joins them: one chassis serial that every file you produce today carries.
Time to do it for real. Work Order DC-EAST-WO-1003: full intake audit of the Bay 14 R750xs, from the BMC. The address is preset in $BMC_IP, credentials ADMIN / ADMIN.
Six objectives stand between this server and the production pool:
1. Raise the controller. Open the BMC's shell and pull its identity readout from inside. 2. Capture the inventory. Land the full hardware inventory in ~/hw-audit.txt. 3. Firmware on file. The component firmware audit goes to ~/firmware-audit.txt. 4. The standard lens. Pull the FRU records over the network, no SSH session. 5. File the FRU report. Ass
Practice Hardware Inventory in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.