Skip to content

patch(v2.0): converge host boot interface configuration for NIC-mode ingestion#4012

Merged
nv-dmendoza merged 5 commits into
NVIDIA:release/v2.0from
chet:cherry-pick-boot-config-v2.0
Jul 23, 2026
Merged

patch(v2.0): converge host boot interface configuration for NIC-mode ingestion#4012
nv-dmendoza merged 5 commits into
NVIDIA:release/v2.0from
chet:cherry-pick-boot-config-v2.0

Conversation

@chet

@chet chet commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Important

This PR cherry-picks the host boot-interface configuration convergence arc into release/v2.0, in merge order:

Related issues

This supports #2821 (nvbug 6430706).

Type of Change

  • Add - New feature or capability
  • Change - Changes in existing functionality
  • Fix - Bug fixes
  • Remove - Removed features or deprecated functionality
  • Internal - Internal changes (refactoring, tests, docs, etc.)

Breaking Changes

  • This PR contains breaking changes

Testing

  • Unit tests added/updated
  • Integration tests added/updated
  • Manual testing performed
  • No testing required (docs, internal refactor, etc.)

Additional Notes

Backports the boot-interface convergence follow-ups that a v2.0 NIC-mode host needs to clear PollingBiosSetup/BiosSetupFailed (nvbug 6430706 / #2821). The base fix -- #2950, re-assert the HTTP boot device during NIC-mode -- is already in release/v2.0; this arc is the refinement set that lands the boot config by interface ID when the Dell NDF MAC goes empty, and converges it across host init, assigned setup, DPU reprovision, and validation.

chet added 5 commits July 23, 2026 11:20
SetBootOrder re-applied a host's boot config on every pass -- re-asserting the
HTTP-boot device (`machine_setup`) and setting the boot order -- even when it was
already in place. It now checks first, and when the config is already set it goes
straight to verification instead of re-writing it: an already-configured host
skips a needless BIOS write and the reboot that applies it.

That re-apply also caused a stall. On Dell, two BIOS config writes can't share one
pending job, so re-asserting `machine_setup` (which commits a job) and then setting
the boot order in the same pass collided -- iDRAC rejects the second with `SYS011`
("a config job is already committed") -- and the flow looped there. Now the
re-assert runs only when the HTTP-boot device is actually reverted (the boot NIC
dropped off the BMC's Redfish inventory on a reboot), and reboots to apply it
before the boot-order set, so the two writes never share a pass.

- Already configured -- skip the re-assert and the boot-order set; verify and move on.
- HTTP-boot device reverted -- re-assert `machine_setup`, reboot to apply, then set the order.
- Boot order not yet set (device fine) -- set the order without re-asserting; no colliding job.

Tests updated!

This supports NVIDIA#3137

Signed-off-by: Chet Nichols III <chetn@nvidia.com>
(cherry picked from commit 78aa376)
When SetBootOrder finds the HTTP-boot device reverted (the boot NIC dropped
off the BMC's Redfish inventory on a reboot), it restores the device with
`machine_setup` and restarts the host to apply it. That restore now happens
once per revert: a new `WaitForHttpBootDeviceApplied` substate polls the
device across the reboot -- the same wait choreography the boot-order job
already has -- instead of the SetBootOrder pass re-writing the staged BIOS
settings and re-creating the config job on every pass until the reboot lands.

- While the reboot is in flight, the host waits in
  `WaitForHttpBootDeviceApplied`; once the device verifies, the flow returns
  to `SetBootOrder` to set the boot order.
- A device still reverted after the wait window (it can drop off again on the
  apply reboot itself) returns to `SetBootOrder` for a fresh restore, so
  re-applies stay bounded to one per window rather than one per pass.
- The restore path drops its two-way reboot branch for the unconditional
  restart the `RebootHost` substate already uses.

Tests updated!

This supports NVIDIA#3166

Signed-off-by: Chet Nichols III <chetn@nvidia.com>
(cherry picked from commit 064ce21)
Four Redfish boot steps -- the three boot-order substates (SetBootOrder,
WaitForHttpBootDeviceApplied, CheckBootOrder) and host boot repair -- each
opened with the same fifteen-line block resolving the host's boot NIC, with
only the wait message differing. The resolution step now lives in one helper,
`require_boot_interface`, and each caller states just the activity it's
blocked on: a zero-DPU host still discovering its boot NIC maps to the
caller's wait outcome, and a host with no resolvable interface stays a hard
error.

- One source of truth for the resolve-or-wait-or-fail choreography, so the
  boot steps can't drift apart as the state machine grows.
- Behavior-preserving: every caller keeps its exact wait message (the helper
  templates "before <activity>"), and wait-vs-error semantics are unchanged.
- Call sites shrink from fifteen lines to a handful each.

This supports NVIDIA#3193

Signed-off-by: Chet Nichols III <chetn@nvidia.com>
(cherry picked from commit 428135d)
…3369)

Machine validation now ensures the host's boot device config is what it
should be, and corrects it when it isn't. While waiting for the host to
boot
into the validation environment, validation verifies the boot config; if
it
reads reverted -- however it drifted, whether someone changed it
externally,
a BIOS quirk, or the boot NIC dropping off the BMC's inventory during
the
reboot's POST -- validation unlocks the BMC, re-drives the boot-order
flow
(re-assert the HTTP-boot device, reboot to apply, set and verify the
order),
re-locks, and resumes from its reboot step.

Without this, a drifted boot config was unrecoverable at this stage: the
host
can't boot into scout, more reboots can't restore a setting that is
gone, and
the BMC lockdown enabled earlier in HostInit blocks any fix -- so
validation
paced reboots indefinitely.

- Verification lives in the wait-for-reboot path: an intact config keeps
the
  normal reboot pacing; only a reverted one enters correction.
- The correction reuses the boot-order flow and the host-boot-repair
unlock/re-lock choreography, honoring the expected-machine lockdown
policy.
- New validation substates (PrepareBootRepair, UnlockForBootRepair,
  RepairBootConfig, LockAfterBootRepair) surface the correction in state
  history and metrics.

Tests updated!

This supports NVIDIA#3365

Signed-off-by: Chet Nichols III <chetn@nvidia.com>

Signed-off-by: Chet Nichols III <chetn@nvidia.com>
(cherry picked from commit a2ab63f)
…on (NVIDIA#3454)

Host boot configuration now runs through one controller path across host
initialization, assigned platform setup, DPU reprovision, and
validation. Each lifecycle keeps its own persisted state while sharing
BIOS setup, vendor jobs, polling, boot order, and final verification.

Primary callouts are:

- `host_boot_config` selects the smallest repair and advances the shared
flow without introducing a new serialized wrapper.
- Order-only drift skips `machine_setup`, while late BIOS drift returns
to the job-aware path and carries a bounded convergence budget.
- Dell job IDs stay persisted through reboot and recovery; validation
keeps its run identity and closes the run on terminal repair failure.
- Viking and legacy persisted states keep their safe recovery behavior.

Tests updated!

This supports NVIDIA#3391

Signed-off-by: Chet Nichols III <chetn@nvidia.com>
(cherry picked from commit 9d80c7f)
@chet
chet requested a review from a team July 23, 2026 18:49
@coderabbitai

coderabbitai Bot commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 3b452790-0cc4-4540-a0c9-430a84241561

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Comment @coderabbitai help to get the list of available commands.

@github-actions

Copy link
Copy Markdown

🔐 TruffleHog Secret Scan

No secrets or credentials found!

Your code has been scanned for 700+ types of secrets and credentials. All clear! 🎉

🔗 View scan details

🕐 Last updated: 2026-07-23 19:02:38 UTC | Commit: 6ad9361

@github-actions

github-actions Bot commented Jul 23, 2026

Copy link
Copy Markdown

🔍 Container Scan Summary

Service Total Critical High Medium Low Other
boot-artifacts-aarch64 3 0 0 3 0 0
boot-artifacts-x86_64 3 0 0 3 0 0
forge-admin-cli-x86_64 259 16 29 79 7 128
machine-validation-runner 547 41 117 191 17 181
machine_validation 547 41 117 191 17 181
machine_validation-aarch64 547 41 117 191 17 181
nvmetal-carbide 547 41 117 191 17 181
TOTAL 2453 180 497 849 75 852

Per-CVE detail lives in the per-service grype-* artifacts (JSON + SARIF). Severity counts only — no CVE IDs published here.

@nv-dmendoza
nv-dmendoza merged commit e64f063 into NVIDIA:release/v2.0 Jul 23, 2026
167 of 169 checks passed
@chet
chet deleted the cherry-pick-boot-config-v2.0 branch July 23, 2026 21:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants