Learn › BMC & Server Management › Boot Device Control
Final test: the whole Boot Device Control chapter. Read every boot option parameter and record which the firmware implements, capture seven refusals with standard error, learn what chassis bootdev writes from its own error, prove with a raw command and a sibling control that the refusal is the firmware, capture a real boot over the console and pull the option ROM banner and the boot decision out of it, file the genuine Dell boot flags decode, and write the procedure and the report. 25 objectives on a real workstation with a real IPMI 2.0 controller at 10.100.0.2.
This chapter covers the following topics:
chassis bootdev, and the two parameters it writesWhat you already know. Chapter 2 controlled host power and established that a command reply is not proof of a transition. Chapter 5 met completion codes 0xC1 and 0xCC and the discipline of capturing a refusal with 2>&1. Chapter 7 captured a boot over the console. This chapter uses all three to answer a question the equipment answers with a refusal.
Objectives. After this chapter you can:
chassis bootdev writes, and why its failure names two parametersThe machine. The controller in this chapter refuses several of the commands taught below, and that is the chapter rather than a defect. Every refusal quoted here was captured on the machine you will get. The host is powered and its firmware carries a network boot ROM, so the boot order this chapter is about is real and visible on the console. 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.
>>> Boot options are a numbered set of parameters read and written with Get and Set System Boot Options. Parameter 5, the boot flags, carries the valid bit, the persistence bit, the boot mode bit and the device selector. Section 8.1.
bootdev is a convenience command that writes both parameters, and the failure shows what it was doing>>> bootdev sets the boot info acknowledge in parameter 4 and the boot flags in parameter 5. Reading its error is how you learn what the convenience command actually does. Section 8.4.
-v and read the debug output>>> A controller completion code shows that a request received a protocol response. It does not prove that the request bytes, target or privilege were appropriate. A successful sibling checks only that operation in its context. Section 8.5.
>>> Persistence retains an override request until cleared. It is not proof that the permanent boot order was rewritten, nor that every platform stops at the option ROM. Verify the console outcome and the actual flags. Section 8.8.
>>> A refusal recorded with its completion code is a finding. A report that closes a request as done on equipment that cannot do it is worse than one that states the refusal, because somebody will rely on it. Section 8.9.
Goal: assess the requested one-time network boot without changing the saved normal boot order. Read the controller capability list first. The work order asks you to record whether the requested override can actually be verified.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 mc info output: Device ID : 0 Device Revision : 3 Firmware Revision : 1.05 IPMI Version : 2.0 Manufacturer ID : 0 Manufacturer Name : Unknown Product ID : 256 (0x0100) Product Name : Unknown (0x100) Device Available : yes Provides Device SDRs : yes Additional Device Support : Sensor Device SDR Repository Device SEL Device FRU Inventory Device IPMB Event Receiver Chassis Device Aux Firmware Rev Info : 0x00 0x00 0x00 0x00 hint: mc has an info subcommand.
Chassis Device is advertised in this capture. That supports investigating chassis operations, but does not promise every command or parameter is implemented. An absent or unexpected capability flag also needs platform documentation and a valid request, not a blanket conclusion.
A one-time override requests the next boot. Verify its application and later consumption or clearing on the actual platform; do not assume a failed PXE attempt has automatically restored the intended disk boot.
Check: keep the difference between an advertised class, a successful override request and an observed boot outcome.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis status output: System Power : on 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 hint: chassis has a status subcommand.
Eleven lines and not one of them is about boot. chassis status reports the power state, the fault flags, the restore policy and the intrusion switch. The boot options are a separate command family with their own parameters, and nothing in this block hints at them.
That is worth noticing before you go looking. On a controller where a boot override is not taking effect, this is not the place to check.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis power status output: Chassis Power is on hint: chassis power takes a status subcommand.
The host is on. Section 8.7 restarts it to watch the firmware choose a boot device, and a machine that is already off would give a power on rather than a reset, which is a different thing.
The single most useful fact in this chapter: the boot options are not one setting. They are a numbered set of parameters, read with Get System Boot Options and written with Set System Boot Options, and a controller may implement some and not others.
| Parameter | What it carries |
|---|---|
| 0 | Set In Progress, the lock used while a multi-parameter write is under way |
| 1 | Service Partition Selector |
| 2 | Service Partition Scan |
| 3 | BMC Boot Flag Valid Bit Clearing |
| 4 | Boot Info Acknowledge |
| 5 | Boot Flags: the valid bit, the persistence bit, the boot mode bit and the device selector |
| 6 | Boot Initiator Info |
| 7 | Boot Initiator Mailbox |
Parameter 5 is the one that matters. Everything a boot override does lives in its five data bytes.
chassis bootparam get takes a parameter number:
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis bootparam get 1 output: Boot parameter version: 1 Boot parameter 1 is valid/unlocked Boot parameter data: 00 Service Partition Selector : unspecified hint: chassis bootparam get takes the parameter number.
A real decode. Boot parameter 1 is valid/unlocked, the raw data byte, and ipmitool's reading of it: the service partition selector is unspecified.
This is the answer a parameter gives when the firmware implements it. Hold the shape in mind, because section 8.3 shows what the other answer looks like.
Objective 4 files this with > ~/boot/param1.txt 2>&1. The 2>&1 is habit here rather than necessity, and habit is the point: the same command against a different parameter needs it.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis bootparam get 4 output: Boot parameter version: 1 Boot parameter 4 is valid/unlocked Boot parameter data: Boot Info Acknowledge :
hint: The same command with the parameter number for the boot info acknowledge.
Also implemented, and worth reading rather than skipping.
Boot Info Acknowledge is how the firmware and the operating system tell the controller they have seen a boot override. Each line is a party that has acknowledged: the operating system or service partition, the OS loader, and BIOS/POST.
It exists because a boot override is consumed rather than applied. The controller sets the flags, the firmware reads them at the next start, and the acknowledge is how the controller learns they were read. When an override appears ineffective, this parameter is one clue. Its interpretation depends on the platform's acknowledgement and clearing rules; corroborate it with the boot flags and console rather than treating missing acknowledgement as proof of one failed component.
Goal: compare a second parameter read with the earlier successful reads. The title describes this lab's limitation; the response still needs precise interpretation.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis bootparam get 0 output: Get Chassis Boot Parameter 0 failed: Invalid data field in request hint: The same command with parameter number 0.
The response reports 0xCC, Invalid data field in request. It does not name the offending field. Keep the exact request and compare it with platform documentation and controlled reads before concluding which capability is missing.
Check: do not save this as a successful parameter capture. The next step tests parameter 5, which matters for the requested override.
Goal: read the flags that carry an IPMI boot-device override. Parameter 5 is the important read before attempting this change.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis bootparam get 5 output: Get Chassis Boot Parameter 5 failed: Invalid data field in request hint: The same command with the parameter number for the boot flags.
The controller returned Invalid data field in request. The requested flags were not read successfully, so we do not yet have evidence that an override can be set or verified.
The response alone does not identify the rejected field or prove the entire feature is absent. Check the request format, platform support and interface context. The following controlled reads and writes document this lab's limitation.
Check: keep this error as a result, not as a successful boot-flags capture. Do not restart the host expecting PXE from this failed read.
A refusal is written to standard error, which a plain > does not capture. Objective 7 is that refusal in a file, and without 2>&1 the file closes empty:
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis bootparam get 5 > ~/boot/param5.txt 2>&1 output: hint: The same command redirected into the file with standard error captured by 2>&1.
The file holds:
Get Chassis Boot Parameter 5 failed: Invalid data field in requestSeven of this lab's twenty-five objectives are refusals, and every one of them needs the redirect. A file that closes empty is the single most common way to lose an objective here, and it is also how a real finding gets lost from a real report.
Two parameters answer and one does not, so far. The useful question is which of the eight this firmware has, and a loop answers it in one command. for p in 0 1 2 3 4 5 6 7; do ...; done runs the body once per value, and head -4 keeps each answer short:
prompt: ops@mgmt:~$ answer: for p in 0 1 2 3 4 5 6 7; do printf '## parameter %s\n' $p; ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis bootparam get $p 2>&1 | head -4; done output:
Get Chassis Boot Parameter 0 failed: Invalid data field in request
Boot parameter version: 1 Boot parameter 1 is valid/unlocked Boot parameter data: 00 Service Partition Selector : unspecified
Get Chassis Boot Parameter 2 failed: Invalid data field in request
Get Chassis Boot Parameter 3 failed: Invalid data field in request
Boot parameter version: 1 Boot parameter 4 is valid/unlocked Boot parameter data: Boot Info Acknowledge :
Get Chassis Boot Parameter 5 failed: Invalid data field in request
Get Chassis Boot Parameter 6 failed: Invalid data field in request
Get Chassis Boot Parameter 7 failed: Invalid data field in request hint: A for loop over the eight parameter numbers, each read piped into head, with a printf label in front of each.
Two of eight. Parameters 1 and 4 answer; 0, 2, 3, 5, 6 and 7 all refuse with the same completion code.
A sweep like this is worth running on any controller before you rely on a capability, and it is three lines of shell. The alternative is discovering the gap during a maintenance window.
Note that 2>&1 sits inside the loop, on the command whose error you want. Objective 8 redirects the whole loop as well, which is the outer > ~/boot/sweep.txt 2>&1 after done.
chassis bootdev is what an operator actually types. It takes a target name rather than five data bytes, and it is the command the change request would be carried out with.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis bootdev pxe output: Set Chassis Boot Parameter 4 failed: Invalid data field in request Set Chassis Boot Parameter 5 failed: Invalid data field in request hint: chassis has a bootdev subcommand, taking the target name.
Two errors from one command, and together they teach what the convenience command is doing.
Set Chassis Boot Parameter 4 failed and Set Chassis Boot Parameter 5 failed. bootdev writes two parameters: the boot info acknowledge, so the controller can tell when the override is picked up, and the boot flags, which carry the override itself.
This is the value of reading an error rather than skipping to the next idea. Nothing in the ipmitool manual page for bootdev says it writes parameters 4 and 5; the failure does.
Goal: compare a second target while keeping the rest of the request consistent.
prompt: ops@mgmt:~$ answer: ipmitool -I lanplus -H 10.100.0.2 -U ADMIN -P ADMIN -C 3 chassis bootdev disk output: Set Chassis Boot Parameter 4 failed: Invalid data field in request Set Chassis Boot Parameter 5 failed: Invalid data field in request hint: The same command with a different target.
Both tested targets returned failures naming parameters 4 and 5. That establishes two refused requests, not that every possible target or option must fail. The response does not identify the exact invalid field.
Check: record both requests and their results, then consult the supported platform procedure before further writes. A successful read elsewhere is not proof a boot override can be written.
Goal: understand what the convenience command attempted. The errors name parameter 4 and parameter 5; do not turn either error into a successful write.
prompt: ops@mgmt:~$ answer: printf '%s\n' 'chassis bootdev attempts parameter 4, boot info acknowledge, and parameter 5, boot flags.' 'Parameter 5 carries the valid, persistence, boot mode and boot device fields.' 'The recorded lab requests failed. Reading parameter 4 successfully does not prove writing it succeeds; multiple failed targets do not prove every possible request is unsupported.' > ~/boot/bootdev-note.txt output: hint: Write the short evidence note with printf, then read it with cat ~/boot/bootdev-note.txt.
Your file should record these statements:
Practice Boot Device Control in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.