release 1.1.2v1.1.2

Also records the host config the chain depends on. The schedule and the
storage layout existed only on the VM, so a rebuilt host would have lost
both, and the README's inline copy of the schedule had already drifted
from what actually runs. crontab.example is byte-identical to the
deployed crontab; fstab.example carries the two-disk layout and the
dockerd mount-namespace trap that makes moving the registry store
non-obvious.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 29 insertions, 23 deletions

diff --git a/image-builder/README b/image-builder/README
index 86c463f..5910497 100644
--- a/image-builder/README
+++ b/image-builder/README
@@ -13,10 +13,19 @@ Three scripts, chained (see docs/specs/2026-07-13-image-builder-design.md):
 Plus one maintenance script (not part of the chain):
   registry-gc.sh         reclaim unreferenced blobs from the registry store
 
+And two reference copies of the host config the chain depends on. Nothing
+reads them; they are here so a rebuilt VM is reproducible:
+  crontab.example        the nightly schedule, as deployed
+  fstab.example          the two-disk storage layout, as deployed
+
 All settings live in ./config.
 
-VM setup (docker.noland.dnx, Slackware x86_64, 4 vCPU / 4 GB / 80 GB)
---------------------------------------------------------------------
+VM setup (docker.noland.dnx, Slackware x86_64, 4 vCPU / 4 GB)
+-------------------------------------------------------------
+Two disks, and which is which matters: a system disk (80 GB, also holding the
+registry store) and a separate docker volume (160 GB) for images and build
+scratch. See fstab.example.
+
 1. Install docker; enable the daemon.
 
 2. NFS-mount the two NAS trees read-only, named to match:
@@ -25,10 +34,17 @@ VM setup (docker.noland.dnx, Slackware x86_64, 4 vCPU / 4 GB / 80 GB)
    Each is a full mirror (PACKAGES.TXT, ChangeLog.txt, slackware64/, patches/,
    extra/). Root must be able to read them (bootstrap runs installpkg as root).
 
-3. Run a LAN registry (storage on the same disk as docker, bind-mounted):
+3. Run a LAN registry. Put its storage on a DIFFERENT disk from docker's:
      docker run -d --restart=always -p 5000:5000 \
        -v /opt/sbo-testbuild/registry:/var/lib/registry --name registry registry:2
 
+   The bind target belongs on the system disk, not the docker volume. The
+   registry grows with every push and never shrinks on its own, while the
+   build needs a large transient peak at a fixed hour; sharing one volume
+   pits a slow leak against a hard failure, and the build loses. See
+   fstab.example for the layout and the dockerd-namespace trap if you move
+   an existing store.
+
 4. Mark the registry insecure (plain HTTP) on the VM AND every pulling client
    (this dev box, the buildsystem VM). In /etc/docker/daemon.json:
      { "insecure-registries": ["docker.noland.dnx:5000"] }
@@ -44,26 +60,16 @@ VM setup (docker.noland.dnx, Slackware x86_64, 4 vCPU / 4 GB / 80 GB)
    full-image on the base-image digest, build-sbo-testbuild on the full-image
    digest + tools .txz hash), so an unchanged night is a cheap no-op. -current
    moves daily and rebuilds most nights; 15.0 is frozen stable and rebuilds only
-   on a real repo update. Deployed schedule on docker.noland.dnx:
-      # -current (ready ~04:35)
-      0  3 * * *  /path/to/sbo-dockerbuild/image-builder/bootstrap.sh           --version current >> /var/log/sbo-testbuild.log 2>&1
-     20  3 * * *  /path/to/sbo-dockerbuild/image-builder/build-full-image.sh    --version current >> /var/log/sbo-testbuild.log 2>&1
-     30  4 * * *  /path/to/sbo-dockerbuild/image-builder/build-sbo-testbuild.sh --version current >> /var/log/sbo-testbuild.log 2>&1
-      # 15.0 (ready ~06:35)
-      0  5 * * *  /path/to/sbo-dockerbuild/image-builder/bootstrap.sh           --version 15.0 >> /var/log/sbo-testbuild.log 2>&1
-     20  5 * * *  /path/to/sbo-dockerbuild/image-builder/build-full-image.sh    --version 15.0 >> /var/log/sbo-testbuild.log 2>&1
-      30 6 * * *  /path/to/sbo-dockerbuild/image-builder/build-sbo-testbuild.sh --version 15.0 >> /var/log/sbo-testbuild.log 2>&1
-
-   Post-build cleanup, after the chain (which ends ~06:30) and before the 15:00
-   cache prune:
-      # daily: drop dangling images left behind when a tag moves to a new build
-      0  7 * * *  docker image prune -f >> /var/log/sbo-testbuild.log 2>&1
-      # weekly (Sunday): reclaim unreferenced blobs from the registry store
-      0  8 * * 0  /path/to/sbo-dockerbuild/image-builder/registry-gc.sh >> /var/log/sbo-testbuild.log 2>&1
-
-   The registry never reclaims blobs on its own, so without the weekly GC its
-   storage grows until the disk fills and the nightly builds fail with
-   "no space left on device" (see the section below).
+   on a real repo update.
+
+   The schedule lives in crontab.example, which is a copy of what the VM runs:
+     crontab crontab.example        # or paste it into `crontab -e`
+
+   Install it rather than retyping it. The timings are load-bearing, not
+   cosmetic: reclaim runs at 02:50, immediately before the 03:00 chain, so the
+   headroom exists when the build needs it. An earlier schedule pruned in the
+   afternoon instead and the -current build failed ten nights running with
+   "no space left on device". The file explains each window.
 
 7. Ensure docker.noland.dnx resolves on the LAN (static IP or DNS).