AerynOS 2026.08 ajoute le support OpenZFS et fait évoluer Moss vers l’auto-mise à jour
Début août 2026, AerynOS publie son image 2026.08, qui ajoute un support OpenZFS expérimental, finalise la phase 2 des dépôts versionnés et découpe systemd en paquets séparés. C’est la démonstration qu’une rolling release à mises à jour atomiques peut rester prévisible.
2 août 2026. AerynOS publie son image 2026.08, une distribution rolling release indépendante qui s’appuie sur le gestionnaire de paquets moss, des mises à jour atomiques avec retour arrière et un système de build nommé boulder. L’image suit la mise à jour du flux unstable qui avait introduit le noyau Linux 7.1.5, le bureau COSMIC 1.5 et Mesa 26.1.6.
Cette sortie n’a rien de spectaculaire, et c’est précisément son intérêt. Elle montre qu’une distribution en publication continue peut rester prévisible — un exploit dans un monde où « rolling release » rime trop souvent avec « surprises à chaque mise à jour ».
Ce qu’est AerynOS, en bref
AerynOS est une distribution rolling release indépendante, pensée pour le poste de travail mais construite autour d’une promesse de prévisibilité. Son identité tient en quatre briques : le gestionnaire de paquets moss, les mises à jour atomiques avec possibilité de retour arrière, le système de build boulder, et une gestion de démarrage EFI soignée.
Le modèle diffère d’une Arch Linux ou d’une openSUSE Tumbleweed sur un point précis : l’atomicité. Là où une rolling release classique applique les paquets un à un — avec le risque de laisser le système dans un état intermédiaire si la mise à jour est interrompue — AerynOS bascule vers un état complet, et peut revenir en arrière en cas de problème. C’est le même contrat que Fedora Silverblue ou openSUSE MicroOS proposent avec rpm-ostree, mais appliqué à une distribution qui construit ses propres paquets avec moss et boulder.
L’image 2026.08 est l’occasion de mesurer si ce contrat tient dans la durée — et les chantiers de cette version (dépôts versionnés, découpage de systemd) montrent que l’équipe travaille précisément sur la pérennité du modèle.
OpenZFS expérimental, aux côtés de Btrfs et Bcachefs
La nouveauté la plus visible est l’arrivée d’un support expérimental d’OpenZFS. AerynOS sait désormais travailler avec des disques de données OpenZFS, en complément de Btrfs et de Bcachefs déjà pris en charge pour les volumes gérés par l’utilisateur.
Le qualificatif « expérimental » n’est pas décoratif. L’implémentation n’a été testée que sur un matériel limité, et l’équipe demande explicitement un retour des premiers utilisateurs. Il ne s’agit donc pas d’un feu vert pour migrer un pool de production, mais d’un signal de direction : AerynOS se positionne comme une distribution capable de jouer sur plusieurs systèmes de fichiers à la fois, ce qui est rare dans l’écosystème des rolling releases grand public.
Pour un homelab, la conséquence est concrète : on peut désormais évaluer OpenZFS — snapshots, checksums, compression — sur une distribution à mises à jour atomiques, sans devoir passer par une distribution serveur classique.
Le cas d’usage type est le stockage de données qui doit survivre à la machine : un pool ZFS avec snapshots automatiques et scrub périodique offre une assurance contre la corruption silencieuse que ni ext4 ni un simple volume monté ne donnent. Combiné aux mises à jour atomiques d’AerynOS, cela dessine une machine qui tolère à la fois une mise à jour ratée et un disque fatigué — deux pannes qu’un homelab rencontre tôt ou tard.
Les dépôts versionnés, phase 2 : Moss se met à jour tout seul
Sous le capot, le changement le plus structurant est l’achèvement de la phase 2 des dépôts versionnés. Introduit au flux unstable début juillet, ce travail redessine la disposition du dépôt sur disque et fait passer la configuration de moss au format KDL.
La conséquence est de taille : moss peut désormais se mettre à jour lui-même à travers des changements de format de dépôt incompatibles, sans migration manuelle. L’utilisateur n’a plus qu’à lancer ses mises à jour habituelles. C’est le rapprochement avec le modèle « install once, update forever » que la distribution revendique — un système qu’on installe une fois et qu’on met à jour indéfiniment, sans réinstallation de rupture.
moss gagne aussi des contrôles de fiabilité sur les artefacts téléchargés dans son stockage adressé par contenu. Ces vérifications peuvent légèrement ralentir certaines opérations, mais elles garantissent que les fichiers en cache sont bien téléchargés et stockés correctement — un garde-fou contre la corruption silencieuse.
systemd 261.2 : le paquet éclaté, les interfaces renommées
La refonte du paquetage de systemd est l’autre chantier notable. AerynOS passe de systemd 257.13 à systemd 261.2, en découpant les composants en paquets séparés : systemd-boot, systemd-coredump, systemd-homed, systemd-container, systemd-resolved et systemd-udev sont désormais distribués individuellement.
Deux conséquences pratiques à connaître avant la mise à jour. D’une part, les services activés ou désactivés manuellement ne devraient plus voir leur état écrasé lors des opérations de paquets moss — une correction qui élimine une source classique de régressions silencieuses. D’autre part, les noms des interfaces réseau peuvent changer après le prochain redémarrage, par exemple de eth0 vers un nom prédictible comme enp12s0. Avant de redémarrer un serveur, un rapide contrôle s’impose :
ip link showC’est le genre de détail qui casse une configuration réseau si on l’ignore. Sur un poste de bureau, l’impact est minime ; sur une machine qui porte des règles de pare-feu ou des ponts, il faut vérifier.
Le reste du lot : XFS, NVIDIA et Codeberg
Trois autres points complètent le tableau.
- Reflinks natifs sur XFS : plusieurs fichiers peuvent pointer vers les mêmes données sans copie complète. Sur les systèmes sans support des reflinks, comme ext4 ou F2FS, AerynOS retombe sur des liens physiques.
- Pilote NVIDIA 610.43.03 : il atterrit dans les dépôts avec un meilleur support DLSS et des correctifs de veille et de reprise, et l’équipe cherche des testeurs sur matériel NVIDIA.
- Évaluation de Codeberg : le développement du site repensé est déplacé sur Codeberg pour évaluer la plateforme comme alternative à GitHub, avant une éventuelle migration plus large.
Enfin, AerynOS prévoit de remplacer son format de recettes de paquets YAML par un schéma KDL, ce qui gèle l’ajout de fonctionnalités au format actuel, considéré comme transitoire.
À qui s’adresse AerynOS, et à qui il ne s’adresse pas
AerynOS n’est pas un remplaçant de Debian sur un serveur de production, et ne prétend pas l’être. Son terrain de jeu, c’est le poste de travail et le homelab : l’utilisateur qui veut la fraîcheur d’une rolling release sans l’anxiété qui va avec — celui qui tournerait sinon sous Arch ou Tumbleweed, mais qui préfère un filet de sécurité atomique.
Trois profils en tirent un bénéfice direct. Les utilisateurs de bureau qui veulent un noyau récent (7.1.5) et un Mesa à jour sans réinstaller à chaque cycle. Les homelabbers qui veulent expérimenter ZFS, Btrfs ou Bcachefs sur une seule machine. Et les bidouilleurs qui suivent l’outillage moss/boulder, réellement différent de rpm ou dpkg.
À qui il ne s’adresse pas : les équipes qui exigent une LTS constructeur, un OS serveur certifié, ou un catalogue de paquets très large. AerynOS est jeune, son catalogue est plus restreint que Debian ou Fedora, et les fonctions expérimentales comme OpenZFS ne sont pas encore de qualité production. Ce n’est pas une critique : c’est le prix à payer pour regarder une distribution construire son modèle en public.
Verdict
AerynOS 2026.08 est une sortie de consolidation, et c’est une bonne nouvelle. La distribution prouve que le modèle « rolling + atomique » peut s’accompagner d’une vraie discipline d’ingénierie : dépôts versionnés, auto-mise à jour de moss, découpage de systemd en paquets propres.
Si vous cherchez un poste de bureau rolling avec mises à jour atomiques et retour arrière, AerynOS mérite une machine de test — l’installation réseau permet de choisir GNOME, KDE Plasma 6.7.3 ou COSMIC 1.5.
Si vous voulez évaluer OpenZFS sur ce type de distribution, traitez-le comme expérimental : réservez-le à des disques de données non critiques et remontez vos observations, pas vos pools de production.
Sur un serveur, appliquez la mise à jour avec précaution : vérifiez les noms d’interfaces réseau après redémarrage et gardez un œil sur les services systemd que vous aviez configurés à la main.