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, 45 insertions, 0 deletions

diff --git a/image-builder/fstab.example b/image-builder/fstab.example
new file mode 100644
index 0000000..79c9473
--- /dev/null
+++ b/image-builder/fstab.example
@@ -0,0 +1,45 @@
+# sbo-testbuild storage layout, /etc/fstab on the docker host.
+#
+# Copyright (C) 2026 Danilo M. <danix@danix.xyz>
+# GPLv2 only; see LICENSE.
+#
+# Reference copy of the two entries this build system depends on. Nothing
+# reads this file; it is recorded so the layout survives a lost VM, because
+# where these live is not a detail. Getting it wrong is what broke the
+# nightly builds for ten days.
+#
+# The UUID below is this host's; use your own (`blkid /dev/sdb1`).
+
+# ---------------------------------------------------------------------------
+# Docker data: its own disk
+# ---------------------------------------------------------------------------
+# Build scratch space wants room to breathe. Exporting the -current full image
+# writes roughly its own size (~33G) transiently, on top of the images already
+# resident, so this volume is sized for the peak and not the steady state.
+# Everything on it is reproducible from the mirror, so it is excluded from
+# vzdump.
+UUID=0e5d008d-0ee0-41bc-9222-aedba1e088d0  /var/lib/docker  ext4  defaults  0  2
+
+# ---------------------------------------------------------------------------
+# Registry store: NOT on the docker disk
+# ---------------------------------------------------------------------------
+# The registry's blob store used to be a bind mount from the docker disk
+# (/var/lib/docker/registry-data). That put ~25G of permanently-resident data
+# on the same volume as the transient build peak, and the two competed: the
+# registry grows with every push, the build needs headroom at 03:20, and the
+# build lost. Moved to the system disk on 2026-09-22, which had 49G idle.
+#
+# Keep them separate. The registry is small, static and I/O-light; the build
+# disk is large, churning and latency-insensitive. Sharing one volume couples
+# a slow leak to a hard failure.
+#
+# If this host's backups cover the system disk, exclude /opt/registry-data:
+# the contents are reproducible by re-pushing the images.
+#
+# Moving it is not just an fstab edit. dockerd caches the mount in its own
+# namespace, so after remounting you must restart the daemon and recreate the
+# registry container, or pushes keep silently landing on the old disk. Verify
+# with:  grep ' /var/lib/registry ' /proc/$(docker inspect registry \
+#            --format '{{.State.Pid}}')/mountinfo
+# and check the device is the system disk, not the docker one.
+/opt/registry-data  /opt/sbo-testbuild/registry  none  bind  0  0