Synex 13 Immutable Alpha 1: Transactional Btrfs on Debian

Synex 13 Immutable Alpha 1: Transactional Btrfs on Debian

Contents

• What Synex Immutable actually is

• How a transactional update really works

• What Alpha 1 guarantees — and what it doesn't

---

On 28 September 2026, the Synex project published the first public image of its most ambitious edition to date. Synex 13 Immutable Alpha 1 does not simply flip the root filesystem to read-only and call the job done. It rebuilds the operating system around bootable Btrfs generations, prepares every change in isolation from the running system, and publishes a new generation only after dpkg, the kernel, the initramfs and the bootloader have all been validated. We ran the alpha in a virtual machine and walked the full create–update–seal cycle by hand. This is what we found.

What Synex Immutable actually is

Synex Immutable began life as a question rather than a blueprint. The project studied a clean installation of openSUSE MicroOS and reached a conclusion worth repeating: a transactional system is much more than a root partition mounted read-only. MicroOS earns its atomicity through a stack of cooperating pieces — generations, a separate modifiable future system, a package database that travels with each snapshot, versioned configuration, and a bootloader that understands the model. Synex kept those properties but deliberately did not copy the MicroOS layout or its tools. There is no OSTree, no image-based deployment, and no replacement for APT or dpkg. Instead, the team built its own transactional engine on top of Debian 13 "Trixie", Btrfs, GRUB and Calamares. In our test image the base sat at Debian 13 update level u12, with KDE Plasma 6.3.6 on Wayland and kernel 6.12.107, exactly as the project's documentation describes.

The unit of change is not a file and not a package. It is a generation. Every bootable system state lives at @immutable-generations/gen-NNNN, and once published its root is marked read-only. Crucially, each root is paired with a matching STATE subvolume, @immutable-state/gen-NNNN, and one is never allowed to exist without the other. STATE holds the administrative machinery that must advance or roll back together with the software: /etc, the dpkg database, the APT state, ucf, DKMS, the debconf cache and the metadata used by systemd's helpers. The reason is coherence. If the package database lived in a single global /var, booting an older generation would leave you with old binaries and a newer package database describing software that is no longer there. By keeping that metadata inside the generation, Synex guarantees that what is installed and what the package manager believes is installed always agree.

Three classes of state coexist on a running system. The generational system itself — /usr, /bin, /lib, /sbin and the kernel and initramfs under /boot — is read-only and changes only when you change generations. The generational administrative state in STATE is writable where it needs to be, most notably /etc, which remains fully writable at runtime while still belonging to its generation. Everything else is persistent and lives outside the generations entirely: /var, /home, /root, the shared GRUB directory under /boot/grub, and a tmpfs for /tmp. The payoff is deliberate. Rolling the system back never touches your documents, your profiles, your logs or your application databases. System rollback and persistent-data rollback are different things, and Synex treats them that way.

The running generation is never inferred from the highest number on disk. Its identity is carried on the kernel command line as synex_immutable=1 together with an explicit rootflags=subvol=@immutable-generations/gen-NNNN. That single design choice is what lets older generations remain bootable without confusing the manager, and it is why you can boot gen-0001 from the boot menu even when gen-0005 exists. During early boot, an initramfs hook reads that marker, mounts the top-level STATE at /.synex-state, verifies that the matching /etc exists, and bind-mounts it read-write over the new root. Later, a systemd unit waits for /var, then overlays the dpkg and APT paths from that same generation on top of the persistent /var and leaves them read-only. The effect is a system whose package-manager metadata is tamper-evident in normal use, yet fully modifiable inside a controlled transaction.

Two packages carry the whole architecture. synex-immutable is the engine: it detects and validates the active layout, enumerates and creates generations, runs APT inside the single pending generation, seals and publishes generations, discards pending work, and supplies both the initramfs hook and the GRUB generator. calamares-settings-synex-immutable is the installation adapter. The installer offers only Btrfs in this alpha — manual partitioning, LVM and ZFS are disabled — and it first unpacks the system into a temporary staging root called @. At the end of installation, Synex-specific Calamares modules snapshot that staging root into gen-0001, build its paired STATE with a complete /etc and the full STATE v2 layout, seal the generation, publish and validate GRUB, and only then delete the staging @ entirely. The installed machine is left with no conventional mutable root hiding outside the generational model. Both UEFI, which requires a real FAT ESP, and legacy BIOS boot are supported.

Synex Package Manager has a clearly defined role on this edition, and it is not to touch the base system. In the alpha it manages Flatpak applications and Flatpak configuration — our test machine reported Flatpak 1.16.6 ready with two user and two system remotes — while APT operations on the base system are performed exclusively through synex-immutable. The plan is for the package manager to detect the immutable variant automatically and expose only the functions compatible with it, keeping the boundary between user applications and the transactional base crisp.

---

How a transactional update really works

The workflow is deliberately explicit and it is worth walking through, because every step is designed so that a failure cannot touch the running system. It starts with synex-immutable create. The command snapshots the generation that is actually active — not necessarily the one with the highest number — into a new pending generation whose root and STATE are both read-write, adjusts that generation's fstab to point at itself with the read-only flag, and verifies that the active generation did not change underneath it. Only one pending generation may exist at any time; a second create is rejected until the first is sealed or discarded. Numbering always advances from the highest existing generation and gaps are never reused, so branching from an older state never overwrites later history.

With a pending generation in place, synex-immutable apt accepts the familiar verbs — update, install, remove, purge, upgrade and full-upgrade — but APT never sees the active root. The engine first enters a private mount namespace with unshare and marks / as private, so transaction mounts cannot leak into the live system. It then builds a transactional chroot in which the pending root, pending /etc and the pending dpkg and APT databases are all writable together. The persistent /var is exposed so that maintainer scripts behave normally, but the critical administrative paths are overlaid from the pending STATE. Your home directory, the persistent root home, the shared GRUB state and the EFI system partition are deliberately not mounted: the transaction is allowed to modify the future system, never the running session or the persistent bootloader.

Two small details reveal how much thought has gone into the chroot. A temporary policy-rc.d returning exit code 101 is installed for the duration of the transaction, which stops Debian maintainer scripts from starting or restarting services inside the chroot; any pre-existing policy-rc.d is preserved and restored afterwards. And because the chroot gets its own fresh tmpfs for /run, the engine detects when /etc/resolv.conf is a symlink into /run and copies the resolver data across, so APT can still fetch packages without handing the transaction your entire live /run. Local .deb files are validated, copied into the transaction's own tmpfs and installed from there, so the staging file vanishes when the transaction unmounts. After every APT operation the engine runs dpkg --audit with captured output; any inconsistency at all means the generation is not considered ready to seal.

Sealing is where Synex earns the word "transactional". synex-immutable seal gen-NNNN cannot touch the active generation, cannot seal an already read-only root, and refuses to run while transactional mounts are still alive. Before it changes anything it runs through a long validation checklist: root and STATE must both exist and be Btrfs subvolumes; STATE must be a complete v2 layout; that generation's fstab must be a regular file pointing exactly at the generation being sealed and must contain the read-only flag; /boot must exist with at least one coherent kernel and initramfs pair; the initramfs hook must be present, executable and syntactically valid, and every initramfs image must contain it; dpkg --audit must be clean. Only then does it sync, mark the root read-only, run update-grub, validate the resulting configuration with grub-script-check, and verify that a menu entry for that exact generation with the correct rootflags actually appeared. If anything fails after the root has been marked read-only, Synex rolls it back to writable and regenerates GRUB to remove the half-published entry. A sealed generation is therefore not merely read-only; it is read-only, bootable and published.

GRUB is a first-class citizen of the architecture. A dedicated generator, 09_synex-immutable, mounts the Btrfs top-level read-only, enumerates generations sorted newest-first, and emits an entry only for those that pass every bootability test — read-only root, writable paired STATE, a valid fstab, a matching kernel and initramfs. Pending generations and inconsistent pairs are silently excluded. Each entry points directly at the kernel and initramfs inside its own generation, and with GRUB_DEFAULT=0 the most recently sealed generation becomes the normal boot choice. The standard 10_linux generator, which would otherwise create entries that boot a non-generational root, is disabled in a controlled way using dpkg-statoverride rather than being edited, because the file belongs to grub-common. Synex tracks whether it created that override and only removes it on uninstall if it did.

We exercised the whole cycle in our test VM. Starting from gen-0001, the status command reported the active STATE, a writable /etc, a complete v2 layout, persistent /var, /home and /boot/grub, a tmpfs /tmp, and architecture validation OK. create produced gen-0002 as pending, apt update ran cleanly inside it, and seal gen-0002 reported the root read-only and STATE writable before listing both generations — gen-0001 active, gen-0002 sealed. On reboot the GRUB menu offered both Synex Immutable-gen-0002 and Synex Immutable-gen-0001, exactly as designed. The read-only root was visible in the system's own disk output as a btrfs mount flagged read-only, and the familiar Synex desktop — 1,608 dpkg packages, the Breeze-dark theme, Firefox ESR and the Konsole terminal — behaved exactly as it does on the classic mutable edition.

Rollback in this first alpha is equally explicit. There is no rollback command yet; returning to an earlier state means booting a previous sealed generation from the GRUB menu. If you then create a new generation, it is derived from the older generation you booted, not from the newest number on disk, which lets you recover from a bad update without destroying the intervening history. One known limitation deserves to be named plainly: /etc is snapshotted at the moment create runs. If you manually edit configuration on the active system after a pending generation already exists, those later changes are not merged into the pending generation the way MicroOS's syncpoint mechanism would. Synex documents this as a deliberate gap for a future release. The atomicity boundary is likewise system-level rather than machine-wide: a maintainer script may still write to persistent paths such as /var/log or an application's own directory under /var/lib, and those side effects do not disappear if a transaction is later discarded.

---

What Alpha 1 guarantees — and what it doesn't

The guarantees the project is willing to make are structural and specific. The active generation always has a read-only root. Every generation has a paired STATE. /etc is writable but generational. The dpkg database and the main APT state follow the generation. Only one pending generation is ever writable, and supported APT operations happen outside the active root. Services are never started inside a transaction. Pending generations are audited with dpkg --audit, none is sealed without a valid kernel and initramfs, and sealing includes automatic GRUB publication plus validation. The active root is determined from the kernel command line, not from numbering, so old generations remain bootable. /var, /home and /root persist across generation changes, and the installer removes the staging root. The status command is not a pretty-printer; it is an auditor of these invariants, and it will tell you when the runtime contract is broken.

Equally important is what Alpha 1 does not yet promise, and the project is refreshingly candid about it. There is no automatic rollback after a failed boot, no post-boot health checker and no boot counting. There is no automatic retention or cleanup of old generations, no managed deletion of sealed generations — discard only removes pending work — and no permanent rollback or default-setting command. Late changes to /etc are not merged into an already-created pending generation. Atomicity covers the system generation and its package state, not all of /var or application data. There is no hostile-root isolation: /.synex-state remains administrative infrastructure that root can reach. Compatibility with the full breadth of Debian maintainer scripts — kernel packages, GRUB and shim updates, DKMS, ucf, the alternatives system, sysusers and adduser, desktop triggers, and any script that writes into a service's own directory under /var/lib — is precisely what this alpha exists to discover. Transactional updating of the EFI firmware state for every possible boot-package upgrade, and a final graphical interface for the transactional workflow, are still ahead. In short, this is a real validation platform, not a finished product, and the project says so.

For download, the image is published through the project's official SourceForge directory under Stable/IMMUTABLE. As an alpha it is intended for testing, architecture evaluation and surfacing packaging incompatibilities, not for production workloads, and the project asks — as any careful distribution should — that you verify the checksum of the downloaded image before writing installation media. The next layers already sketched in the documentation are retention and rollback management, automatic health checking with fallback, and broader compatibility with complex packages. If those land, Synex will have quietly done something notable: brought genuine transactional, generational updating to a conventional Debian system without asking anyone to abandon APT, dpkg or GRUB.

---

Concluding word

Synex 13 Immutable Alpha 1 is a genuinely interesting piece of engineering. It treats immutability as a system property — generations, paired state, isolated transactions, validated boot entries — rather than a mount flag, and it keeps the familiar Debian package stack intact throughout. For tinkerers, evaluators and anyone who has ever nursed a system back from a half-applied upgrade, it is well worth an afternoon in a virtual machine. Keep it out of production, read the limitations with the same care you give the features, and enjoy watching a small distribution punch well above its weight.

---

Disclaimer

All product names, trademarks and registered trademarks are property of their respective owners and are used here for identification purposes only. The Distrowrite Project aims for accuracy and relies solely on official Synex sources and direct first-hand observation of the alpha; nonetheless, software evolves and details may change after publication. Open-source software is to be used responsibly, within its licence terms and applicable law, and alpha releases in particular should be treated as experimental.

---

References

• Synex 13 Immutable Alpha 1: Btrfs generations, transactional updates, and a new system model — official release announcement (includes the full official technical architecture document)

• Synex Announcements category

• Synex Stable/IMMUTABLE downloads on SourceForge

• Synex Community Forum

---

🛡️♾️🔄🔐👨‍💻

↑ Back to top