Repository navigation
Reserve a bootstrap data slot in the ISO: - #76
Merged
Merged
Conversation
jacobweinstock
force-pushed
the
bootstrap-slot
branch
from
October 12, 2026 16:53
d23b5e2 to
48d184f
Compare
There was a problem hiding this comment.
🟡 Changes recommended
Cache and collection paths can pair an ISO with missing, stale, or truncated layout metadata.
2 open findings
What changed in this PR
Adds a fixed bootstrap-data slot to CaptainOS ISOs for per-host Tinkerbell customization.
Changes:
- Adds and locates a 4 MiB CPIO bootstrap slot.
- Generates matching ISO layout metadata.
- Collects and publishes the ISO sidecar artifact.
| File | Description |
|---|---|
captain/iso.py |
Builds the slot and layout metadata. |
captain/flavor.py |
Registers the layout artifact. |
captain/cli/stages.py |
Includes the layout in cache checks. |
captain/artifacts.py |
Collects the layout alongside the ISO. |
.github/workflows/ci.yml |
Uploads the layout in CI. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Per-host data such as network configuration has to reach CaptainOS before its networking starts, and rebuilding an ISO per host or per change does not scale, nor fit the Tinkerbell model. Tinkerbell already personalizes the shared ISO while serving it, but only for kernel arguments, which are too small and awkward for structured or binary data. As the slot's exact location for each released ISO can differ between releases, architectures and flavors, a *.iso.layout.json is produced per ISO per flavor. This decouples Tinkerbell and CaptainOS releases and changing slot locations. Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
jacobweinstock
force-pushed
the
bootstrap-slot
branch
from
October 12, 2026 18:18
48d184f to
77cbb1c
Compare
Member
Author
|
@Mergifyio queue |
Contributor
Merge Queue Status🛑 Queue command has been cancelled |
The GitHub Action names didnt match. Also, dont run speculative checks because this causes a draft PR to be created and the full CI build to run. Signed-off-by: Jacob Weinstock <jakobweinstock@gmail.com>
Contributor
🛑 The queue request has been cancelled: new commits were pushedDetails@jacobweinstock pushed to this pull request after |
Contributor
Merge Protections🟢 Merge protection satisfied — ready to merge. Show 1 satisfied protection🟢 📃 Configuration Change RequirementsMergify configuration change
|
Member
Author
|
@Mergifyio queue |
Contributor
Merge Queue Status
Waiting for
All conditions
|
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.
Description
Per-host data such as network configuration has to reach CaptainOS before its networking starts, and rebuilding an ISO per host or per change does not scale, nor fit the Tinkerbell model. Tinkerbell already personalizes the shared ISO while serving it, but only for kernel arguments, which are too small and awkward for structured or binary data.
As the slot's exact location for each released ISO can differ between releases, architectures and flavors, a *.iso.layout.json is produced per ISO per flavor. This decouples Tinkerbell and CaptainOS releases and changing slot locations.
Fixes: #
How Has This Been Tested?
How are existing users impacted? What migration steps/scripts do we need?
Checklist:
I have: