MicroOS transactional-update vs Ansible: /etc config persistence across atomic snapshots

Question

MicroOS transactional-update creates a new btrfs snapshot per atomic deployment, activating on reboot. Persistent /etc subvolume survives snapshots but isn't integrated with the update pipeline. When a package update replaces a config‑owning file such as /etc/nginx/nginx.conf, the new snapshot has the package default while /etc keeps the modified file. No automatic merge, no .rpmnew/.rpmsave artifact, no runtime warning; admin must manually diff and reconcile after reboot.

Ansible and Salt operate on mutable roots, working on Leap/Tumbleweed but not MicroOS, where writes go to a snapshot that may be discarded on rollback or fail to persist across updates. The /etc subvolume integration does not track changes as OS state, leaving config drift undetected and unmerged between live system and staged snapshot.

systemd‑sysext extension images ship /etc overlays as squashfs merged at boot but require rebuilding on every config change, offer no live reload, and have no standard tooling to integrate Ansible or Salt output into sysext images. This leaves an unresolved interoperability question for declarative config management on immutable‑root systems.

Under what conditions does the persisted /etc subvolume override the snapshot’s default config at boot?
Is there a supported mechanism to inject Ansible‑ or Salt‑rendered config into the transactional-update pipeline without rebuilding a systemd‑sysext image?
How does MicroOS detect and report config drift between live /etc and the snapshot’s expected /etc after an atomic update?

Tasadduq Burney · Answer

Answer to the three core questions

When does the persisted /etc subvolume override the snapshot’s default config at boot?

MicroOS mounts the root snapshot first and then mounts the dedicated /etc subvolume. Because btrfs mounts later subvolumes over earlier ones, the preserved /etc wins if it is mounted after the root snapshot switch. If the /etc subvolume is not marked persistent or is mounted before the snapshot, the snapshot’s default files will be used.

Is there a supported way to inject Ansible‑ or Salt‑rendered config into the transactional‑update pipeline?

No native integration exists. The update pipeline operates on immutable snapshots, so you must either:

Add a %post script to the rpm that writes the rendered file into the snapshot, or
Rebuild a systemd-sysext image that contains the desired configuration and install it as an extension.

How does MicroOS detect and report config drift after an atomic update?

There is no built‑in drift detection. Administrators need to run manual checks such as rpm -V /etc/nginx or btrfs diff between snapshots to spot differences. The update process only verifies package files, not user‑modified config files.
Practical steps for your environment

Verify which /etc is in use:mount | grep '/etc'
# or
btrfs subvolume list / | grep '/etc'

Check that the /etc subvolume is marked persistent:transactional-update shell
# Inside the shell, inspect /etc/.btrfs subvolume properties

Detect drift after an update:transactional-update shell
rpm -V /etc/nginx  # shows mismatches between package and live file
# or
btrfs diff /etc

Inject Ansible/Salt output (example with rpm %post):
%post
# Assume rendered config is in /tmp/rendered/nginx.conf
cp /tmp/rendered/nginx.conf /etc/nginx/nginx.conf

Alternatively, rebuild a sysext image with the new config and install it:
systemd-sysext install --name nginx-conf my-nginx.sysext

What we need to confirm for a precise recommendation
Could you tell us which MicroOS release you’re running and whether /etc is configured as a separate persistent subvolume? The mount order and subvolume flags differ between releases, and that will affect the override behavior.

MicroOS transactional-update vs Ansible: /etc config persistence across atomic snapshots

1 answer

Answer to the three core questions

Practical steps for your environment

What we need to confirm for a precise recommendation

Your perspective belongs here.

0 question comments