Synex 13 Immutable Alpha 1: Btrfs generations, transactional updates, and a new system model

We are pleased to announce Synex 13 Immutable Alpha 1, the first public image of a new Synex edition built around a generational and transactional model.

Unlike the traditional editions, Synex Immutable does not directly modify the system that is currently running. The active root remains read-only, while updates are prepared on a new independent Btrfs generation that only becomes part of the boot process after all operations have been completed and validated.

This development began with the study of the openSUSE MicroOS architecture and a concrete question: how to bring the properties of a transactional system to Synex without adopting an image-based model such as OSTree, while keeping APT, dpkg, GRUB, and the usual system structure.

The result does not reproduce the MicroOS layout or its tools. Based on the same fundamental ideas — generations, modifications outside the active system, consistency between software and the package manager, and rollback from boot — we developed our own implementation adapted to Synex.

A system divided into generations

Synex Immutable uses Btrfs as the foundation of the architecture.

Each bootable system state is represented by a generation:

@immutable-generations/gen-0001
@immutable-generations/gen-0002
@immutable-generations/gen-0003
...

Each generation also has an associated STATE:

@immutable-state/gen-0001
@immutable-state/gen-0002
@immutable-state/gen-0003
...

The root of a published generation remains read-only.

STATE, on the other hand, contains the administrative parts that must evolve together with that root but still need to remain writable at certain stages, including /etc, the dpkg database, APT state, ucf, DKMS, debconf, and metadata used by systemd.

This means that a generation is not composed only of its binaries.

Conceptually:

GENERATION
=
root
+
/etc
+
dpkg/APT administrative state
+
kernel/initramfs
+
validated boot entry

The goal is that when the system moves forward or returns to a previous generation, the software and the metadata describing that software always remain consistent with each other.

Read-only root, without making the entire system read-only

One of the central design decisions was to clearly separate the system, configuration, and persistent data.

During normal operation:

/            -> active generation          RO
/etc         -> generation STATE           RW
/var         -> persistent                 RW
/home        -> persistent                 RW
/root        -> persistent                 RW
/boot/grub   -> persistent                 RW
/tmp         -> tmpfs                      RW

This allows /etc to remain writable for the administrator without turning it into a global state shared by every generation.

At the same time, specific parts of /var that belong to the package manager are overlaid through bind mounts from the corresponding STATE and are presented read-only while the system is running:

/var/lib/dpkg
/var/lib/apt
/var/lib/ucf
/var/lib/dkms
/var/cache/debconf

The rest of /var remains persistent.

This separation matters because a system rollback must not automatically imply a rollback of documents, profiles, logs, databases, or application state.

In Synex Immutable:

system rollback does not mean persistent-data rollback.

Updates happen in another generation

The transactional workflow starts with:

sudo synex-immutable create

The command uses the generation that is actually active as its source and creates a new pending generation from it.

For example:

gen-0001   active
gen-0002   pending

The new generation has both its root and its STATE in read-write mode, but it does not replace or modify the mounts of the running system.

The active generation continues operating normally.

Package operations are then performed through:

sudo synex-immutable apt update
sudo synex-immutable apt full-upgrade

or through the install, remove, purge, and upgrade variants.

APT does not run on the active root.

synex-immutable creates a private mount namespace, mounts the pending generation there, and builds a transactional chroot in which the following are presented together:

pending root        RW
pending /etc        RW
pending dpkg DB     RW
pending APT state   RW

Meanwhile, outside that environment, the user continues running the previous generation, whose root and administrative state remain protected.

APT and dpkg remain APT and dpkg

One of the project decisions was not to replace the existing package ecosystem.

Synex Immutable continues to use APT and dpkg.

The difference is where they run.

Inside the transactional environment, APT works with the same paths it normally expects:

/etc
/var/lib/dpkg
/var/lib/apt

but those paths belong to the future generation.

This preserves the usual Synex package model and format without requiring applications and system components to be converted to a format specific to an immutable edition.

During these operations, policy-rc.d is also applied to prevent maintainer scripts from attempting to start or restart services inside the transactional chroot.

Once each operation finishes, Synex runs:

dpkg --audit

to verify package-state consistency.

seal: a generation is not published merely because APT finished

Completing an update does not automatically turn the pending generation into a bootable generation.

That step is performed explicitly:

sudo synex-immutable seal gen-0002

Before committing it, seal validates, among other things:

• the existence and consistency of the root and its STATE;
• the complete STATE layout;
• the fstab corresponding to that generation;
• dpkg state;
• the existence of a coherent kernel and initramfs;
• the presence of the Synex Immutable hook inside the initramfs;
• the absence of remaining transactional mounts.

Only then does it synchronize the state and switch the root to read-only.

But the process is still not complete.

seal automatically runs:

update-grub

validates the resulting grub.cfg with grub-script-check, and verifies that an exact entry exists for that generation with the corresponding Btrfs rootflags.

Only after this sequence completes successfully is the generation considered sealed and published.

GRUB is also part of the architecture

Synex Immutable includes its own generator:

/etc/grub.d/09_synex-immutable

It discovers the available generations and publishes only those that meet the requirements needed to boot.

Each entry points directly to the kernel and initramfs that belong to that generation:

Synex Immutable - gen-0002

with:

rootflags=subvol=@immutable-generations/gen-0002

Generations are ordered from newest to oldest, and GRUB normally uses the latest sealed generation as the default entry.

The conventional 10_linux generator is disabled in a controlled way through dpkg-statoverride, preventing entries that bypass the generational model from being created.

/boot belongs to each generation, so the kernel and initramfs move forward and backward with it.

/boot/grub, by contrast, remains outside the generations as shared persistent state.

