AerynOS has shipped its first development update and new install images in three months, and the headline is a piece of packaging plumbing rather than a desktop feature. Versioned Repositories phase 2 is now deployed, which means the moss package manager can carry a system across a breaking change in its own on disk format during an ordinary update. No reinstall, no manual repository switch, no blog post telling users to run three commands in the right order. The project frames it as install once, update forever. Around it, the 2026.08 image adds experimental OpenZFS for data drives, moves systemd from 257.13 to 261.2, and ships Linux 7.1.5.
The short answer
AerynOS published its first development update since May on August 2, alongside a new 2026.08 install image. Versioned Repositories phase 2 is deployed, letting the moss package manager cross breaking on disk format changes during a normal update rather than through a migration users have to perform. moss also gained native reflink support on XFS, with an optional EROFS metadata image approach in development for ext4 and f2fs. Experimental OpenZFS support arrives for data drives next to btrfs and bcachefs. systemd jumps to 261.2 and is now split into sub packages, which changes network interface naming after a reboot. CDN77 is sponsoring content delivery.
Ask anyone who has maintained a distribution what they dread, and format migrations will come up quickly. The package manager needs to change how it stores things, every existing installation is on the old layout, and the only ways out have historically been a migration tool people forget to run or a blog post that begins with the word "before". AerynOS spent three quiet months making that problem go away, and published the result on August 2.
Versioned Repositories, and why the boring version matters
The feature is called Versioned Repositories phase 2, and what it buys is the ability to change the on disk format in a way that is breaking, and have existing systems arrive on the other side without their owners doing anything.
The mechanism is in the name. Repositories declare a format version, moss knows which versions it can read, and the upgrade path across a boundary is part of the sync rather than a separate ceremony. The project describes the outcome as users simply continuing to update their systems and receiving new features as part of the normal workflow, and calls the model install once, update forever.
For a distribution still in alpha, this is more consequential than it sounds. A project that cannot change its own format without stranding installations either stops changing the format or accepts that every change costs it users. Removing that constraint is what lets the rest of the roadmap stay open.
Storage work: reflink on XFS, EROFS for everyone else
moss composes a system root out of content addressed assets, which raises an obvious question: are those bytes on disk once or twice.
On XFS the answer is now once. moss gained native reflink support, so the filesystem shares extents between the store and the composed root instead of copying. That is the same trick btrfs users have benefited from, extended to a filesystem plenty of people already run.
For ext4 and f2fs, where reflink is not available, the project has an optional EROFS metadata image approach in development. Different mechanism, same goal: stop paying for identical data twice. It is worth noting this is described as in development rather than shipped, so ext4 users are not getting it in 2026.08.
The rest of the image
Experimental OpenZFS support arrives for data drives, joining btrfs and bcachefs. The scoping is deliberate and worth respecting: this is for pools you attach, not for the root of a system that composes itself atomically.
systemd moves from 257.13 to 261.2 and is now packaged as separate sub packages, so a minimal install can leave parts of it behind.
On kernels, the stable and gaming branches carry Linux 7.1.5 and the LTS branch carries 6.18.40. The NVIDIA driver is at 610.43.03 with improved DLSS support. Elsewhere in the package set: COSMIC 1.5.0, KDE Plasma 6.7.3, Mesa 26.1.6, Firefox 153.0.1, PHP 8.5.9, QEMU 11.0.3 and Wine 11.14.
Infrastructure got a boost too. CDN77 is now sponsoring content delivery across 130 countries, which the project ties to its interest in European digital sovereignty.
The one thing to check before you reboot
Buried in a systemd version jump is a change that will catch someone: network interface names.
Moving to systemd 261.2 brings a naming scheme change, and an interface that was eth0 can come back as enp0 after the reboot. Anything pinned to the old name goes with it. Firewall rules that name an interface, static network configuration, monitoring checks, a script that parses ip output looking for a specific device.
The failure mode here is unpleasant precisely because it is invisible until the machine is already back up with an interface nothing in your configuration mentions. Look at what you have pinned before you reboot, not after.
Where the project says it is going
The update is candid that the last few months went into foundations rather than features: build and packaging tooling, infrastructure, incremental Wayland and hardware work. The interesting sentence is about what comes next. The project says AerynOS has been deliberately kept on a very tight leash, and that now the ability to deliver updates seamlessly is secured, it will move into a more open and collaborative space.
That sequencing is defensible. Opening a project to contributors before you can ship a format change without breaking their machines mostly generates work for everyone. Doing it after is how a distribution grows.
It remains an alpha, and nothing here changes that. But an alpha that has solved its own upgrade problem is in a materially better position than one that has not.
Sources and further reading
- AerynOS: solid foundations are leading to expanding horizons
- Phoronix: AerynOS issues first development update and new ISOs in three months
- AerynOS project blog
- Our guide to choosing a Linux distribution in 2026
Frequently asked questions
What problem do Versioned Repositories actually solve?
Every package manager eventually needs to change the format of the data it stores on disk, and that change is normally the moment a distribution has to ask users to do something. Reinstall, run a migration tool, edit a repository file by hand, or wait for a special update that must be applied before any other. Versioned Repositories phase 2 lets moss recognise which format version a repository speaks and upgrade itself across a breaking boundary as part of a normal sync. The user side of the operation is that nothing happens: you update, and you are now on the new format. For a distribution still in alpha, being able to break your own format without breaking every installation is the difference between iterating and freezing.
What is moss and how does it differ from a conventional package manager?
moss is the package manager AerynOS has been building since 2020, and it is content addressed rather than file copying. Packages are stored as hashed assets and a system root is composed from them, which is what makes a transaction atomic and a rollback cheap. In this update moss gained native reflink support on XFS, which lets the filesystem share extents between the store and the composed root instead of duplicating data, and there is an optional EROFS metadata image approach in development for ext4 and f2fs users who do not have reflink. That is the same problem solved twice for different filesystems: avoid paying for the same bytes on disk more than once.
Is the OpenZFS support usable, and for what?
It is labelled experimental and it is scoped to data drives, sitting alongside the btrfs and bcachefs options the project already supported. That scoping is the important detail. Using OpenZFS for a pool of data you attach to an AerynOS machine is a very different risk profile from using it as the root filesystem of a distribution that composes system roots atomically, and the project is offering the first rather than the second. Treat it as a way to bring an existing pool along, not as an invitation to rebuild your root.
What breaks when I update to 2026.08?
One thing worth knowing before you reboot: network interface names change. The systemd move from 257.13 to 261.2 brings a naming scheme change, so an interface that was eth0 can come back as enp0 after the reboot. If you have anything pinned to an interface name, firewall rules, a static configuration, a script that greps ip output, that is where it will bite. Check it before you reboot rather than after, because the machine will come up with an interface your configuration does not mention. systemd is also now split into sub packages, so a minimal install can leave parts of it out.
Is AerynOS ready for production use?
No, and the project does not claim it is. AerynOS is an alpha distribution, and this update is explicit that the effort of recent months went into build tooling, packaging and infrastructure rather than user visible features. What the update does signal is that the foundations are considered settled enough to open up: the post says the project has been kept on a tight leash and is now deliberately moving toward a more open and collaborative space. That is a reasonable moment to try it on a spare machine, contribute packaging, or watch it. It is not a reason to put it under anything you need on Monday.