fix(dell): match DPU HTTP boot option by name prefix, not exact equality

[kirson-git]

Problem

Dell::set_boot_order_dpu_first (src/dell.rs) builds the expected boot option name as
"HTTP Device 1: {DeviceDescription}" and compares it for exact equality against each
boot option's display_name:

if boot_option.display_name == expected_boot_option_name {

On Dell iDRAC the real boot option name has an adapter/MAC/protocol suffix appended, e.g.:

HTTP Device 1: NIC in Slot 40 Port 1 Partition 1 - Nvidia Network Adapter - C4:70:BD:2C:3C:0A - IPv4

So the exact == never matches, the loop falls through to
Err(RedfishError::MissingBootOption(..)), and the boot order is never set. Downstream
(NICo / infra-controller) this wedges the host-provisioning state machine at SetBootOrder
indefinitely.

Fix

Match by prefix — the constructed expected name is already a prefix of the real display_name:

if boot_option.display_name.starts_with(&expected_boot_option_name) {

The reorder action itself (PATCH Boot.BootOrder=[id]) is unchanged.

Testing / verification

Reproduced and verified on a live BlueField-3 + Dell PowerEdge XE9680 (iDRAC):

• Before: set_boot_order_dpu_first returned MissingBootOption("HTTP Device 1: NIC in Slot 40 Port 1 Partition 1") even though that boot option existed (Boot0000, with the suffix above) and was settable — confirmed by a manual PATCH .../Settings {"Boot":{"BootOrder":["Boot0000"]}} returning HTTP 200.
• After: the prefix match selects the correct boot option and sets it first; the host advances past SetBootOrder.

🤖 Generated with Claude Code

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[williampnvidia]

starts_with is too broad. For example, an expected Partition 1 can prefix-match Partition 10. Also this same in-line expression is used 3 times. I would use a matcher function like this:

fn boot_option_name_matches(expected: &str, actual: &str) -> bool {
    actual == expected
        || actual
            .strip_prefix(expected)
            .is_some_and(|suffix| suffix.starts_with(" - "))
}

[williampnvidia]

I would also add a unit test, something like this:

  #[test]
  fn boot_option_name_matches_legacy_and_extended_names() {
      let expected = "HTTP Device 1: NIC in Slot 4 Port 1 Partition 1";
      let cases = [
          (expected, true),
          (
              "HTTP Device 1: NIC in Slot 4 Port 1 Partition 1 - Nvidia Network Adapter - 00:11:22:33:44:55 - IPv4",
              true,
          ),
          (
              "HTTP Device 1: NIC in Slot 4 Port 1 Partition 10 - Nvidia Network Adapter - 00:11:22:33:44:55 - IPv4",
              false,
          ),
          (
              "HTTP Device 1: NIC in Slot 4 Port 2 Partition 1 - Nvidia Network Adapter - 00:11:22:33:44:55 - IPv4",
              false,
          ),
          (
              "HTTP Device 1: NIC in Slot 4 Port 1 Partition 1 unexpected suffix",
              false,
          ),
      ];

      for (actual, should_match) in cases {
          assert_eq!(
              boot_option_name_matches(expected, actual),
              should_match,
              "unexpected match result for {actual}"
          );
      }
  }

[williampnvidia]

Please replace the unrestricted prefix checks with the bounded boot_option_name_matches() helper discussed in the inline review, add the proposed regression test, and use the helper at all three modified call sites: machine_setup_status, set_boot_order_dpu_first, and is_boot_order_setup. This preserves support for both legacy and extended Dell boot-option names while preventing false matches such as Partition 1 matching Partition 10.

[williampnvidia]

This issue has been fixed with #102, I am closing this.