From 48882edb25df1dabb6197edda8ffb092c32731fd Mon Sep 17 00:00:00 2001 From: "Danilo M." Date: Tue, 22 Sep 2026 11:10:35 +0200 Subject: release 1.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 --- image-builder/fstab.example | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 image-builder/fstab.example (limited to 'image-builder/fstab.example') 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. +# 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 -- cgit v1.2.3