Returning to an earlier generation

Synex Immutable Alpha 1 does not yet include a specific rollback command.

In this first version, returning to an earlier state simply means selecting another sealed generation from GRUB.

For example:

gen-0001
gen-0002
gen-0003

can coexist as independent bootable states.

If the user boots gen-0001, Synex recognizes that generation as active. If a new generation is created from there, later generations are not overwritten: a new number is assigned, but the source is the system that is actually running.

This makes it possible to continue working from an earlier state without destroying the existing history.

A transactional architecture, not absolute machine-wide atomicity

There is a deliberate boundary in the model.

General /var remains persistent and is also exposed inside transactions. Only the administrative paths that belong to STATE are overlaid on top of it.

As a result, changes made by a maintainer script to paths such as:

/var/lib/dpkg
/var/lib/apt

belong to the pending generation.

But changes to:

/var/log
/var/cache
/var/lib/<application>

may immediately affect persistent state.

This means Synex Immutable does not claim atomicity for every possible effect on the machine.

The guarantee being pursued is different:

strong atomicity of the system generation and its administrative package state.

Persistent data deliberately has an independent lifetime.

From MicroOS to a Synex-native architecture

The conceptual starting point for this development was openSUSE MicroOS.

Before implementing Synex Immutable, we studied its real behavior on a clean installation: Btrfs structure, snapshots, /etc, the RPM database, transactional environment, boot, rollback, transaction abort behavior, and the separation between the generational system and persistent state.

That analysis led to an important conclusion: a transactional system is not defined simply by mounting / read-only.

The real unit is the generation.

MicroOS solves that problem with transactional-update, Tukit, Snapper, a generational RPM database, and its own boot integration.

Synex keeps the properties we considered fundamental, but implements them differently:

MicroOS                     Synex Immutable
-------------------------   --------------------------------------
transactional-update        synex-immutable
Tukit                       TransactionMount + GenerationManager
Snapper snapshots           native Btrfs generations
generational RPM DB         STATE v2 for dpkg/APT
systemd-boot/BLS            GRUB + 09_synex-immutable
writable /etc per snapshot  generational STATE

We did not aim to reproduce the MicroOS layout literally.

The work that followed focused on solving the problems specific to Synex and the APT/dpkg ecosystem: which state had to accompany a generation, how to execute maintainer scripts without touching the active system, how to handle /etc, how to preserve /var, how to include the kernel and initramfs, and how to make GRUB part of the update commit process.

The result preserves a characteristic we considered important from the beginning: Synex Immutable remains Synex.

It does not require converting the system to an OSTree-based deployment model or replacing APT and dpkg. The transactional architecture is built around them.

Calamares and the creation of GEN1

Installation is also part of the model.

Calamares initially works on a temporary conventional root:

@

and independently creates the required persistent subvolumes.

At the end of the installation, the Synex Immutable-specific modules convert that staging area into:

@immutable-generations/gen-0001
@immutable-state/gen-0001

GEN1 is validated, sealed, and published in GRUB.

Once the boot configuration has been confirmed as valid, the temporary @ root is permanently removed.

The installed system is therefore left without a conventional mutable root outside the generational architecture.

This process has been implemented and tested on both UEFI and BIOS systems.

Synex Package Manager on the Immutable edition

In this first Alpha, Synex Package Manager can continue to be used to manage Flatpak applications.

Specific integration with Synex Immutable remains part of the work planned for future versions.

The goal is for the SPM backend to automatically detect when it is running on the Immutable variant and, based on that information, expose only the functions that are compatible with this model.

Under that design, SPM will focus on Flatpak management and Flatpak-related options, while modifications to the base system through APT will continue to be performed through synex-immutable.

Conceptually:

Current state

Flatpak
   ↓
Synex Package Manager

Base system / APT
   ↓
synex-immutable

And as the planned evolution:

SPM detects Synex Immutable
        │
        └── exposes only
            the functions compatible
            with the edition

This means that the separation between user applications and the base system is already defined architecturally, even though automatic adaptation of the SPM interface is not yet part of Alpha 1.

Alpha 1 and next steps

Synex 13 Immutable Alpha 1 already implements the complete core of the generational model:

• read-only active root;
• writable generational /etc;
• STATE v2 for dpkg/APT;
• creation and discard of pending generations;
• isolated APT transactions;
• validation through dpkg --audit;
• generation sealing;
• automatic GRUB publication and validation;
• booting previous generations;
• independent persistence of /var, /home, and /root;
• complete installation through Calamares on UEFI and BIOS.

Some layers deliberately remain outside this first Alpha.

These include management and retention of sealed generations, an administered rollback/default command, post-boot health checking, automatic fallback after a defective generation, and handling changes made to the active /etc while a pending generation already exists.

The Alpha will also allow us to broaden testing with complex packages and maintainer scripts that interact with persistent areas of the system.

Technical documentation

Alongside this release, we are publishing a complete technical document covering the design and implementation of Synex Immutable:

Synex Immutable: transactional architecture and operating model

The documentation covers the Btrfs layout, STATE v2, runtime mounts, the bind-mount architecture, the APT transactional environment, seal validation, GRUB, the Calamares bootstrap process, rollback, and the current atomicity boundaries.

Our intention is for the architecture of this edition not to be a black box, and for anyone interested in evaluating, studying, or contributing to the project to be able to understand precisely what happens behind each generation.

Availability

Synex 13 Immutable Alpha 1 is available for immediate download.

As an Alpha release, it is primarily intended for testing, architecture evaluation, and identifying incompatibilities before moving on to the next development stages.

As always, we recommend verifying the checksum of the downloaded image before creating the installation media.