Repository navigation
Model BMC capabilities as firmware-derived facts + OS-install mechanism as a dependency solve (§2/§3/§4) - #5748
Closed
gunbai-bot[bot] wants to merge 3 commits into
Closed
gunbai-bot[bot] wants to merge 3 commits into
gunbai-bot[bot] wants to merge 3 commits into
Conversation
…as a dependency solve (§2/§3/§4)
Operator directive: don't hard-code a firmware flash — model the board/BMC's
capabilities and let the OS-install mechanism fall out of a dependency solve.
- extdeps/bmc/capability.dag (new, DMTF Redfish anchor): BmcCapability
{PowerControl|BootSourceOverride|AccountManagement|FirmwareUpdate|VirtualMedia
|BiosAttributeConfig} + BmcFirmwareVersion{family,version} + a
BmcFirmwareCapabilityRow catalog. A capability is the PRESENCE of its Redfish
resource/action, derived from (family, version) — NOT a board property. The
one grounded row is openbmc_2_07_00_capabilities, from a live Redfish probe of
srv3's BMC (192.168.1.192) on 2026-06-24: has Power/BootOverride/Account/
UpdateService; lacks VirtualMedia (404) and BIOS attribute config (empty
Attributes, /Bios/Settings 404).
- §3 dissolution: deleted the bare RedfishVirtualMediaSupport flag
(VirtualMediaSupported|VirtualMediaUnsupported) and the board-level
asrock_altrad8ud_virtual_media_support — a fork that modeled VirtualMedia as a
property of the BOARD when it is a property of the FIRMWARE VERSION. Now it's
membership: CapabilityVirtualMedia ∈ the firmware's capability row. Only
consumers were asrock_rack.dag + one witness, both repointed.
- gunbc/os_install_mechanism.dag (new): OsInstallMechanism
{VirtualMediaInstall | PxeHttpInstall | FirmwareUpdateThenVirtualMedia} +
solve_install_mechanism. VirtualMediaInstall is preferred (out-of-band Redfish,
no PXE/proxyDHCP/same-L2/BIOS-edit, Tailscale-agnostic); FirmwareUpdateThen-
VirtualMedia when VM absent but UpdateService present AND the catalog knows a
VM-capable firmware (firmware update = a capability-acquiring transition, §4
solve-from-inhabitance); PxeHttpInstall only as the fallback that drags in the
two physical preconditions PXE can't escape (BIOS network stack + same-L2).
srv3_install_mechanism solves to PxeHttpInstall TODAY because the catalog has no
VM-capable firmware yet — add one grounded row and it flips to
FirmwareUpdateThenVirtualMedia with no edit here.
Witnesses (green by execution): srv3 capabilities grounded; catalog has no
VM-capable firmware today; srv3 solves to PXE today; a VM-capable firmware flips
srv3 to the firmware-update path; a node WITH VirtualMedia solves direct.
Note: BmcFirmwareVersion lives in extdeps (capabilities are a Redfish-realization
concept) referencing std.bmc.BmcFirmwareFamily — std.bmc untouched. The
VirtualMedia-capable firmware row is the single operator-pending fact (which
ALTRAD8UD-1L2T OpenBmc build exposes VirtualMedia); adding it activates the clean
install path fleet-wide.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…Redfish VirtualMedia (cited row) + WebUI-vs-Redfish nuance Operator researched the firmware→capability question and found the decisive fact: NO ASRockRack ALTRAD8UD-1L2T OpenBmc firmware exposes VirtualMedia or BIOS attributes over Redfish — not the installed 2.07.00, not the latest 03.22.00 (released 2026-04-14). The OEM hasn't wired nbd-proxy/jsnbd (VirtualMedia) or MCTP/PLDM (BIOS attrs) into the Redfish schema; 03.22.00's changes are first-login password enforcement + sensor/security patches (CVE-2024-54085), not Redfish feature parity. - Added openbmc_03_22_00_capabilities as a CITED row (provenance marks it cited-not-live-probed, since srv3 runs 2.07.00) — so the catalog now records that the capability is unflipped across the installed AND latest firmware. The solve provably stays PxeHttpInstall on this board; FirmwareUpdateThenVirtualMedia is sound-but-uninhabited for this firmware line (still valid for boards whose OEM wired Redfish VM — model is board-agnostic). - openbmc_redfish_vs_webui_virtual_media_doc: CapabilityVirtualMedia models the REDFISH (automatable) surface, NOT whether the feature exists — VM is available via the legacy WebUI KVM but is 404 over Redfish, and BIOS config is reachable only via host UEFI or MgmtTool IPMI-OEM. A node having WebUI virtual media does NOT make CapabilityVirtualMedia true. - os_install_mechanism doc records the honest consequence: srv3's automatable remote install today is PXE (BIOS net-stack enabled out-of-band once + same-L2) or the manual WebUI-KVM attach. Witnesses green by execution (catalog_has_no_vm_capable_firmware_today now stronger — holds across both the installed and latest firmware rows). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…d entries (01.13.00/02.07.00/03.22.00) with official dates + release notes, modeling confirms NO Redfish VirtualMedia across the whole line Each maintained BMC firmware entry is now a grounded row with its official release_date + release_summary from the ASRockRack download catalog (the authority for version identity). The full history (first 01.13.00 -> installed 02.07.00 -> latest 03.22.00) carries the same capability set with NO VirtualMedia / NO BIOS-attribute Redfish support -- the catalog_has_no_vm_ capable_firmware_today witness confirms it by execution across every entry, so srv3 correctly solves to PxeHttpInstall. Adds two docs: bmc_manual_is_generic_ceiling_doc (the OpenBMC manual documents Redfish VirtualMedia generically -- a capability CEILING, not a per-firmware fact; the live probe 404 is ground truth, §5 spec-vs-shipped) and bmc_version_string_doc (catalog labels builds 02.07.00 with leading zero; Redfish FirmwareInventory reports 2.07.00 stripped). Witnesses green by execution: srv3_firmware_capabilities_are_grounded, catalog_has_no_vm_capable_firmware_today, srv3_today_solves_to_pxe, vm_capable_firmware_flips_srv3_to_firmware_update_path, node_with_virtual_media_solves_direct (synthetic VM fixture updated for the enriched row shape). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
Author
|
Closing to rework. This PR carries prose documentation dumped into |
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Jun 24, 2026
…s Disposition Two closed PRs re-landed with documentation moved to PR/commit body: PR #5748 (BMC capability solve + firmware catalog): - extdeps/bmc/capability.dag: BmcCapability coproduct + BmcFirmwareCapabilityRow catalog grounded from live Redfish probe + ASRockRack release notes. §3 dissolution: VirtualMedia is a firmware-version capability (membership in this catalog), not a board property (the prior RedfishVirtualMediaSupport flag). - extdeps/bmc/types.dag: removed RedfishVirtualMediaSupport (dissolved upstream). - extdeps/boards/asrock_rack.dag: removed asrock_altrad8ud_virtual_media_support and its import; firmware catalog is the single authority. - gunbc/os_install_mechanism.dag: OsInstallMechanism coproduct + solve_install_mechanism derives mechanism from firmware capabilities (§4 inhabitance-solve); srv3 today solves to PxeHttpInstall (no VirtualMedia row for this firmware line). - test/claim/bmc_capability_solve_witness_test.dag: 5 witnesses grounding the solve (srv3 capabilities; catalog has no VM firmware; srv3→PXE; VM-firmware flips to FirmwareUpdateThenVirtualMedia; node with VM solves direct). - test/claim/srv3_os_install_witness_test.dag: replaced board-level VirtualMedia match with firmware_exposes check against openbmc_2_07_00_capabilities. PR #5750 (srv3 boot-once-cd entrypoint): - gunbc/srv3_boot_once_cd.dag: srv3_boot_once_cd() func — stage netrc + PATCH BootSourceOverride(Cd/Once) + POST ComputerSystem.Reset(ForceRestart). Fail-closed: any stage returns exit_failure. Reuses boot_override_body/reset_body from gunbc.tools.bmc_onboard (named os-install consumer of bmc_redfish_json_concat_debt). srv3_boot_secret_on_disk_debt promoted from String to Disposition = Scaffold { dissolves_to: RealizationDispatch, bind: extdeps.filesystem.filesystem_io.Filesystem } matching the pattern in bmc_onboard. - test/claim/srv3_boot_once_cd_witness_test.dag: 3 pure wire-shape witnesses (Cd/Once override body; ForceRestart reset body; netrc path staged). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This was referenced Jun 24, 2026
briansrls
added a commit
that referenced
this pull request
Jun 24, 2026
…srv3 boot-once-CD (structured Disposition) (#5765) * WIP: Re-land #5748 (BMC firmware capability catalog) + #5750 (srv3 boot-once- * Fix parse errors: remove let-binding type annotation + move == onto same expression line Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Brian Searls <briansearls1@gmail.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Executes the operator's directive: don't hard-code a firmware flash — model the board/BMC's capabilities and let the OS-install mechanism fall out of a dependency solve. This grew directly out of the live srv3 onboarding: PXE failed because this BMC's firmware exposes no remote way to enable the BIOS network stack, and Virtual Media (the clean primitive) is absent on its firmware — which is precisely a capability fact that belongs modeled, not improvised.
What
extdeps/bmc/capability.dag(new, DMTF Redfish anchor):BmcCapability={PowerControl | BootSourceOverride | AccountManagement | FirmwareUpdate | VirtualMedia | BiosAttributeConfig},BmcFirmwareVersion{family, version}, and aBmcFirmwareCapabilityRowcatalog. A capability is the presence of its Redfish resource/action, derived from(family, version)— not a board property. The one grounded row,openbmc_2_07_00_capabilities, comes from a live Redfish probe of srv3's BMC (192.168.1.192) on 2026-06-24: has Power / BootOverride / AccountService / UpdateService; lacks VirtualMedia (404) and BIOS attribute config (emptyAttributes,/Bios/Settings404).RedfishVirtualMediaSupportflag and the board-levelasrock_altrad8ud_virtual_media_support— a fork that modeled VirtualMedia as a property of the board when it is a property of the firmware version. Now it's membership:CapabilityVirtualMedia ∈the firmware's row. Only consumers wereasrock_rack.dag+ one witness, both repointed.gunbc/os_install_mechanism.dag(new):OsInstallMechanism = {VirtualMediaInstall | PxeHttpInstall | FirmwareUpdateThenVirtualMedia}+solve_install_mechanism. VirtualMediaInstall is preferred (out-of-band Redfish — no PXE, no proxyDHCP, no same-L2, no BIOS edit, Tailscale-agnostic). When VM is absent butUpdateServiceis present and the catalog knows a VM-capable firmware, the solve yieldsFirmwareUpdateThenVirtualMedia— firmware update as a capability-acquiring transition (§4 solve-from-inhabitance).PxeHttpInstallis only the fallback that drags in the two physical preconditions PXE can't escape (BIOS network stack on + same L2 broadcast domain).The solve in action (witnesses, green by execution)
srv3_install_mechanismsolves toPxeHttpInstalltoday because the catalog has no VM-capable firmware row yet. Add one grounded row → srv3 flips toFirmwareUpdateThenVirtualMediawith no edit to the solve. That row is the single operator-pending fact (which ALTRAD8UD-1L2T OpenBmc build exposes VirtualMedia); adding it activates the clean, Tailscale-proof install path fleet-wide. Witnesses cover: srv3 capabilities grounded; catalog has no VM-capable firmware today; srv3 → PXE today; a VM-capable firmware flips srv3 to the firmware-update path; a node with VirtualMedia solves direct.Notes for review
BmcFirmwareVersionlives in extdeps (capabilities are a Redfish-realization concept) referencingstd.bmc.BmcFirmwareFamily— std.bmc untouched.RedfishSystemActions there. No conflict.🤖 Generated with Claude Code