# 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: its own disk, NOT the docker or system 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. # # That traded one shared volume for another. Between weekly GCs the registry # grew 13G -> 53G and filled /, which took down /tmp, the log, buildx state # and even crontab (a `crontab -` on the full disk wrote a 0-byte file). On # 2026-10-05 it moved to its own disk with backup=0 in Proxmox, so it is out # of vzdump and a leak can only fill itself. # # Keep it separate from both. The registry is small, static and I/O-light; # the build disk is large, churning and latency-insensitive; the system disk # must never fill. Sharing a volume couples a slow leak to a hard failure. # The contents are reproducible by re-pushing the images, so never back it up. UUID= /opt/registry-data ext4 defaults 0 2 # # 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 registry disk. A plain `docker stop/start` # is not enough: on 2026-10-05 the restarted container still saw the old, # deleted directory on the system disk and served an empty store. /opt/registry-data /opt/sbo-testbuild/registry none bind 0 0 # --------------------------------------------------------------------------- # Booting: LILO, and it needs re-running by hand # --------------------------------------------------------------------------- # This host boots BIOS/legacy with LILO in the MBR of /dev/sda. GRUB is also # installed, but only as EFI binaries under /boot/efi, and the firmware never # boots in EFI mode, so they are inert. There is no ambiguity about which # bootloader runs; there is just an unused one lying around. # # LILO maps the kernel by physical block address, so the map goes stale # whenever the blocks move. Run `lilo -v` after: # # * installing or replacing a kernel or initrd (the usual case) # * editing /etc/lilo.conf # * moving or defragmenting /boot # # Forgetting leaves an unbootable machine that looks fine until it reboots, # which on a headless VM means a console session to recover. `lilo -t -v` # tests without writing, and re-running `lilo -v` when nothing changed is # harmless, so when in doubt, run it. # # Editing the entries above does NOT need it: mounts are userspace, applied # long after the kernel loads, and the root device is unchanged.