patch(v2.0): converge host boot interface configuration for NIC-mode ingestion#4012
Conversation
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)
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
🔐 TruffleHog Secret Scan✅ No secrets or credentials found! Your code has been scanned for 700+ types of secrets and credentials. All clear! 🎉 🕐 Last updated: 2026-07-23 19:02:38 UTC | Commit: 6ad9361 |
🔍 Container Scan Summary
Per-CVE detail lives in the per-service |
Important
This PR cherry-picks the host boot-interface configuration convergence arc into
release/v2.0, in merge order:78aa3766a) -- skip the SetBootOrder re-apply when the boot config is already set064ce21bc) -- apply SetBootOrder boot config once per reboot428135d4f) -- resolve the boot NIC through one shared stepa2ab63f2c) -- ensure a correct boot config during machine validation9d80c7fcd) -- generalized convergence for host boot interface configurationRelated issues
This supports #2821 (nvbug 6430706).
Type of Change
Breaking Changes
Testing
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 inrelease/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.crates/machine-controller/Cargo.toml[dev-dependencies]): resolved tocarbide-redfish+carbide-test-harness+carbide-test-support, droppingcarbide-instrument-- that crate does not exist onrelease/v2.0and nothing in the picked code references it. All other commits applied cleanly.release/v2.0already pins v0.44.21 (mainis at v0.44.22).