Project

• 1: Platforms and Limits
• 2: Design
• 3: Security and Trust
• 4: Contributing
• 5: Shipping the Mac Component
• 6: Validation History
• 7: Barn 0.9.3 Changes
• 8: Barn 1.1.0 Local Acceptance

1 - Platforms and Limits

Barn is built for local development and testing. Use this page to check host requirements and guest capabilities before setting up a lab.

Version

This documentation covers Barn 1.2.0 (see the Installation Guide and 1.2.0 Release Notes). Run barn version to check your installed binary; the Linux image catalog updates independently via barn update.

• Stable channel: Barn 1.2.0 was published on 2026-11-12 as a regular GitHub release, so releases/latest, the download installer without BARN_VERSION, and the Homebrew formula select it; DEB and RPM packages are downloaded from the release. Set BARN_VERSION=1.2.0 to pin it.
• Native macOS component: The Darwin arm64 archive and Apple Silicon Homebrew install include the signed, notarized Barn.app alongside the matching CLI and helper. Go and Xcode are not required; see macOS Guests.
• Changes in 1.2.0: Resource and environment overrides, recoverable root-disk growth, lifecycle --parallel, and inventory-based host names. Linux defaults change to 1 vCPU / 2 GiB; set vm_cpu: 2 and vm_mem: 4GiB explicitly to preserve 1.1.0 defaults. Existing applied VMs retain their resources until a resource-changing operation is requested.
• Historical verification: Dated test records are archived in Validation History and Barn 1.1.0 Local Acceptance.

See the version baseline for option availability and the 1.2.0 validation record for release evidence.

Linux guests

Barn builds release binaries for all four host targets, with primary live-hypervisor test coverage on darwin/arm64 and linux/amd64. On Linux hosts, Barn requires accessible /dev/kvm and either NetworkManager or systemd-networkd. Run barn doctor to inspect host readiness or barn setup --dry-run to preview dependency and network setup.

The catalog embedded in Barn 1.2.0, revision 2026110502, provides 9 distribution families and 17 image artifacts with u24:stable as the default: Ubuntu 22.04/24.04/26.04 LTS, Debian 12/13, Rocky Linux 8/9/10, and CentOS 7 (see Linux Images for exact versions):

• Each user manages one Linux lab in a private RFC1918 /24; the node count is limited only by the subnet’s usable addresses and host resources.
• Foreign-architecture guests run under QEMU TCG software emulation. Rocky Linux 8 arm64 also uses TCG on Apple Silicon because its 64 KiB page-size kernel is incompatible with Apple HVF.
• CentOS 7 (el7) is a deprecated compatibility image restricted to native linux/amd64.
• vm_shares (QEMU Virtio-9p) supports Linux and macOS hosts when QEMU and the guest kernel support 9p. SSH/SCP/rsync remain alternatives when a guest kernel lacks 9p.

macOS guests

barn mac requires Apple Silicon, macOS 27 or later, an active desktop login session, and the Barn.app native component. Guests run macOS 27 on Apple’s Virtualization.framework without needing QEMU or the Linux host network (see the macOS Guests guide):

• Disk space: Preparing the first macOS VM requires roughly 65 GiB of free disk space for the cached .ipsw restore image, the unbooted base image, and the VM’s APFS clone. Downloads support HTTP range resumption, or you can pass a local file via --ipsw.
• Concurrency limit: Apple’s framework allows at most two running macOS VMs at a time per Mac (counting VMs across all apps and any active .ipsw base installation); you can keep additional VMs in the stopped state.
• Isolation and sharing: Each macOS VM gets its own private /24 NAT subnet, SSH keypair, login password, and APFS copy-on-write disk, plus VirtioFS directory shares (--share) and plain-text clipboard sync.
• Framework boundaries: USB passthrough, VM snapshots, and suspend/resume are not supported, and Apple Account sign-in inside a virtual machine may be restricted by macOS.
• Damaged Mac state: A malformed recovery journal stops barn mac image ls, the space estimate in barn mac doctor, and image pruning until it is repaired. One unreadable machine state stops barn mac ls, while the other machines stay usable by name.

Use barn mac doctor and barn mac ls to inspect macOS VMs; top-level barn status, destroy, and purge apply only to the Linux lab.

Data and lifecycle

Keep important work backed up on the host or in version control:

• Linux lab: barn recreate replaces root disks and non-persistent data disks while retaining persistent: true disks, and a whole-deployment recreate refuses an inventory that omits an existing node; barn destroy removes root and non-persistent disks. During recovery, barn up formats a data disk that carries no signature and resets an existing ext4 or XFS filesystem only when the checker reports recognized corruption. A partition table, a signature without a UUID, unsupported filesystem features, or an unknown checker failure keeps the data and reports a warning (see Storage and Access).
• macOS VMs: barn mac recreate replaces the VM’s disk with a fresh clone from the base image, and barn mac destroy deletes the VM’s disk, keys, and state while leaving shared host directories untouched.

For diagnostics, see Troubleshooting; for privilege and trust boundaries, see Security and Trust; and for build and release workflows, see Contributing.

2 - Design

Barn provides two distinct virtualization workflows through one CLI: multi-node Linux labs and standalone macOS guests.

The sections below summarize the Linux lab architecture; for the deeper rationale behind each decision, see the Design Essays. The native Mac lifecycle essay explains network ownership, locks, credentials, and recovery; usage is in macOS Guests and Mac Commands.

One Linux lab per user

Each Unix user manages one Linux lab deployment stored in BARN_HOME (default ~/.barn) and driven by a single Pigsty-compatible YAML inventory (see Why Barn Has No Projects). Because deployment state lives in BARN_HOME rather than the working directory, lifecycle and access commands work from any directory.

Node-level convergence

Barn computes a specification hash per node from the documented vm_* and Pigsty identity fields and records it alongside the node’s committed state and QEMU process identity:

• barn up creates newly added nodes, starts stopped nodes, retries unfinished guest setup on running nodes without restarting their QEMU processes, and refreshes managed /etc/hosts and SSH entries.
• Changing an existing node’s specification or removing a node from barn.yml never destroys a VM behind your back—CPU and memory changes use barn resize, other modifications require barn recreate, and removals require barn destroy. A whole-deployment recreate refuses an inventory that omits an existing node (see Declarative Does Not Mean Destructive).

Runtime selection

--arch/-A overrides inventory vm_arch for an invocation. With neither set, the guest follows the host; -A native overrides the inventory and restores that default. Image flag -I does not change architecture, and switching an existing VM requires recreation; see configuration rules.

vm_arch applies across the entire deployment (native uses the host CPU architecture; explicit amd64 or arm64 selects that architecture from the catalog). Barn uses hardware acceleration (HVF on macOS, KVM on Linux) whenever guest and host architectures match, switching to QEMU TCG only for foreign architectures or catalog-declared kernel incompatibilities (el8 arm64 on Apple Silicon). If native HVF/KVM fails for any other reason, Barn fails closed rather than silently degrading to software emulation.

