# Farrow 0.8.0: clearer recovery and refreshed images > Recover host preparation, isolate failed nodes, preserve VM identities, and start the September Debian and Ubuntu images. --- LLMS index: [llms.txt](/llms.txt) --- Farrow 0.8.0 reduces manual work after interrupted setup and partial VM starts. It also refreshes the Debian and Ubuntu images while retaining every previous Catalog artifact and the identity of existing VMs. ## What changed - **Host preparation follows the command.** Interactive `start`, `restart`, and `reload` can prepare missing host tools and restore an intact Farrow network. On macOS, new network installation completes Homebrew discovery/installation or the verified archive download before requesting administrator authentication, so Homebrew cannot invalidate a credential acquired too early. - **A failed node does not block independent peers.** A missing host share fails its own node during `up` or `start`; stopped peers can still start when a new node fails to prepare. Errors name the source and mount, and Farrow does not create an empty replacement. Restart/reload/recreate check share access before stopping existing VMs. - **Recovery preserves identity.** A missing public key is derived from the original private key. A lost private key produces backup-recovery guidance instead of a new login identity. macOS vmnet log-directory recovery retains network ownership evidence and avoids false subnet-conflict reports. - **Failures keep their context.** Scoped retry commands preserve the inventory, repository, and applicable flags; a `start` retry remains `start`. Setup and its retry share one operation ID, and bounded event logs work before deployment state exists. Uncached image information no longer requires QEMU. - **Cleanup reports the final result.** Explicit persistent-disk deletion and purge no longer describe disks as both retained and deleted. Owned disks left by a previously removed node do not block destruction of the remaining lab. ## September images Embedded Catalog `2026092001` contains 37 artifacts across nine families, including all 27 previous artifacts. These new stable versions cover amd64 and arm64: | Family | System version | Catalog version | |---|---|---| | `d12` | Debian 12.15 | `20260909.2596.1` | | `d13` | Debian 13.7 | `20260914.2601.1` | | `u22` | Ubuntu 22.04.5 | `20260913.0.0` | | `u24` | Ubuntu 24.04.5 | `20260911.0.0` | | `u26` | Ubuntu 26.04.1 | `20260918.0.0` | Debian keeps the offline XFS tools and generated `en_US.UTF-8` locale, with `C.UTF-8` as the default. Ubuntu keeps Canonical's original image bytes; deployment accounts and networking are configured by cloud-init. Existing VMs and explicitly pinned image versions keep their original bases. See [Images](../../../docs/reference/images/) for repository and update behavior. ## Install or upgrade ```bash curl -fLO https://github.com/pgsty/farrow/releases/download/v0.8.0/install.sh chmod +x install.sh FARROW_VERSION=0.8.0 ./install.sh export PATH="$HOME/.local/bin:$PATH" farrow version ``` For an existing lab, review `farrow plan` and then run `farrow up` from its inventory directory. On first use, run `farrow up` in a terminal to prepare the host and create the default lab. Farrow remains pre-1.0 and uses GitHub's pre-release channel; keep the explicit `FARROW_VERSION`. The release includes macOS/Linux amd64/arm64 archives, Linux DEB/RPM packages, checksums, SBOMs, the installer, and a Homebrew formula. Other installation methods are in the [Quick Start](../../../docs/start/tutorial/#install). `start` still powers on existing nodes; `up` applies the inventory and retries unfinished guest setup. No separate repair command is required. The existing test-data reset policy is unchanged: confirmed unusable test filesystems can be cleared, including persistent data disks, with an explicit data-loss notice. Missing devices, failed probes, busy mounts, or host I/O errors do not authorize formatting; root disks and host shares stay outside that recovery path. ## Validation and limits Four hosts completed the seven-system pro path: two macOS arm64/HVF hosts and two Linux amd64/KVM hosts, each with Rocky Linux 9.8/10.2, Debian 12.15/13.7, and Ubuntu 22.04.5/24.04.5/26.04.1. The baseline candidate `6d7870e` performed clean initialization from the LAN repository. Runtime candidate `1c054a0` then passed in-place installation, healthy repeated `up`, stop/start, two rounds of guest SSH, data-disk access, Ansible configuration reads, and control-node SSH. Both Macs also passed Ansible ping on all seven nodes. VM UUIDs, image identities, and healthy root/data disk paths and inodes were retained. The temporary acceptance VMs were subsequently cleaned up. The following are single measurements, not a performance distribution. The first `up` includes image download: | Host | Platform | Clean first up at 6d | Healthy up at 1c | Existing-disk start at 1c | |---|---|---:|---:|---:| | m0 | Linux amd64 / KVM | 117.915 s | 3.924 s | 36.944 s | | m1 | macOS arm64 / HVF | 86.309 s | 1.745 s | 39.639 s | | m3 | Linux amd64 / KVM | 98.443 s | 2.169 s | 44.068 s | | m5 | macOS arm64 / HVF | 87.946 s | 1.467 s | 38.162 s | The release tag points to `320a32afa8f6fca02592215aa0d5607ca4e852b2`, which changes only README and release notes relative to the tested runtime. Complete local `make check` and release archive/package verification passed. The [source CI](https://github.com/pgsty/farrow/actions/runs/35568664994), independent [packaging snapshot](https://github.com/pgsty/farrow/actions/runs/35568664948), and [tag workflow](https://github.com/pgsty/farrow/actions/runs/35569143101) all passed; the tag workflow produced 20 release assets, including 19 checksummed payloads. The [release is public](https://github.com/pgsty/farrow/releases/tag/v0.8.0) on GitHub's pre-release channel. All 20 anonymous downloads returned HTTP 200; their full SHA-256 digests match the GitHub API and inspected draft, and all 19 payloads match `checksums.txt`. The [UX audit](https://github.com/pgsty/farrow/blob/v0.8.0/UX-AUDIT-0.8.md) and [image refresh record](https://github.com/pgsty/farrow/blob/v0.8.0/IMAGE-REFRESH-20260920.md) preserve the earlier regression, image-boot, and upgrade evidence. Both official image repositories serve the same signed Catalog as the release. An isolated `farrow update` against each endpoint verified its signature and activated revision `2026092001`. All ten new image objects at each endpoint returned HTTP 200 with matching content lengths; this was not a fresh full-body hash check of every public qcow2. The public installer completed isolated user-directory installations on macOS arm64 and Linux amd64. Both CLIs reported 0.8.0 / `320a32a`, and the installed CLI/helper bytes matched their verified public archives. The Linux download used a temporary SSH loopback forward to the existing proxy, removed afterward. Default installations and VM/network state were unchanged. These checks verify binary delivery; fresh host setup and VM boot through the public installer remain untested. The [Homebrew tap update](https://github.com/pgsty/homebrew-infra/commit/9c3401958a435248ebf0e5402e7efff712ee1c4c) provides 0.8.0 with all four archive checksums matching the public release. Local formula checks, strict online audit, and native arm64 `brew fetch` passed. [Homebrew CI](https://github.com/pgsty/homebrew-infra/actions/runs/35570285428) also passed its metadata, updater, style, platform, and audit checks on macOS and Linux. No new Homebrew install, upgrade, or `brew test` was performed. This is a clean 6d baseline followed by a 1c lifecycle replay, not a second clean initialization at 1c. The Homebrew authentication-order regression fails before the fix and passes after it; its fresh formula-install path was not replayed natively after the fix. Native macOS setup used the verified LAN backend archive. Physical-host reboot, a complete Pigsty installation, and native macOS amd64 or Linux arm64 operation remain outside this run. **macOS directory sharing remains unavailable with the tested QEMU directory descriptor behavior.** The new preflight improves diagnosis; it does not add sharing support. The pro inventory used no host shares. A missing control-node guest private key is now reported even if an old ready marker exists, but automatic private-key reinjection is still not implemented. Management SSH can remain usable while peer SSH carries that limitation. See [Status](../../../docs/about/status/) for the full dated matrix.