Learn › BMC & Server Management › Field Replaceable Unit Inventory
Final test: the whole Field Replaceable Unit Inventory chapter. Walk a real multi-device FRU tree with fru print, read each device on its own, extract a serial the way an RMA form wants it, loop the device ids, read the FRU Device Locator records that make discovery possible, take the system GUID and its encoding warning, map the entities, prove presence with the sensors, capture the two identification commands this controller does not implement and tell them apart by their completion codes, file the genuine Dell R730 reference, and produce the corrected asset record. 25 objectives on a real workstation called mgmt with a real IPMI 2.0 controller at 10.100.0.2 whose FRU tree you audit for real.
This chapter covers the following topics:
What you already know. Chapter 1 ran fru print on a controller with a single device and extracted the board serial with awk. Chapter 4 read sdr elist and used the entity identifier to tell sensors apart. This chapter walks a tree of three devices, finds out how the controller advertises them, and reconciles what it reports against a written record.
Objectives. After this chapter you can:
awk and grep0xC1 from 0xCC and say what each one means for the next stepThe machine. The controller in this chapter carries three FRU devices: the board and two power supplies. The host is powered and the displayed sensors report in-band readings. Those observations do not certify the whole chassis as fault-free. Two of the commands taught below fail, and that is the chapter rather than a defect. Boot takes about 3 minutes. This chapter is free; the machine is yours for 60 minutes and stops itself after 20 minutes idle.
This chapter uses a real Linux workstation and software-emulated IPMI hardware. The protocol requests and replies are real; controller identity, sensor values and host behavior may be seeded or emulated. Supplied physical-hardware captures are labeled separately.
These five questions establish whether you need this chapter in full. Each explanation names the section that covers the point.
>>> The controller can read stored FRU identification without the host operating system, and an OS reinstall does not itself erase it. The data can still be incorrect or outdated. Corroborate disputed fields with part labels and maintenance evidence. Section 5.1.
fru print only reports device 0 unless a device number is given>>> A controller does not serve a list of its FRU devices. It publishes one locator record per device in the sensor data repository, and ipmitool walks those records to find them. A device with no locator is invisible to the walk even though the part is fitted and its memory is readable. Section 5.4.
>>> IPMI and SMBIOS store the same sixteen bytes and disagree about the order of the first three fields. A great many controllers copy the GUID straight out of SMBIOS, so ipmitool says so and prints it anyway. The value is correct; comparing it against a differently ordered copy is what goes wrong. Section 5.5.
Invalid command is a syntax error in ipmitool; Invalid data field comes from the controllerInvalid data field means the session lacks privilege for that command>>> For either response, retain the exact request and check target, context, arguments and platform support. The code alone does not establish every capability of the firmware. A privilege refusal is 0xD4, a third thing. Section 5.8.
>>> Neither source is automatically infallible. In this supplied lab, the documented replacement and controller reading identify the stale filed value. On physical hardware, corroborate the identity before changing the asset record. Section 5.10.
Your job: find what changed after a power-supply replacement, then correct the asset record. Work at ops@mgmt:~$, the management workstation. Commands shown below use this lab's BMC address and training account; type the command, not the prompt.
Follow one exercise at a time. The 25-item list in the terminal is the final inventory assessment, not a to-do list for this screen. A reading exercise says read now; a file-writing exercise names the file to create. check-progress reports assessment results, separately from the lesson's practice markers.
A field replaceable unit is a part that can be replaced during service, such as a board, power supply, backplane or riser. FRU inventory records store identification such as manufacturer, product, serial number and part number. The controller reports the records available to it; not every physical part necessarily has a separate record.
You can read these records without the host operating system, so an OS reinstall does not itself erase the inventory. That does not make the stored data infallible: FRU fields can be programmed incorrectly or changed. When sources disagree, compare the reported identity with the part label and maintenance evidence before correcting the asset record.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 fru print output: FRU Device Description : Builtin FRU Device (ID 0) Board Mfg Date : Unspecified Board Mfg : LinuxCam Board Product : node01 Board Serial : LC-00001 Board Part Number : BMC-v10
FRU Device Description : PS1 (ID 1) Board Mfg Date : Unspecified Board Mfg : LinuxCam Board Product : PSU-750W-A Board Serial : LC-PS01 Board Part Number : PWS-750-1R
FRU Device Description : PS2 (ID 2) Board Mfg Date : Unspecified Board Mfg : LinuxCam Board Product : PSU-750W-A Board Serial : LC-PS02 Board Part Number : PWS-750-1R hint: fru has a print subcommand.
Three devices, separated by blank lines.
Builtin FRU Device (ID 0) is the board the controller sits on. This lab exposes it at device 0, and Chapter 1 read it on a machine that had nothing else.
PS1 (ID 1) and PS2 (ID 2) are the two power supplies. Both are PSU-750W-A with part number PWS-750-1R, and their serial numbers differ: LC-PS01 and LC-PS02. Two identical parts distinguished only by serial number is the normal case in a chassis, and it is why the serial is the field an asset record keys on.
Board Mfg Date : Unspecified is blank on this controller. A populated field reports a manufacturing date; warranty eligibility still depends on vendor entitlement and purchase records.
The name in the description, PS1, is not decoration. Section 5.3 shows where it comes from.
fru print takes a device number and reads just that device. On a chassis with eleven devices this is the difference between an answer and a page.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 fru print 0 output: Board Mfg Date : Unspecified Board Mfg : LinuxCam Board Product : node01 Board Serial : LC-00001 Board Part Number : BMC-v10 hint: fru print takes the device number as its argument.
The same five lines as the first block of the tree, without the description header. Device 0 is the built-in FRU device in this lab; inspect the actual platform's inventory map.
At ops@mgmt:~$, read the first power supply. The inventory tree labelled PS1 as FRU device 1; the final argument selects that one record:
ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 fru print 1Board Product names the model, Board Part Number identifies the part type, and Board Serial identifies this particular unit. You will compare those fields with PS2 next.
Done when: the output describes PS1 only and you can identify its serial and part number. No file is required for this practice step. The assessment later asks for this reading in ~/inventory/ps1.txt.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 fru print 1 output: Board Mfg Date : Unspecified Board Mfg : LinuxCam Board Product : PSU-750W-A Board Serial : LC-PS01 Board Part Number : PWS-750-1R hint: The same command with the device number for PS1.
Serial LC-PS01, part number PWS-750-1R. This is the supply the filed asset record has right.
Your goal: tell the two power supplies apart.
The inventory tree labelled PS1 as device 1 and PS2 as device 2. The final argument to fru print selects the device. Keep the connection options and change that argument to 2.
Try it: at ops@mgmt:~$.
ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 fru print 2Read two fields: Board Part Number identifies the part type. Board Serial identifies this particular unit.
Check: compare those fields with PS1. Which stays the same, and which changes? This practice step only reads the record. You will save it as ~/inventory/ps2.txt in the assessment.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 fru print 2 output: Board Mfg Date : Unspecified Board Mfg : LinuxCam Board Product : PSU-750W-A Board Serial : LC-PS02 Board Part Number : PWS-750-1R hint: The same command with the device number for PS2.
PS2 reports serial LC-PS02. PS1 reported LC-PS01. Both report part number PWS-750-1R.
That is the distinction: same part type, different physical units. A matching part number does not mean the same power supply was reinstalled.
The filed asset record lists PS2 as LC-PS00. Keep the observed serial LC-PS02; section 5.10 uses it to reconcile the record. Identity alone does not establish whether the supply is healthy.
Next: extract one identifier from the labelled output, so you can save the value you actually need.
An asset system wants a value, not a block of labelled text. awk -F': ' splits each line on a colon and a space, and {print $2} prints what follows it on the matching line.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 fru print 0 | awk -F': ' '/Board Serial/{print $2}' > ~/inventory/asset-tag.txt output: hint: Pipe the single-device read into awk with the field separator set to colon-space, matching the Board Serial line and printing field 2, then redirect.
The file holds one line:
LC-00001Note that the command reads fru print 0 rather than the whole tree. Running the same awk against the full tree would return three serials, one per device, which is a different answer to a different question.
When the question is about every device, run the pattern against the whole tree. grep -i matches case-insensitively and keeps the whole line:
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 fru print | grep -i 'Board Part Number' > ~/inventory/part-numbers.txt output: hint: Pipe the whole tree into a case-insensitive grep for the part number line and redirect.
The file holds:
Board Part Number : BMC-v10
Board Part Number : PWS-750-1R
Board Part Number : PWS-750-1RThree lines, one per device, in device order. The two supplies share a part number, which is what identical parts look like, and the label is kept because the question was "what part numbers are in this machine" rather than "what is device 1's part number".
When the question is about some devices and not all of them, a shell loop runs the same command per device. for id in 1 2; do ...; done runs the body twice with $id set to each value, and the redirection outside the loop collects both:
prompt: ops@mgmt:~$ answer: for id in 1 2; do ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 fru print $id | grep -i 'Board Serial'; done > ~/inventory/psu-serials.txt output: hint: A for loop over the two device numbers, each read piped into grep for the serial line, with the redirection placed after done.
The file holds:
Board Serial : LC-PS01
Board Serial : LC-PS02Two lines, the two supplies and nothing else. Redirecting after done sends the output of the whole loop into the file; putting the redirection inside the loop would overwrite the file on the second pass and leave one line.
Three approaches to one problem, and the choice is made by the question: fru print N | awk for one field of one device, fru print | grep for one field of everything, a loop for one field of a chosen set.
A question worth asking about section 5.1: how did fru print know there were three devices?
The controller does not serve a list. It publishes one FRU Device Locator record per device in its sensor data repository, and ipmitool walks that repository to discover them. sdr elist fru prints exactly those locator records.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 sdr elist fru output: PS1 | 00h | ns | 10.1 | Logical FRU @01h PS2 | 00h | ns | 10.2 | Logical FRU @02h hint: sdr elist takes a record type; ask it for fru.
Two records, for PS1 and PS2. The board at device 0 needs no locator, because device 0 is the builtin device every controller has by convention.
Read the columns. PS1 is the name, and it is where the description in fru print came from. 10.1 and 10.2 are the entity identifiers, which section 5.5 reads. Logical FRU @01h is the device number and how it is reached.
The state column reads ns, no state, because a locator record is not a sensor and has no reading.
The consequence of that design is the finding worth carrying out of this chapter, and objective 10 records it:
prompt: ops@mgmt:~$ answer: printf 'A FRU device is a chunk of non-volatile memory on a part, carrying the identity of that part: manufacturer, product, serial number, part number. One controller can hold many of them, numbered from 0. Device 0 is the builtin device, the board the controller itself sits on.\nFinding the rest is a separate step. The controller does not serve a list of its FRU devices. It publishes one FRU Device Locator record per device in its SDR repository, and ipmitool walks that repository to discover them. Each locator carries the device number, the access address, the entity the device belongs to, and the name printed beside it. sdr elist fru prints exactly those locator records, which is why PS1 and PS2 show up there as Logical FRU at 01h and 02h.\nThe consequence in practice: a FRU device with no locator record is invisible. fru print reads device 0 and stops, and the part sits in the machine with its serial number in memory that nothing ever asks for. When an inventory comes back thinner than the hardware you know is fitted, the locator records are the first thing to check.\n' > ~/inventory/device-map.txt output: hint: printf with three paragraphs separated by newline escapes, redirected into the file.
The file reads:
A FRU device is a chunk of non-volatile memory on a part, carrying the identity of that part: manufacturer, product, serial number, part number. One controller can hold many of them, numbered from 0. Device 0 is the builtin device, the board the controller itself sits on.
Finding the rest is a separate step. The controller does not serve a list of its FRU devices. It publishes one FRU Device Locator record per device in its SDR repository, and ipmitool walks that repository to discover them. Each locator carries the device number, the access address, the entity the device belongs to, and the name printed beside it. sdr elist fru prints exactly those locator records, which is why PS1 and PS2 show up there as Logical FRU at 01h and 02h.
The consequence in practice: a FRU device with no locator record is invisible. fru print reads device 0 and stops, and the part sits in the machine with its serial number in memory that nothing ever asks for. When an inventory comes back thinner than the hardware you know is fitted, the locator records are the first thing to check.The third paragraph is the operational point. Missing locator information is one possible reason an inventory walk omits a fitted part. Check device support, access and read errors too. The memory on that supply is still readable with fru print 3; nothing told the walk to look there.
This is why an inventory is checked against a count of what is physically installed at least once, rather than trusted on its own.
A GUID is a 128-bit identifier assigned to a system at manu
Practice Field Replaceable Unit Inventory in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.