Each node’s committed state records the effective architecture and accelerator (barn status displays both). Before executing a destructive recreate, Barn pre-validates the QEMU binary, version, network backend, base image bytes, boot mode, and firmware so a missing dependency never destroys a working VM.

Two NICs, one fixed subnet

Every Linux VM attaches two virtual NICs (see Why Every Barn Node Has Two NICs):

• Management NIC: QEMU user-mode networking providing DHCP, DNS, outbound internet access, and host-loopback SSH port forwarding without host firewall changes.
• Fixed-IP lab NIC: Carries the static RFC1918 /24 address from barn.yml for host-to-node, node-to-node, and Ansible traffic.

To provide the fixed-IP subnet without running QEMU as root:

• macOS hosts run a pinned socket_vmnet daemon.
• Linux hosts use NetworkManager (nmcli managing barn0) when active, or systemd-networkd with the distribution qemu-bridge-helper (verifying beforehand that enabling an inactive systemd-networkd will not claim physical host interfaces). On Debian, setup grants qemu-bridge-helper access to a group containing the caller and smoke-tests an unprivileged QEMU attachment before committing the network transaction.

Storage and configuration lifetimes

Desired configuration (barn.yml), applied deployment state ($BARN_HOME), and cached base images ($BARN_HOME/images) have independent lifecycles:

• Updating a catalog channel (barn update) does not rewrite existing VM root disks.
• Verified base images are stored read-only and shared across nodes via per-node qcow2 copy-on-write root overlays.
• Ordinary destroy and recreate retain persistent: true data disks. During guest recovery, up formats only a data disk without any signature or an ext4/XFS filesystem whose checker reports recognized corruption; anything it cannot classify keeps its data and reports a warning (see Data Disks and Storage and Access).
• barn image prune protects images referenced by the active catalog, applied nodes, and local-* aliases (see Images).

Safety boundary

QEMU processes and image downloads run as your normal user account; root privileges are used only during setup, network install/uninstall, and hosts install/uninstall. Before signaling a process or deleting a node file, Barn verifies file ownership, path containment, QMP UUID/name identity, process start-time/cmdline tuples, and the journal allowlist—stopping immediately if any check is ambiguous (see A PID Is Not a Virtual Machine).

3 - Security and Trust

Barn is designed for trusted local development workstations. All Linux lab nodes share a private subnet, and the control node holds the SSH key needed to administer every peer node in the lab. Barn’s ownership and identity checks prevent accidental damage to unrelated host files or processes, rather than isolating mutually untrusted local users.

Host privileges

Always run barn as your normal desktop or shell user. QEMU processes, Barn.app macOS VMs, image downloads, VM disks, and state files all run under and belong to your user account. Administrator (sudo) privileges are used only for three explicit host-level tasks:

Before prompting for sudo, setup, network, and hosts display the exact plan they will execute. On a terminal, up, start, restart, and reload can offer to prepare a host that lacks a dependency or an intact Barn network; they run the same setup plan with the same single confirmation and never assume --yes. Without a terminal they only report what is missing, so run barn setup --yes for unattended preparation.

Keep barn and /opt/barn/libexec/barn-hosts-helper installed from the same release build: the CLI verifies the helper’s embedded SHA-256 digest before invoking it, and the helper checks /etc/hosts ownership, permissions, link count, and pre/post content digests on every write.

By contrast, barn mac creates per-VM user-space vmnet networks on demand without any root daemon or privileged network setup (see Design and Uninstall).

Guest access and SSH trust

In Linux labs, the default guest account is dba with a locked password, passwordless sudo, and an Ed25519 deployment SSH keypair generated in $BARN_HOME. Barn also installs that private key on the control node so Ansible playbooks and administrative scripts can reach every node in the lab—meaning anyone with shell access to the control node has administrative access to the entire Linux lab.

Barn applies distinct OpenSSH host-key policies across its three connection paths:

Each macOS VM generates its own Ed25519 SSH keypair and random local administrator password (stored in a 0600 password file inside the VM slot directory and readable via barn mac password). Once guest initialization completes, both Linux and macOS guests enforce SSH public-key authentication, disable SSH password authentication and root SSH login, and grant passwordless sudo to the configured admin user. Strip private keys, passwords, and sensitive state before sharing logs or inventories in bug reports.

On first Mac contact, trust comes from the runner-owned private network and runner identity checks before and after the SSH connection; the observed host key is then pinned to the instance UUID. The GUI password shares the SSH key’s file-permission boundary: that key already grants guest sudo, so storing only the password in Keychain would add signing and lock-state failures without protecting additional guest authority. See Native Mac lifecycle.

Shared folders and disposable disks

• Host directory shares: Writable shares (readonly: false in Linux vm_shares or :rw in barn mac --share) grant guest processes direct write access to the shared host directory, and changes made inside the shared directory persist after the VM is destroyed. Share dedicated project folders and prefer read-only shares whenever guests do not need to modify host files.
• Persistent and disposable data disks: Ordinary Linux destroy and recreate retain persistent: true data disks. During recovery, up formats a data disk without any signature and resets an existing ext4 or XFS filesystem, persistent or not, when the checker reports recognized corruption; other probe or checker failures keep the data and report a warning. Keep important data backed up on the host (see Storage and Access).

Downloads and image trust

Barn separates trust verification across four independent mechanisms:

Release assets are built from the exact tag, by the tag workflow when its Mac signing secrets are configured and otherwise by the documented local release path. Source CI must pass on the release commit first. Both paths require package, archive, SBOM, and checksum verification before creating a draft GitHub Release; local publication follows the Mac release handbook.

In 1.2.0, release.json records signed:false, attested:false for the general release envelope. The Git tag and general checksums/release metadata have no separate cryptographic signature or attestation. Catalog Minisign verification and Apple Silicon code signing/notarization retain the distinct scopes listed above; the final acceptance record verifies them separately.

