1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
# 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: 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=<registry-disk-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.
|
