| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
On sda2 the registry grew 13G -> 53G between weekly GCs and filled /.
That broke /tmp, the build log, buildx state and the GC itself, so every
build failed from 2026-10-04. Run registry-gc.sh daily at 07:30 instead
of Sundays only.
The store has since moved to a dedicated disk with backup=0, out of
vzdump. Record that in fstab.example along with two traps hit during
the fix: `crontab -` on a full disk silently writes a 0-byte crontab,
and a plain docker stop/start leaves the registry serving the old,
deleted directory.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
|
The docker host boots BIOS/legacy with LILO in the MBR; GRUB is installed
but only as EFI binaries the firmware never loads, so it is inert rather
than competing. Worth writing down, because "two bootloaders installed"
reads as ambiguous until you check which one the firmware actually uses.
The part that bites is that LILO maps the kernel by physical block, so
`lilo -v` has to be re-run by hand after a kernel or initrd change. Skip
it and the machine looks fine until it reboots, which on a headless VM
means recovering from the console.
Noted next to the mount entries, and noted that editing those entries
specifically does not need it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|
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>
|
