• Onebox v32.9.0
    Release / build-and-release (push) Successful in 21m42s
    Stable

    jkunz released this 2026-09-25 05:33:17 +00:00 | 16 commits to main since this release

    2026-09-25 - 32.9.0

    Features

    • Abandon a storage leftover retirement that has changed nothing. onebox migration storage-leftovers --abandon removes the storage-leftover-retirement record while every artifact in it is still present, so no archive is recorded and no removal intent is, after which Onebox starts again and a later --approve captures anew. It also asks the backup repository for snapshots under the retirement's tags: an unpinned attempt an interrupted cleanup left is removed by its exact tags, and a pinned archive the record does not name yet refuses the abandonment, like an archived artifact, a removal in progress or a complete retirement; those are only resumed with --approve. The record is removed only while it is exactly the one checked.

    Fixes

    • Refuse a storage leftover retirement before it writes its record when the backup repository cannot be listed. The approval wrote the storage-leftover-retirement record and only then listed the repository for earlier archives, so a listing refused by the repository, such as Snapshot list exceeds the maximum 33554432 bytes, left a record that had changed nothing and that kept Onebox from starting. The repository listing under the new retirement's tags now runs before the record is written, after the preconditions and the inventory and hashing of every artifact, which already did. BackupManager.findDirectoryArchives returns each archive's snapshot id, tags and pin instead of its id alone.
    • Name both ways out when Onebox refuses to start during a storage leftover retirement: the resume with --approve --checkpoint-reference <its checkpoint reference>, and --abandon while it has archived and removed nothing.

    Maintenance

    • Update @serve.zone/containerarchive from 0.4.0 to 0.6.2. Its listSnapshots() returns snapshot summaries without item or chunk lists and applies the tag filter before its 32 MiB listing cap, so the retirement's listing under its own tags no longer fails on the size of the whole repository; full manifests come from getSnapshot(). verify() checks one manifest at a time and prune() plans retention on the snapshot summaries, so the full-integrity check and the daily prune's retention planning are no longer refused by the 32 MiB cap on a repository whose manifests together exceed it. Destructive pruning stays disabled in containerarchive, so the daily prune still removes nothing and logs Archive prune failed. Its native binaries are now static musl builds; they use mimalloc as their global allocator and zlib-rs for gzip, so backups and restores run at least as fast as with the 0.4.0 glibc binaries again and verification within 3 % of them, where 0.6.1's musl binaries restored and verified 31–87 % slower. The containerarchive process holds more resident memory during those operations (it peaked at about 142 MiB instead of 36 MiB in containerarchive's x86_64 measurements), and compressible data is stored about 2 % larger; existing archives need no migration.
    Downloads