Snapshot history keeps only about 5 updates #56
No reviewers
Labels
No labels
P0
P1
P2
P3
audio
bakery
boot
breadbug
bug
build
ci
dependencies
design
disk
docs
encryption
final
firewall
graphics
hardware
idle
installer
keybinds
nvidia
packages
phase-1
polish
recovery
reliability
reproducibility
secure-boot
security
shell
signing
snapshots
supply-chain
swap
tech-debt
theming
ux
website
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Breadway/bos!56
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/bos-27-snapshot-retention"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Root Snapper retention keeps 2-20 normal and 4-10 important snapshots with quota-aware 20% free-space and 50% snapshot-space thresholds. The installer enables quota accounting, and the README and recovery docs explain the policy.
Validation: a headless KVM Arch guest with Btrfs root and 17 GiB free completed ten real pacman -S nano transactions. snap-pac created ten complete pre/post pairs, and all ten pairs survived number cleanup, including a repeat with NUMBER_MIN_AGE=0. Exact versions and reproduction commands are in docs/validation/bos-27-retention.md. Bash syntax and git diff --check pass. Earlier FAST_BUILD ISO build passed. Main was merged into this branch to resolve its changelog conflict.
Settings copy is tracked separately by BSET-20 and PR #22.
Closes #27
This PR card tracks BOS-27 / PR #56. Ten pacman transaction/free-space acceptance is still missing; reviewer found the PR unmergeable. Parent BOS-27 is TODO. Synchronizing card status to TODO.
Independent review of PR #56: the change sets the requested Snapper retention values and documents them, but the acceptance criterion still requires ten real
pacman -Stransactions followed by confirming at least ten pre/post snapshot pairs while free space is available. I could not safely run that check in this environment./dev/kvmis absent; this process has no elevated capabilities (NoNewPrivsand seccomp are active), andsudocannot escalate here. A QEMU TCG guest is technically available, but there is no prepared installed guest, and the host filesystem is 95% full with 45 GB free while other BOS build work is present. Provisioning an installer guest for the real transaction test is not a safe validation path under those constraints. I did not run a simulated substitute or touch the live desktop, user configuration, or installed binaries. PR #56 is also currently reported unmergeable; Forgejo returns no CI statuses, consistent with this repo's lack of pull request CI. Returning BOS-27 and its PR card BOS-56 to TODO until the real acceptance can be demonstrated.Independent review PASS at
44504c01af. Reviewed installer config/quota changes and independently read the preserved headless guest raw logs. They contain ten distinct pacman transaction markers, ten actual nano reinstalls, and ten complete snap-pac pre/post pairs. The separate age-eligible cleanup CSV retains all ten pairs after disabling the minimum-age protection. Final config matches NUMBER_LIMIT=2-20, NUMBER_LIMIT_IMPORTANT=4-10, FREE_LIMIT=0.2, SPACE_LIMIT=0.5 and QGROUP=1/0; guest has 17 GiB free. Bash syntax and diff check pass; no configured CI statuses. This meets the requested free-space transaction acceptance. It does not claim a fresh Calamares install or low-space stress test. Settings copy is tracked separately by BSET-20.