The two official image repositories (https://repo.pigsty.io/barn and https://repo.pigsty.cc/barn) always require valid minisign catalog signatures, even when passed explicitly via --repo. Custom HTTPS or local directory repositories may use unsigned catalogs when explicitly selected with --repo or BARN_REPO (see Linux Images).

Report a vulnerability

Report security vulnerabilities privately via GitHub Security Advisories or by emailing [email protected] with barn --json version, your host OS and architecture, and a minimal reproduction with credentials removed. Security fixes land in the latest 1.x patch release; only the latest 1.x release is supported, and 0.x releases receive no further fixes. See SECURITY.md for the full policy, and use GitHub Issues for ordinary bug reports.

4 - Contributing

Barn is an Apache-2.0 open-source project. Contributions to the CLI, native macOS component, documentation, and image pipeline are welcome.

Choose a repository

When filing a bug report, include barn version, your host OS and architecture, the exact command you ran, and the error output with private keys and passwords removed. Report security vulnerabilities privately via the security policy. For major behavioral changes, open an issue first to align on the design, and see CONTRIBUTING.md for coding and pull-request conventions.

Find the implementation

Tag v1.2.0 is the current stable release; its changes since 1.1.0 are listed in the 1.2.0 release notes. Find each subsystem here:

Read each package’s tests alongside the implementation—they codify the exact boundary between automatic recovery and fail-closed safety checks.

Build and test

Install the pinned toolchain listed in Build from Source and run the full local gate:

make check

make check runs Go module and shell checks, unit and race-detector tests, go vet, staticcheck, govulncheck, four-target cross-builds (darwin/arm64, darwin/amd64, linux/amd64, linux/arm64), installer and image-pipeline tests, and license verification. When changing hypervisor, networking, or Barn.app behavior, also run live VM lifecycle tests on the target host (macOS HVF / Virtualization.framework or Linux KVM) and record the tested host environment in your pull request.

To verify packaging changes locally with the tools pinned in packaging/toolchain.env:

make release-check
make release-snapshot SNAPSHOT_DIST=.goreleaser-review

SNAPSHOT_DIST must be a new directory path inside the repository root; release-snapshot builds and verifies archives, .deb/.rpm packages, SBOMs, and checksums locally without uploading artifacts.

Edit the documentation

Maintain new design decisions, research conclusions, and acceptance records in this site’s content/blog/design/ and content/blog/release/, with their date, implementation status, source evidence, and acceptance conditions. The design notes collect the durable explanations; task guides and reference contracts stay in content/docs/. The source repository no longer maintains a docs/ directory.

Every documentation page is maintained as an English/Chinese pair (page.md and page.zh.md). Keep commands, defaults, explicit {#id} heading anchors (required by OINK v1.5.1 Duo View compare: true), tables, and warnings in 1:1 parity across both languages, lead with the user’s task, and keep Linux lab and barn mac workflows clearly separated.

Validate the website repository with:

make check

make check verifies the Go module graph, builds the site with Hugo Extended against the pinned OINK v1.5.1 module (clearing any local theme replacements and disabling Go workspaces), and runs bin/check_internal_links.py public to verify all internal links, anchors, and assets. When testing against a local sibling OINK checkout, use make check-local or make build-local. Check CLI examples against barn <command> --help and test inventory examples with barn validate and barn plan using a temporary BARN_HOME.

Release outputs and gates

Stable versions from 1.0.0 on are published as the latest GitHub release; versions below 1.0.0 and versions with a prerelease suffix are GitHub pre-releases and need an explicit BARN_VERSION in the installer. Each release ships darwin/linux .tar.gz archives (containing bin/barn, bin/barn-hosts-helper, and licenses/), Linux .deb and .rpm packages (installing /usr/bin/barn and /opt/barn/libexec/barn-hosts-helper), checksums.txt, release.json, and SPDX SBOMs.

Since 0.9.2, the Darwin arm64 archive also contains bin/Barn.app. Its CLI, helper, and app use Developer ID signatures and Apple notarization. Homebrew installs the app under libexec; ordinary installation needs no Go or Xcode.

The automatic release workflow requires all six Apple signing/notarization secrets and a successful native build. With none configured, it skips automatic release creation; partial configuration fails. The Mac release handbook covers the local signed-release process, payload identity, CI secrets, and installation acceptance.

Before publishing a release:

1. Run make catalog-check: it verifies both official mirrors’ signatures in fresh temporary data roots, requires the exact embedded catalog bytes, and checks all stable artifact URLs and sizes. If the catalog changed, synchronize the embedded snapshot, revision, date, and repo.yaml first. Run catalog tests and barn update with a fresh temporary BARN_HOME; go run ./tools/catalogcheck -verify-bytes also downloads and hashes every stable artifact without retaining it. Formal native builds and both release paths enforce the catalog gate.
2. Run the source CI and packaging workflows on the target commit and verify version strings, paired barn-hosts-helper digests, licenses, SBOMs, and checksums.txt.
3. Run live Linux VM acceptance tests (and live macOS VM acceptance when shipping Barn.app).
4. Publish the GitHub Release and update the Homebrew tap (pgsty/infra/barn), then publish the documentation site and verify the public download and package installation paths.

Maintain the image catalog

Use the Image Pipeline tools (packaging/image-pipeline/build.sh and build-official.py) to validate and offline-normalize candidate qcow2 images before running live hypervisor smoke tests, updating repo.yaml, and signing catalog.json.

To export the binary’s embedded schema-3 catalog to a new path:

go run ./tools/catalogexport /absolute/new/catalog.json

catalogexport writes atomically to a non-existent target path; it accepts relative paths, ~/, and directory symlinks and creates missing parent directories. Use make catalog-sign and make catalog-verify with the offline Minisign keypair (keeping production private keys outside Git and CI). See Linux Images for the repository and client verification rules.

5 - Shipping the Mac Component

Maintainers ship the native macOS component inside the ordinary barn_VERSION_darwin_arm64.tar.gz archive. Since 0.9.2, the standard installer and pgsty/infra/barn Homebrew formula install the CLI, its matching hosts helper, and Barn.app together. This page is the maintained release handbook, checked against the v1.2.0 release scripts on 2026-11-12. For a development build, use Build from Source.

Keep one release identity

The native payload and the GoReleaser archives must carry the same version and source commit. packaging/mac-release.py exports MACOS.md, MACOS.json, bin/barn, bin/barn-hosts-helper, and Barn.app; its manifest records file modes, digests, and signing state. VM disks, credentials, restore images, and installed services are outside this payload.

The app’s bundle identifier is com.pgsty.barn; its internal executable is barn-mac-runner. The CLI checks the versioned runner protocol and also recognizes the earlier Barn Mac.app bundle name. Replacing the app preserves VM state under $BARN_HOME/mac.

Signing order matters because the CLI embeds the helper’s digest:

1. Build and sign barn-hosts-helper.
2. Embed that signed helper’s SHA-256 when building barn, then sign the CLI.
3. Sign Barn.app with hardened runtime and a secure timestamp.
4. Submit the CLI, helper, and app together to Apple for notarization. After acceptance, staple the app, validate its ticket, and check Gatekeeper.
5. Export and re-extract the payload, then recheck signatures and the stapled ticket. During release assembly, replace the Darwin arm64 archive’s CLI/helper with these exact signed bytes and regenerate its SPDX document and checksums.

The payload builder and archive verifiers enforce this pairing. Signing the helper again after building the CLI changes the digest and breaks it.

Build a formal release locally

Use an Apple Silicon Mac with macOS 27+, Xcode 27+, the locked toolchain, a Developer ID Application identity, and a stored notarytool profile. Select the identity with security find-identity -v -p codesigning; create the profile with xcrun notarytool store-credentials. Keep certificate private keys and passwords outside the repository.

Check out a clean source tree tagged v$RELEASE_VERSION, setting RELEASE_VERSION to the intended release version. Choose a new artifact directory outside the source repository:

export BARN_CODESIGN_IDENTITY='Developer ID Application: your organization (TEAMID)'
export BARN_NOTARY_PROFILE=barn-release
export BARN_MAC_REQUIRE_NOTARIZATION=1
VERSION="${RELEASE_VERSION:?Set RELEASE_VERSION to the checked-out release tag version}"
COMMIT="$(git rev-parse HEAD)"
export SOURCE_DATE_EPOCH="$(git show -s --format=%ct HEAD)"
export BARN_BUILD_DATE="$(date -u -r "$SOURCE_DATE_EPOCH" +%Y-%m-%dT%H:%M:%SZ)"
RELEASE_DIR="$(mktemp -d "${TMPDIR:-/tmp}/barn-release.XXXXXX")"

python3 packaging/mac-release.py build \
  "$VERSION" "$COMMIT" "$SOURCE_DATE_EPOCH" "$RELEASE_DIR/native.tar.gz"
BARN_MAC_PAYLOAD="$RELEASE_DIR/native.tar.gz" \
  make release-local VERSION="$VERSION" OUTPUT="$RELEASE_DIR/assets"

The formal native build and release-local enforce the make catalog-check gate before building. Synchronize and test any changed official catalog first, following the release gates. A snapshot or uncommitted payload cannot serve as a formal local release. release-local verifies archives, packages, SBOMs, checksums, and CLI/helper pairing, and writes the assembled assets to the specified directory.

For packaging development, BARN_MAC_PAYLOAD=/absolute/native.tar.gz make release-snapshot exercises native payload composition. Match the payload to the snapshot version selected by .goreleaser.yaml—for example, 1.2.1-next after v1.2.0—and use uncommitted for a dirty checkout or the full commit for clean source. Snapshots accept ad-hoc signatures; formal release verification requires a notarized Developer ID payload.

Configure automated signing

The tag workflow uses all six repository secrets below. With none configured, it skips automatic release creation so maintainers can use the local path. A partial set fails immediately; with all six present, a native build, signing, or notarization failure blocks release assembly.

The Mac workflow imports signing material into an ephemeral runner keychain and removes it at the end of the job. Pull requests and snapshots use ad-hoc builds. The release workflow creates a draft after verifying the assembled payload.

Verify installation and publish

Run make check, make mac-native-test, and a full snapshot with the native payload. Exercise first installation, repeated installation, and upgrade in an isolated directory. On a supported physical Mac, verify startup, SSH, the desktop window, and normal shutdown using the packaged app. App replacement must preserve instance IDs, machine IDs, SSH keys, and host pins.

The existing tests/mac-live-acceptance.py requires an absolute --barn path, a dedicated disposable --home, a separate new or empty --output evidence directory, and explicit --allow-test-root authorization for that test root. Inspect the sequence with --plan first. --gui adds desktop/clipboard checks; --allow-download adds Apple download when no base is prepared. The harness preserves failed state and evidence. Isolate the process’s home directory as well as BARN_HOME when testing SSH integration, because managed ~/.ssh/config entries live outside the VM state root.

Release assembly generates barn.rb from packaging/homebrew/barn.rb.tmpl. The formula installs barn into bin, and the helper and app into libexec. Keep its install/test logic aligned with the tap. Versions with a suffix need an explicit version line because Homebrew may infer 64 from the architecture suffix; plain versions omit that line. The 0.9.1 public archive predates app delivery and supports Linux guests only.

After checking the local output, push the source and tag, upload the files to a draft GitHub Release, and verify the uploaded bytes before publishing. Mark versions below 1.0.0 and versions with a prerelease suffix as pre-releases; stable releases become latest. Update all four Homebrew platform URLs and checksums after the assets are public, then verify the public archives, installer, and Homebrew upgrade against those released bytes. Record signing, notarization, VM acceptance, and public installation results separately in the validation history.

6 - Validation History

Barn 1.2.0 final acceptance — 2026-11-12

• CI and packaging: Source/Mac CI and complete packaging CI passed the release commit. The tag workflow passed its signing-configuration check and skipped remote assembly; the documented local signing path produced the formal release. make release-local, signatures, notarization, staple, and Gatekeeper passed.
• Final artifacts and catalog: All 20 draft and all 20 anonymous public downloads matched the verified local sizes and SHA-256 digests. Both official catalogs verified, activated in fresh roots, and matched the embedded bytes; each mirror’s 17 stable artifacts passed reachability/size checks. Selected runtime image downloads also verified their payload digests.
• Final runtime: The downloaded Linux archive passed 18 KVM operations covering ext4/XFS root growth, idempotence, shrink rejection, guest-tool failure, CLI interruption, identity/data retention, concurrency, and teardown. The downloaded native Mac bundle completed all 15 lifecycle phases plus desktop, two-way clipboard, close-window background execution, SSH, and normal shutdown. One Apple HTTPS timeout was preserved and retried successfully after identity/base checks; no product bytes changed.
• Public delivery: Public latest and pinned installers passed on darwin/arm64 and linux/amd64. Isolated installer upgrade from 1.1.0 and repeated installation passed. The Homebrew update passed a real 1.1.0 → 1.2.0 upgrade, brew test, style, and strict online audit. The bilingual reference now documents 57 commands and 174 local option entries per language against 1.2.0.

Physical runtime coverage was darwin/arm64 and linux/amd64; darwin/amd64 and native linux/arm64 received cross-build and artifact checks. The historical 1.1.0 homepage recording is explicitly labelled. See the complete release review for candidate upgrade evidence, retained retries, and scope limits.

Barn 1.2.0 preparation — 2026-11-12

The 1.2.0 readiness review preserves the uncommitted candidate’s source, catalog, full snapshot, Linux/KVM and native Mac checks, followed by the completed commit, CI, signing, and publication gates.

Barn 1.1.0 final acceptance — 2026-11-09

• Source and packaging: The release commit passed source/Mac CI and complete packaging CI before tagging. Local make check, make mac-native-test, and make release-snapshot also passed. The tag workflow passed its signing-configuration check; the complete release used the documented local signing path because repository signing secrets were absent.
• Downloaded assets: All 20 draft attachments were downloaded again and matched the local sizes and SHA-256 digests. The 19-entry checksum manifest, archive/package parity, four binary architectures, file permissions, helper pairing, and SPDX documents passed verification. Apple accepted notarization submission cabe1b9c-fc54-4f07-b8bf-d834f0226013; the downloaded app passed signature, staple, and Gatekeeper checks. The relocated Homebrew bin/libexec layout found the matching native component.
• Catalog: Both official catalogs passed signature verification, activation in fresh data roots, and byte comparison against the embedded catalog; all 17 stable artifacts passed HTTP availability and size checks on both mirrors. The final downloaded binary also activated the official catalog in a fresh BARN_HOME.
• Linux runtime: The downloaded linux/amd64 binary created a Debian 13 guest using -I d13 -A x86_64 without rewriting its inventory. CPU/memory changes 2/2 GiB → 3/3 GiB → 2/2 GiB, stop/start, remote arguments, and exit 17 passed. VM UUID, SSH public key, machine ID, and the persistent-disk sentinel survived resizing and restart. A second Debian 13 guest booted as arm64 through -A aarch64, using QEMU TCG with cortex-a72; SSH reported aarch64. Both test guests were removed after verification.
• Mac runtime: A new isolated macOS 27 guest passed creation, SSH, remote exit 17, stop/start, identity and data retention, and destruction. Existing user SSH files were unchanged and the user’s running Mac VM was left in place. The signed public installer and repeated installation also passed in a separate directory.
• Public delivery: Anonymous downloads of all 20 public attachments matched the verified draft. Both the default installer and explicit BARN_VERSION=1.1.0 installed the published release. The Homebrew update sets all four archive URLs and digests. The initial Ubuntu 26.04 recording verified public installation and a first Linux VM on a prepared host network; the homepage recording now shows a real Apple Silicon macOS run (brew install pgsty/infra/barn, ./configure -c full, a four-node barn up, and barn status on macOS 27.0.1 with QEMU 11.1.3). A subsequent 16-stage in-place upgrade and multi-distro acceptance run on Apple Silicon is recorded in Barn 1.1.0 Local Acceptance.

Physical hosts covered darwin/arm64 and linux/amd64, with an additional linux/arm64 guest under TCG. darwin/amd64 and native linux/arm64 received cross-build and artifact checks. GUI and clipboard evidence retains its earlier dated scope. Initial harness retries corrected unsupported timeout flags, a test write requiring guest sudo, and a TCG assertion that did not accept the thread=multi option; their logs were retained alongside the successful runs.

Barn 1.0.0 final acceptance — 2026-11-05

The final acceptance record binds the downloaded artifacts and public installation checks to this release identity:

• Source and downloaded assets: The final commit passed source/Mac CI and packaging CI. The release used local Developer ID signing because automated signing secrets were absent. All 20 uploaded attachments were downloaded again, matched their original sizes and SHA-256 digests, and passed the 19-entry checksum manifest plus archive/package, CLI/helper, architecture, permission, SBOM, and identity checks.
• Catalog bytes: Both official catalogs verified and matched the embedded bytes. Streaming all 17 stable artifacts from each mirror produced 34 successful size/digest checks. A fresh BARN_HOME activated the catalog with barn update.
• Packaged Mac acceptance: The downloaded CLI/helper/app passed Developer ID, notarization, staple, and Gatekeeper checks, including after installation and relocation into the Homebrew layout. An isolated 0.9.3 → 1.0.0 installer upgrade retained the old release and existing VM identities, SSH keys, and data sentinels. A new VM passed SSH, write, stop/start, identity/data retention, and destruction checks.
• Linux acceptance: On linux/amd64, the downloaded binaries created two Debian 13 guests in a fresh state root. Fixed IPs, accounts, XFS data disks, stop/start/restart, argument boundaries, and remote exit 17 passed. Missing-node recreation failed before stopping VMs; control-node deletion elected a successor; destruction followed by up rotated machine identity while preserving a persistent-disk sentinel.
• Public channels: After publication, both the default installer and explicit BARN_VERSION=1.0.0 installed the public release. Real Homebrew upgraded 0.9.2 → 1.0.0 and passed brew test, online audit, and tap tests. The tap update and site update were published, and the public bilingual release and installation pages were checked.

Physical runtime coverage was darwin/arm64 and linux/amd64. darwin/amd64 and linux/arm64 received cross-build and artifact checks. GUI, clipboard, and fault-injection experiments from the preceding candidate run retain that earlier identity below.

Hardening and candidate rehearsals — 2026-11-04–05

The hardening checkpoint at 377061c passed source checks and a 0.9.4-next packaging snapshot without a native Mac payload. Subsequent physical-host tests began with 0.9.4-next; fixes received focused retests, followed by a signed and notarized 1.0.0-rc.1 build using catalog 2026102802. The candidate run covered disk-preservation checks, lock release after cancelled sudo work, shared-networkd uninstall, the 15-stage Mac lifecycle, GUI/clipboard, and interrupted-recreate recovery. Final release assembly later used catalog 2026110502 and the identity above.

The record retains failed attempts as well as successful reruns. A short SSH probe needed bounded retry; a resource-constrained build and a shared module-cache failure needed environment corrections; one acceptance assertion incorrectly required a stdout field when successful empty output could omit it. The dm-error experiment was rejected by the whole-disk guard before reaching the filesystem checker. These observations identify which product path actually ran and which failure belonged to the harness or environment.

Barn 0.9.1 local candidate acceptance — 2026-10-22

The 0.9.1 record reports make check, native component tests, four-platform packaging, and an ad-hoc native payload. The CLI candidate was 0.9.1-dev.1; the complete snapshot was 0.9.1-next. An isolated upgrade from a real 0.9.0 archive used a local download fixture and verified repeated installation, retained releases, helper pairing, and app discovery. Homebrew checks covered the bin/libexec layout; native tests and mac doctor did not start a VM. The public 0.9.1 assets contained CLI/helper archives and Linux packages, without Barn.app; the original record’s public-release checklist describes the subsequent process, not completed runtime evidence.

Pre-0.9.0 checkpoint — 2026-09-29

At the 2026-09-29 checkpoint, Barn 0.9.0 was the first release candidate prepared under the barn name prior to publication. For current installation commands, use the Quick Start.

Documentation baseline

macOS guests

At the 2026-09-29 checkpoint, barn mac ran macOS 27 guests on Apple Silicon via Barn Mac.app (io.pgsty.barn.mac-runner; subsequently renamed to Barn.app / com.pgsty.barn in Barn 0.9.1) with state under $BARN_HOME/mac (see the current macOS Guests guide and Mac Commands reference).

Following the rename on 2026-09-29, local CLI and barn-hosts-helper unit suites, native bridge/image/exit-prompt/menu tests, the runner bundle build, ad-hoc code-signature verification, and probe checks all passed, building on the full 16-phase live macOS VM acceptance run recorded earlier that day.

The rename record explicitly limits the renamed build’s evidence to those checks: its VM lifecycle was not replayed. The 2026-10-03 archive correction retained the original dates, versions, commits, and test scope rather than attributing earlier VM runs to the renamed build.

Remaining pre-0.9.0 release checks

At the 2026-09-29 checkpoint, the remaining pre-publication gates for 0.9.0 were:

• Full source, archive, DEB/RPM, installer, and four-platform checks on the final tagged commit.
• Fresh host setup and Linux/macOS VM lifecycle and cleanup verification under the renamed binary and paths.
• macOS Developer ID signing, notarization, and release publication.
• Verification of the public GitHub repository, Homebrew tap, official /barn image endpoints, and barn.pgsty.com.

Earlier Mac implementation records

• 2026-09-26–27: The initial implementation log records a full IPSW download and CLI restore, base-image immutability, dual-guest lifecycle tests, and installer rejection of a modified package. The final 12-stage run took 140.305 s starting with already initialized guests. It used the retired fixed-slot/shared-network implementation and an ad-hoc development signature.
• 2026-09-28: The complexity review retained identity, locking, and recovery safeguards while simplifying the implementation. Regression checks verified that readiness did not rewrite SSH material. An initial shutdown timeout coincided with high guest load; the full rerun passed without forced power-off or timeout changes. The record treats the load as an observation, not a proven cause.

Barn Mac native record: 2026-09-29

On 2026-09-29, the pre-rename development tree was validated on an Apple Silicon Mac running macOS 27.0 (26A428) using an ad-hoc signed development build and APFS clones of a base image prepared on 2026-09-26 from Apple’s pinned 27.0 restore image:

• Source and bundle checks: Full make check, native Swift component tests, and the Mac bundle build with extracted-archive checksum, signature, and probe checks passed.
• Automated 16-phase live acceptance (244.9 s): Verified VM creation from the base image, named VM creation with a VirtioFS shared folder, independent machine identities, sshd hardening, disk and per-VM subnet isolation, DNS, outbound HTTPS, exit-code propagation, exec argument boundaries, bidirectional shared-folder writes, clean stop/start, configure, enforcement of the two-VM running limit, recreate identity rotation, desktop window display, two-way plain-text clipboard sync, idempotent up, and destroy.
• Manual timing and recovery checks: First boot from a prepared base image reached SSH readiness in 22 s; clean shutdown completed in 6.5 s; subsequent starts reached SSH readiness in 6–12 s; forced power-off completed in 0.7 s. Also verified booting into macOS Recovery (--recovery), changing --subnet while preserving the pinned SSH host key, and connecting via ssh mac1 through installed ~/.ssh/barn-mac_config entries.

Items deferred to subsequent release milestones at that checkpoint:

• Developer ID signing, Apple notarization, and public distribution of the app bundle.
• End-to-end IPSW download + base preparation via first-time barn mac up or barn mac image update.
• Desktop menu Restart… and Shut Down… actions, additional Apple Silicon models, and host reboot persistence.

The same named-machine record includes a later 07ebfd4 candidate rerun: all 16 phases passed in 298.9 s after an initial five-second SSH probe failed and the guest answered on a later observation. Both runs reused an existing 26A428 base; fresh download and restore remained outside that checkpoint’s coverage.

Pre-rename Linux validation summary

In the 0.8.0 four-host acceptance run, each host booted Rocky Linux 9.8 and 10.2, Debian 12.15 and 13.7, and Ubuntu 22.04.5, 24.04.5, and 26.04.1 (28 guest VMs total, all passing and cleaned up afterward). Both official endpoints served catalog 2026092001 with SHA-256 23e8dbf6c19bd192d56c6d71eb30901f17945b3487e427a43abe108463780306, verified via isolated barn update runs and HTTP HEAD content-length checks on the 10 new image objects.

Open test items at the earlier checkpoint

• Rocky/EL9 hosts with NetworkManager + firewalld, and a fresh systemd-networkd host replay.
• Physical host reboot persistence across active deployments.
• Live hypervisor runs on darwin/amd64 and linux/arm64 hosts beyond cross-build and package verification.
• End-to-end el7 VM lifecycle replay on native linux/amd64.
• Full Pigsty configure → barn up → install.yml playbook execution.
• Fresh-host setup and VM creation driven end-to-end from the public download installer, Homebrew formula, or published DEB/RPM packages.

Barn verification history

Barn 0.8.0 — 2026-09-21

• Release CI and assets: Tag v0.8.0 (320a32afa8f6fca02592215aa0d5607ca4e852b2) passed source CI, the packaging snapshot workflow, and the release tag workflow, publishing 20 release assets (19 checksummed payloads). All 20 assets were downloaded anonymously and verified against the release checksums.txt manifest, and isolated user-prefix installs on darwin/arm64 and linux/amd64 verified 0.8.0 (320a32a).
• Homebrew tap: Commit 9c34019 updated pgsty/infra/barn to 0.8.0 across all four targets and passed local brew fetch, audit, and tap CI.
• Four-host 7-distro acceptance: Clean initialization was run at baseline commit 6d7870e26cb2f4082a00c188f746783fc027687e across two Linux amd64 hosts (m0, m3, installed from the .deb package) and two macOS arm64 hosts (m1, m5, installed from the verified archive), booting the 7-distro pro inventory from a local LAN repository. Runtime candidate 1c054a027420b5410c6f6feb344e27e001ae1af1 (adding the macOS Homebrew authentication-order fix) was then installed in place on all four hosts and verified across idempotent up (preserving running QEMU processes, VM UUIDs, and disk inodes), two rounds of guest SSH, stop/start, /data disk mounts, Debian locale/XFS checks, control-to-peer SSH, and Ansible inventory reads (ansible all -m ping on both Macs). See the 0.8.0 Release Notes for per-host timings.

Barn 0.7.0 release — 2026-09-16

• Release CI and assets: Commit 9c6d4896d93733d1cb60a7e5d8591e9a06659c9d (v0.7.0) passed source CI, the packaging snapshot workflow, and the release tag workflow. All 20 public release assets passed anonymous download and SHA-256 verification, public installer checks passed on darwin/arm64 and linux/amd64, and pgsty/infra/barn passed local brew upgrade and brew test.
• Ubuntu amd64/KVM storage & bootstrap recovery: Tested corrupt ext4/XFS data-disk resets (3.2 s recovery while keeping the QEMU process alive), persistent disk retention across recreate, transient probe failures and busy mounts (preserving existing disk data and UUIDs), read-only 9p share fallback, and resuming a 0.6.0 VM whose initial egress probe had failed (3.3 s recovery, surfacing the expected control-ssh warning where 0.6.0 had already removed the staged control key; see the 0.7.0 Release Notes). Catalog 2026090501 remained unchanged.

Barn 0.6.0 release — 2026-09-05

• Release CI and assets: Following lifecycle, UX, release-metadata, and CI fixture reviews, commit 057774e3a13477782a2ae07bd71127d03c0f1ae7 (v0.6.0) passed Go 1.27.1 source CI, packaging checks (13d9d70), and the release tag workflow, producing 20 verified release assets. An isolated darwin/arm64 installation verified upgrading from 0.5.0 to 0.6.0 via the public installer, plus barn init and barn plan.
• macOS arm64/HVF lifecycle acceptance: Verified initial boot, scale-out without restarting the control node, control-to-peer SSH, stop/start, reload, selective recreate, scale-in, guest /etc/hosts refresh, preflight rejection of invalid reload or conflicting partial recreate before stopping existing VMs, degraded status reporting, and SSH exit code 255 passthrough.
• Catalog 2026090501: Switched the default image to u24:stable and incorporated the Debian/Rocky updates from 2026090302 across all 27 verified qcow2 artifacts on both official endpoints.

Barn 0.5.0 release — 2026-09-03

Commit fc85b65ff6a24b0933b56ae1179be9ada2ba91b1 (v0.5.0) passed Go 1.27.1 source and GoReleaser packaging gates and published the 20-asset pre-release. 0.5.0 introduced confirmation-free whole-deployment barn purge, set https://repo.pigsty.io/barn as the global default repository with --mirror for https://repo.pigsty.cc/barn, removed implicit upstream URL fallback during artifact downloads, and added packaging/image-pipeline/build-official.py for the eight digest-pinned Debian/Rocky targets.

Barn 0.4.0 release — 2026-09-02

Passed make check and all release archive, DEB/RPM, SBOM, checksum, installer, and Homebrew formula gates. barn up gained automatic interactive host setup when run on an unprepared terminal host, vm_disks[].fs defaulted to auto, readiness errors began surfacing the last guest error line, and CLI output formatting was unified across commands.

Barn 0.3.0 release — 2026-09-02

Passed make check and all release packaging gates. Made catalog refreshes explicit via barn update and barn image sync, and added per-node failure stages and log inspection hints to guest readiness error messages.

Barn 0.2.0 release — 2026-09-01

Commit 59d1b62aebb3d044a317e4006cc8a0bf56f4feaf (v0.2.0) passed source CI, packaging workflows, and local four-platform archive, DEB/RPM, and SPDX verification. Live darwin/arm64 HVF acceptance verified selective u24-1 create/SSH/stop/start, incremental cached el9-1 creation, whole-deployment status, and destroy with SSH config cleanup. On Ubuntu 26.04 amd64/KVM, the Linux binary audited a running four-node deployment and connected to its control guest.

Schema-3 Catalog closure — 2026-08-29

Catalog 2026082903 (9 families, 27 artifacts, SHA-256 571b1ff9c7d4d42355df3392ea62a339471c2d01d868669a7625fac8b93f245d, signed by key 4686B39A40F9B562) passed byte-for-byte equality checks between the embedded catalog and published endpoints, a full SHA-256 sweep across all 27 qcow2 artifacts (19 GiB), and a clean-client d13:stable (409.3 MiB) download and qemu-img check on darwin/arm64.

0.1.0 candidates — 2026-08-28 and 2026-08-29

Validated two targeted fixes prior to 0.2.0:

• Targeted QMP recovery: When QMP sockets were externally removed from two of four running nodes on darwin/arm64, Barn restarted only the two affected nodes (13.7 s to readiness) while keeping the two healthy nodes’ boot IDs unchanged.
• QEMU-free catalog inspection: Decoupled barn image list and make check from requiring qemu-img on PATH when no local cached qcow2 files need inspection.

EL7/EL8 compatibility — 2026-08-28

Commit 7c666c7 restored el7 and el8 support with regression tests covering pre-recreate runtime preflight ordering and signed-catalog baseline migration. Catalog 2026082801 (9 families, 17 image artifacts, plus 2 socket_vmnet archives) passed full SHA-256 and signature checks, and an isolated darwin/arm64 run booted Rocky Linux 8.10 arm64 under the built-in TCG rule to SSH readiness in 44.2 s (verifying NetworkManager, fixed IP, dba UID/GID 88, and guest markers).

Native replay — 2026-08-27

Verified fixed-IP networking, SSH readiness, default CPU/memory/root/data disks, cloud-init, stop/start, cross-directory CLI invocations, control-node uptime preservation during scale-out, control-to-peer SSH, ignoring upper-layer Pigsty variables, and explicit-only node destruction across darwin/arm64 and linux/amd64 (mx). On Linux, also verified passwordless sudo automation, Debian qemu-bridge-helper group permissions, unprivileged bridge attachment, refusal to uninstall an active bridge with four attached tap interfaces, and clean network teardown after destroy.

7 - Barn 0.9.3 Changes

This page records the user-visible changes shipped in Barn 0.9.3 on 2026-10-31. The workflow changes began in source commit 27f17bb and were completed by the commits leading to the release. Check barn version when auditing another build.

See the Barn 0.9.3 release notes for the upgrade summary and the complete bilingual release note.

Resource changes and recovery

Edit vm_cpu or vm_mem and run barn resize [node...]. QEMU hot-plugs supported increases when the running VM has reserved capacity; decreases, older VMs, and unsupported backends use a stop/start fallback. The VM identity, disks, and SSH keys remain unchanged. resize refuses image, disk, network, share, creation, removal, and deployment-wide changes; use recreate, up, destroy, or a full selected operation as indicated by its next: field.

Linux and macOS lifecycle, persistent-disk, and replacement operations journal their transition state. If a process is interrupted or receives SIGINT or SIGTERM, the next lifecycle command can recover the operation; cancelled commands report the structured cancelled result. On macOS, barn mac up --no-wait returns when the VM process starts and may leave first-boot SSH and sudo provisioning running. Run barn mac up NAME again to wait for readiness.

Paths

barn init and setup work through directory symlinks. init -o ./lab/config/barn.yml also creates missing parent directories. Existing files still require --force, and writes never follow or replace an output-file symlink.

User-selected paths now accept normal development layouts:

CLI-relative paths, including a relative BARN_HOME, are interpreted from the current working directory. Use an absolute BARN_HOME to reach the same deployment from different directories. Barn still rejects / and the user’s home directory as data roots and checks the ownership and structure of its managed state. An owned ~/.ssh directory may be reached through a directory symlink; a linked ~/.ssh/config is still left for manual Include integration.

Shared folders and mount paths

Linux guests use QEMU Virtio-9p, now supported on macOS hosts as well as Linux hosts. QEMU and the guest kernel must support 9p. Native macOS guests continue to use VirtioFS through barn mac --share.

• Linux share sources use the invoking user’s actual filesystem permissions. A directory may belong to another user, overlap another source, or be writable by multiple guests. Coordinate concurrent writes as you would between host processes.
• Source paths support spaces, Unicode, and commas. Linux guest mount paths are normalized and escaped for shell commands and fstab, including spaces, Unicode, and shell punctuation.
• Mac share names support spaces and Unicode: valid UTF-8, 1–255 bytes, excluding ., .., /, and ASCII control characters. Share sources may be directory symlinks.
• The eight-share limit is removed. Backend device and host resource limits still apply. Linux sources must not overlap BARN_HOME, and mount targets must not overlap each other, system directories, data-disk mounts, or the guest SSH directory.

See Storage and Access for Linux shares and Mac Commands for native macOS shares. Barn never changes host ownership to make a share writable.

Apply only the selected node changes

Explicit selections in plan, up, reload, and recreate preserve unselected peers’ applied definitions, even if those peers were edited or omitted in the current inventory. Uncreated, unselected nodes do not require image resolution. This allows a multi-node edit to be applied in batches:

barn plan node-1 -f barn.yml
barn recreate node-1 -f barn.yml
barn plan node-2 -f barn.yml

The entire inventory must still parse correctly. Conflicts with applied addresses, aliases, control-node roles, or shared deployment settings are checked before stopping or deleting nodes. Omitting selectors evaluates the whole inventory; removing a YAML entry never deletes its VM. See Daily Operations.

Generated template image selection

barn init [template] --image <reference> writes an explicit vm_image under all.vars for every generated node. barn setup [template] --image <reference> uses the same behavior while preparing a generated template. References may be aliases, channels, or version selectors; the flag does not download an image. Existing inventories selected with -f or discovered automatically are never rewritten by this option.

Images and development limits

Provisioning still defaults to one worker and a one-hour deadline, with 1 MiB of captured stdout and stderr per node. These user-facing limits are separate from the internal VM startup scheduler. Image digests, declared sizes, qcow2 structure, retained-disk compatibility, and process identity are still verified. The contributor image pipeline retains its own recipe bounds.

8 - Barn 1.1.0 Local Acceptance

This run starts with the installed Barn 1.0.0, installs the public 1.1.0 Homebrew formula, checks upgrade and everyday workflows, then rebuilds the test environment. The script was written before execution. This run has ended: core checks passed, one recovery gap was found, and clipboard/privileged-host checks remain incomplete. The owner authorized deletion of existing local Barn VMs.

Environment and evidence

• Host: macOS 27.0.1, Apple Silicon, 18 logical CPUs, 128 GiB RAM; QEMU 11.1.3.
• Initial state: eight running Linux VMs and one running macOS VM named mac1; the normal executable is /opt/homebrew/bin/barn.
• Upgrade target: public tag v1.1.0, commit b2cc8da8983e710255d504bf26bf5d7b3f182790.
• Recordings, raw output, assertions, and executable scripts live in a separate acceptance directory outside Git. Each stage produces an asciicast v2 recording with original timing and a viewing copy with shortened waits.
• Linux checks use the actual user’s ~/.barn. Detailed native Mac checks reuse tests/mac-live-acceptance.py with a dedicated test root and an APFS clone of the prepared base; final checks cover the normal user path.
• Terminal recordings capture output without keyboard input, passwords, or private SSH keys. Desktop checks use native application controls; the screenshot is in the acceptance chat. Clipboard status is recorded below.

Execution order

Assertions and retries

Every command records arguments, exit status, duration, and raw output. Failed assertions preserve the environment. Script corrections create separate retry records; product defects are recorded independently. Failed footage remains available. Only viewing copies shorten waits.

The existing host network is checked and reused first. Operations requiring host sudo inspect actual authorization and the execution plan; unavailable checks are marked blocked. Apple OS image updates, physical Intel Macs, and Linux KVM are separate environment coverage.

Results and playback

This run ended at 11:08 on 2026-11-09 (Asia/Shanghai). The normal PATH resolves to public Barn 1.1.0. Upgrade recovery passed for the original eight Linux VMs and one Mac VM before their authorized deletion. All test VMs, the dedicated Mac data root, and the additional 120 GiB base were removed; the original default macOS base remains.

Stage results

Deleting the control node promotes a remaining node. After updating admin_ip in the inventory as instructed, creating the former node again reattached its retained disk and preserved the peer’s PID and data. With the old inventory requesting a control-role reversal, up correctly refused implicit recreation.

Image matrix

All nine configurations passed image acquisition, boot, SSH, OS/architecture checks, data writes, stop/start, and cleanup. -I/-A left the inventory file unchanged. EL7/arm64 returned usage / 2 because the catalog has no matching artifact. EL7/amd64 on this host returned capability / 3 without creating a deployment.

Readiness marker after forced termination

Immediately after successful recreation of an Ubuntu 24.04 arm64/HVF node, its verified QEMU process was forcibly terminated. The next up booted the guest, but both /var/lib/barn/ready.json and error.json were absent. SSH and persistent data worked and cloud-init had finished; up timed out after 180 seconds with exit 5. This observed recovery gap is preserved in 03-linux-lifecycle-r3 and 03-power-loss-investigation.

The following recovery restored readiness while preserving the running VM PID, its peer, and persistent data:

barn exec meta -- sudo -n /usr/local/libexec/barn-finalize
barn up meta -f barn.yml

In a second trial, the guest ran sudo sync before the process was terminated, again after checking its command line and QMP UUID. up recovered automatically. The immediate-interruption behavior was observed once under the stated conditions; persistence timing and other images need further investigation. Relevant 1.1.0 code is the readiness probe and guest-setup retry entry.

Checks not completed

• Bidirectional clipboard: native UI automation did not reliably inject the host system clipboard, and the browser tool has an isolated clipboard. Manual host input had not arrived when this run ended, so this remains unverified.
• Privileged host changes: sudo -n required a password, including access to root-owned network planning state. Existing network reuse, privilege-error classification, and read-only hosts plans were checked; network reinstall/uninstall and /etc/hosts writes were not executed.
• This host is Apple Silicon. Physical Intel Macs, Linux/KVM, and Apple OS image updates remain separate environment coverage.

Local evidence

Evidence lives at ~/barn-acceptance/1.1.0-20261109-101029/. Open player/index.html for offline playback of 23 asciicasts: approximately 58.9 minutes of original timing or 12.1 minutes in the viewing copies. Viewing copies change timestamps only; output bytes and SHA-256 are checked per recording. Terminal recordings do not contain desktop frames; the desktop screenshot is in the acceptance chat.

evidence/plan-before-execution.md and .zh.md preserve the original plan. Stage directories contain script snapshots, commands, exit codes, and raw output; findings.json records the recovery gap and incomplete checks. Initial footage and retries remain for script corrections involving Homebrew prompts, SSH aliases, create/recreate plan categories, control-role promotion, TCG parameters, and error classification. Full recordings stay local; this site contains the acceptance account.