Repository navigation
Conversation
The ASRock ALTRAD8UD's BMC-hosted netboot (gunbc.bmc_netboot_serve: the OpenBMC controller serves kernel/initrd/seed, the host's UEFI Shell fetches them over SOL) lived as a separate srv4-only flow beside the one delivery solver. It exists because the board's firmware PXE client needed a setup visit to enable (#7027), which is not remotely actuatable. It is now the seventh candidate of gunbc.boot_artifact_delivery, shaped exactly like UEFI HTTP: a target-bound BmcHostedShellBootStanding with five requirements of its own (controller shell, serve, SOL send, UEFI Shell, artifacts), a BmcHostedShellBoot delivery arm, and BootFromUefiShell as its boot-control target (Redfish BootSourceOverrideTarget UefiShell). It ranks last under the existing policy, so an established PXE path always wins. The frozen os_install_mechanism projection refuses it as outside the legacy mechanisms; it requires no site staging capability. No producer mints its Established arm yet: a frontier row in census_closure_frontier names the producer that dissolves it. Moving bmc_netboot_serve onto these params is that follow-up. srv13-srv16 (operator, 2026-10-07): four ASRock Altra hosts get HostIdentity and hostname allocation rows only. No address, BMC endpoint, MAC or hardware row is authored before first contact observes one. Executed locally with a fresh claim_batch: boot_artifact_delivery (34/34, new test bmc_hosted_shell_boot_is_selected_only_when_established_and_outranked_by_pxe), dissolution_census (5/5), network_boot_manifest_broker (23/23), hostname_allocation (7/7), runner_throughput_qualification (29/29), managed_host_unit_hold (17/17). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2eec5cb7e3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| OpenBmcConfigfsUsbGadget { params: _ } => BootFromRemovableMedia | ||
| UefiHttpBoot { params: _ } => BootFromUefiHttp | ||
| PxeChainBoot { evidence: _ } => BootFromNetworkPxe | ||
| BmcHostedShellBoot { params: _ } => BootFromUefiShell |
There was a problem hiding this comment.
When this arm is selected, the plan unconditionally requests BootFromUefiShell, but solve_bound_boot_artifact_delivery admits any route that provides generic boot control. The new witness exercises this with no_vm_profile, whose only route is IpmiLanplusRoute; the modeled IPMI and Redfish target vocabularies provide no UEFI-shell target. Consequently, an established shell standing can produce a plan whose boot-control action cannot be realized. Require route-specific evidence that the shell can be selected, or refuse this candidate.
Useful? React with 👍 / 👎.
| if same_boot_delivery_target(left: t, right: request.target) == false { | ||
| CandidateIneligible { cause: CandidateEvidenceForOtherTarget { evidence_target: t } } | ||
| } else { | ||
| staged_digest_standing(offered: p.artifact_digest, requested: request.artifact.digest) |
There was a problem hiding this comment.
For an IsoImage request, this compares the requested ISO digest with BmcHostedShellBootParams.artifact_digest, which is documented as the digest of the bootstrap served by the controller. The actual path in gunbc.bmc_netboot_shell_boot fetches vmlinuz and initrd from the BMC and then downloads the installation ISO from BmcNetbootServePlan.bulk_iso_url; that URL and its bytes are absent from this standing. A matching bootstrap digest can therefore make the candidate eligible while the kernel downloads an unrelated ISO, violating the plan's exact-artifact guarantee. Bind and verify the bulk ISO URI/digest as well, or restrict this delivery to an artifact format representing the served kernel/initrd bundle.
Useful? React with 👍 / 👎.
1 participant
The ASRock ALTRAD8UD's BMC-hosted netboot (gunbc.bmc_netboot_serve: the
OpenBMC controller serves kernel/initrd/seed, the host's UEFI Shell fetches
them over SOL) lived as a separate srv4-only flow beside the one delivery
solver. It exists because the board's firmware PXE client needed a setup
visit to enable (#7027), which is not remotely actuatable.
It is now the seventh candidate of gunbc.boot_artifact_delivery, shaped
exactly like UEFI HTTP: a target-bound BmcHostedShellBootStanding with five
requirements of its own (controller shell, serve, SOL send, UEFI Shell,
artifacts), a BmcHostedShellBoot delivery arm, and BootFromUefiShell as its
boot-control target (Redfish BootSourceOverrideTarget UefiShell). It ranks
last under the existing policy, so an established PXE path always wins.
The frozen os_install_mechanism projection refuses it as outside the legacy
mechanisms; it requires no site staging capability.
No producer mints its Established arm yet: a frontier row in
census_closure_frontier names the producer that dissolves it. Moving
bmc_netboot_serve onto these params is that follow-up.
srv13-srv16 (operator, 2026-10-07): four ASRock Altra hosts get HostIdentity
and hostname allocation rows only. No address, BMC endpoint, MAC or hardware
row is authored before first contact observes one.
Executed locally with a fresh claim_batch: boot_artifact_delivery (34/34,
new test bmc_hosted_shell_boot_is_selected_only_when_established_and_outranked_by_pxe),
dissolution_census (5/5), network_boot_manifest_broker (23/23),
hostname_allocation (7/7), runner_throughput_qualification (29/29),
managed_host_unit_hold (17/17).
🤖 Generated with Claude Code