Context
scripts/build-rootfs.sh was removed in #293 (see that issue for rationale). It had been kept as a "documented manual fallback" but had drifted into effectively dead code:
- It duplicated provisioning logic that now lives in
scripts/guest/guest-config.sh.
- It omitted the CI-kernel workarounds applied on the squashfs path (iptables-legacy, static
resolv.conf, Docker's DOCKER_INSECURE_NO_IPTABLES_RAW).
- It produced a finished ext4 image that the current
coop setup flow (download CI squashfs → unpack → guest-config.sh → pack ext4) does not consume.
- It shipped no kernel, so it couldn't actually unblock a user cut off from the Firecracker CI S3 bucket.
Today, image creation depends entirely on the Firecracker CI S3 bucket being reachable and publishing assets for a recent enough Firecracker minor. If that bucket is unavailable, there is no supported way to build a rootfs locally.
What we'd want
A genuine offline / from-scratch image-build path, if we decide it's worth supporting. Requirements that the old script did not meet:
- Reuse
scripts/guest/guest-config.sh (single source of provisioning truth) rather than duplicating package/tool installation.
- Apply the same CI-kernel workarounds, or document/provide a kernel where they aren't needed.
- Produce (or point
coop setup at) an artifact in the shape the current flow expects, end-to-end.
- Provide a kernel as well, since the rootfs alone can't boot.
Decision needed
Whether an offline build path is worth the maintenance cost at all, or whether relying on the CI S3 bucket (with the existing older-minor fallback) is sufficient. This issue tracks that decision and any follow-up implementation.
Context
scripts/build-rootfs.shwas removed in #293 (see that issue for rationale). It had been kept as a "documented manual fallback" but had drifted into effectively dead code:scripts/guest/guest-config.sh.resolv.conf, Docker'sDOCKER_INSECURE_NO_IPTABLES_RAW).coop setupflow (download CI squashfs → unpack →guest-config.sh→ pack ext4) does not consume.Today, image creation depends entirely on the Firecracker CI S3 bucket being reachable and publishing assets for a recent enough Firecracker minor. If that bucket is unavailable, there is no supported way to build a rootfs locally.
What we'd want
A genuine offline / from-scratch image-build path, if we decide it's worth supporting. Requirements that the old script did not meet:
scripts/guest/guest-config.sh(single source of provisioning truth) rather than duplicating package/tool installation.coop setupat) an artifact in the shape the current flow expects, end-to-end.Decision needed
Whether an offline build path is worth the maintenance cost at all, or whether relying on the CI S3 bucket (with the existing older-minor fallback) is sufficient. This issue tracks that decision and any follow-up implementation.