AerynOS 2026.08 adds OpenZFS support and moves Moss toward self-updating
In early August 2026 AerynOS published its 2026.08 image, adding experimental OpenZFS support, completing phase 2 of its versioned repositories and splitting systemd into separate packages. It is a demonstration that an atomic rolling release can stay predictable.
August 2, 2026. AerynOS shipped its 2026.08 image, an independent rolling-release distribution built around the moss package manager, atomic updates with rollback and a build system called boulder. The image follows the unstable stream update that introduced the Linux 7.1.5 kernel, the COSMIC 1.5 desktop and Mesa 26.1.6.
Nothing about this release is flashy, and that is precisely the point. It shows that a rolling distribution can stay predictable — no small feat in a world where “rolling release” too often rhymes with “a surprise on every update”.
What AerynOS is, in brief
AerynOS is an independent rolling-release distribution, aimed at the desktop but built around a promise of predictability. Its identity rests on four pillars: the moss package manager, atomic updates with rollback, the boulder build system, and careful EFI boot management.
The model differs from Arch Linux or openSUSE Tumbleweed on one precise point: atomicity. Where a classic rolling release applies packages one by one — risking an intermediate state if an update is interrupted — AerynOS switches to a complete state and can roll back if something goes wrong. It is the same contract that Fedora Silverblue or openSUSE MicroOS offer through rpm-ostree, but applied to a distribution that builds its own packages with moss and boulder.
The 2026.08 image is a chance to measure whether that contract holds over time — and this release’s projects (versioned repositories, the systemd split) show the team working precisely on the durability of the model.
Experimental OpenZFS, alongside Btrfs and Bcachefs
The most visible addition is experimental OpenZFS support. AerynOS can now work with OpenZFS data drives, alongside the Btrfs and Bcachefs already supported for user-managed volumes.
The “experimental” qualifier is not decorative. The implementation has only been tested on limited hardware, and the team explicitly asks early adopters for real-world feedback. This is not a green light to migrate a production pool; it is a direction signal — AerynOS is positioning itself as a distribution that can play across multiple filesystems at once, still rare among consumer rolling releases.
For a homelab, the consequence is concrete: you can now evaluate OpenZFS — snapshots, checksums, compression — on an atomic-update distribution, without reaching for a classic server distro.
The typical use case is data storage that must outlive the machine: a ZFS pool with automatic snapshots and periodic scrub offers insurance against silent corruption that neither ext4 nor a plain mounted volume provides. Combined with AerynOS atomic updates, that sketches a machine that tolerates both a botched update and a tired disk — two failures a homelab hits sooner or later.
Versioned repositories, phase 2: Moss updates itself
Under the hood, the most structural change is the completion of phase 2 of the versioned repositories. Introduced to the unstable stream in early July, this work redraws the on-disk repository layout and moves the moss configuration to the KDL format.
The consequence is significant: moss can now update itself across incompatible repository-format changes, with no manual migration. Users simply run their normal updates. It is a step toward the “install once, update forever” model the distribution claims — a system you install once and update indefinitely, with no breaking reinstall.
moss also gains reliability checks on assets downloaded into its content-addressable storage. These checks may slightly slow some operations, but they guarantee that cached files are downloaded and stored correctly — a safeguard against silent corruption.
systemd 261.2: the package split, and renamed interfaces
The systemd packaging overhaul is the other notable project. AerynOS moves from systemd 257.13 to systemd 261.2, splitting components into separate packages: systemd-boot, systemd-coredump, systemd-homed, systemd-container, systemd-resolved and systemd-udev are now distributed individually.
Two practical consequences matter before you update. First, services you enabled or disabled by hand should no longer have their state overwritten during moss package operations — a fix that removes a classic source of silent regressions. Second, network interface names may change after the next reboot, for example from eth0 to a predictable name like enp12s0. Before rebooting a server, a quick check is in order:
ip link showThat is the kind of detail that breaks a network configuration if you ignore it. On a desktop, the impact is minor; on a machine carrying firewall rules or bridges, it needs verification.
The rest of the batch: XFS, NVIDIA and Codeberg
Three further points round out the picture.
- Native reflinks on XFS: several files can point to the same data without a full copy. On filesystems without reflink support, such as ext4 or F2FS, AerynOS falls back to hardlinks.
- NVIDIA driver 610.43.03: it lands in the repositories with improved DLSS support and sleep/resume fixes, and the team is looking for testers on NVIDIA hardware.
- Codeberg evaluation: development of the redesigned site is moving to Codeberg to assess the platform as an alternative to GitHub, ahead of a possible wider migration.
Finally, AerynOS plans to replace its YAML package-recipe format with a KDL schema, freezing new features in the current format, which is now considered transitional.
Who it is for, and who it is not for
AerynOS is not a drop-in replacement for Debian on a production server, and it does not pretend to be. Its sweet spot is the desktop and homelab operator who wants the freshness of a rolling release without the anxiety — someone who would otherwise run Arch or Tumbleweed but wants an atomic safety net.
Three profiles benefit directly. Desktop users who value a current kernel (7.1.5) and up-to-date Mesa without reinstalling every cycle. Homelab operators who want to experiment with ZFS, Btrfs or Bcachefs on one machine. And tinkerers following the moss/boulder tooling, which is genuinely different from rpm or dpkg.
Who it is not for: teams that need a vendor LTS, a certified server OS, or a very large package archive. AerynOS is young, its package set is smaller than Debian or Fedora, and experimental features like OpenZFS are not yet production-grade. That is not a criticism; it is the price of watching a distribution build its model in the open.
Verdict
AerynOS 2026.08 is a consolidation release, and that is good news. The distribution proves that the “rolling + atomic” model can come with real engineering discipline: versioned repositories, self-updating moss, and a clean split of systemd into individual packages.
If you want a rolling desktop with atomic updates and rollback, AerynOS deserves a test machine — the network-based installer lets you choose GNOME, KDE Plasma 6.7.3 or COSMIC 1.5.
If you want to evaluate OpenZFS on this kind of distribution, treat it as experimental: keep it to non-critical data drives and report your observations, not your production pools.
On a server, apply the update with care: check network interface names after a reboot and keep an eye on the systemd services you configured by hand.
In short, AerynOS is converging on the promise that boring updates and a rolling cadence can coexist — and 2026.08 is the most convincing evidence yet.