mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-10 04:36:40 +00:00
kevinveenbirkenbachandClaude Opus 5
41732fbf9a
The guard compared free space against USB_SIZE_MB = PULLED_MB*2+256, which is the nominal size of an image 02_luks_device.sh creates with truncate - sparse, so nothing ever allocates it. It also ran after that script, i.e. once the image was already created, formatted and mounted, so the image's own footprint was already subtracted from the df it read. It charged the pulled tree a second time while that tree was counted as used, not free. In run 30781723102 it demanded 28108M against 16582M and refused a drill that fits: the peak is 14555M additional, derived from rescue-diagnostics-swarm-web-app-nextcloud-0, and the same run's debian job contains a full 9/9 completion of the same drill. Rather than predicting the image's ext4 overhead - two earlier attempts at that constant were wrong in both directions - both thresholds are now read: df on DEV_MOUNT reports what the encrypted filesystem actually offers after mkfs, and df on DIR_BACKUPS reports what the host still has for the copy the sync writes into the sparse file and, later, the restore root. Both are compared against PULLED_MB, a measured quantity. USB_SIZE_MB keeps sizing the image. Every abort now tears the device down (umount, luksClose, rm -f); a refused drill previously left the mapping and the image behind. Exercised against the recorded numbers and six edge cases: 26624/16582/13926 passes where the old guard refused, an undersized device or host is refused, and an empty or non-numeric df reading is reported as unreadable. Both thresholds sit exactly at PULLED_MB, so second-order allocation inside the image (extent trees, directory blocks) is uncovered - tens of MiB against a 13.9 GiB tree. The drill has not been run with this guard. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Script Collection
This directory contains automation scripts used across the project.
-
system/ contains host and system-facing helpers.
-
container/ contains helpers that run inside the local container.
-
github/ contains GitHub workflow helper scripts.
-
For the canonical Make target index, see make.md.
-
🛠️ Organize operational helpers for development, CI, release, and maintenance
-
🧭 Separate responsibilities into focused subdirectories with clear scope
-
📚 Keep script-based workflows discoverable and easier to navigate
The scope of this folder is script organization at the repository level. Detailed responsibilities belong in the README files of the respective subdirectories.