Run the emulated SP fleet on the falcon host, once per rack - #48
Merged
Conversation
--emu replaces --emu-sp/--emu-rot/--wicket-setup, and launch defaults to the firmware the image was built from (zfs prop voxel:tuf-fw), with [sp] paths as the fallback for images built without --from-tuf. The TUF image build caches are gitignored.
Each sled gets the gimlet complement (2 M.2, 5 U.2) as propolis NvmeDisk devices on sparse host zvols under the deployment's dataset, so teardown reaps them and every launch starts on blank media. Disk identity rides in the NVMe serial; voxel-init discovers the disks with nvmeadm, writes the six-partition gimlet layout on the M.2s, seeds the boot image partition from the image's host phase 2, labels the U.2s, and names them all in sled-agent's config as real injected disks - omicron's SyntheticDisk path no longer runs anywhere. The install dataset preseed moves onto the M.2 ZfsPool slice. Also fixes stage_sp_emu reading hubris archives from its own output directory instead of the image firmware dir (a shadowed binding), which broke every --emu launch.
Launch stages the release's host phase 1 rom into the fleet dir and writes it into each gimlet SP's host-boot QSPI before the SP starts, so Hubris hashes real contents and Nexus identifies host phase 1 instead of reporting unknown (pairs with the sp-emu SHA-256 hash model). voxel-init also writes installinator's mupdate-override marker into every install dataset, so a fresh rack boots frozen in the post-MUPdate state and recovery-finish becomes the mandatory first operation, exactly as on a real rack (RFD 556).
The fleet moves out of the switch zones onto the host: a rack's SPs outlive the sled reboots they cause, and both switch zones share one flash instead of keeping private copies that drift. The in-zone fleet path is deleted; voxel sp ls and the faux-mgs verbs drive the host fleet; sp-sim stays disabled on emu racks built from source; the IPCC and SWD debug tooling targets the host-side processes. MPL headers on the new source files.
Real NVMe disks and recovery-state boot for upgrade compliance
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
1 participant
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.
Second in the flag-day stack, on top of #47. Includes the single-flag emulated-rack launch commit plus the SP-fleet-on-host commit.