Atomic upgrade rollback behavior when /var contains application state

Answer

When you roll back an rpm-ostree deployment, only the OS tree (/usr and /etc) is restored to the previous commit; the /var directory is left untouched because it is not versioned in the OSTree commit.

Confirmed facts

• rpm-ostree creates a new OSTree commit for /usr and (via three‑way merge) /etc on each upgrade.
• /var is a separate mutable subtree that is preserved across deployments.
• Running rpm-ostree rollback switches the boot entry to the previous OSTree commit but does not modify any files under /var.

Likely explanation

The design treats /var as persistent application state, assuming that state migrations are forward‑compatible or that administrators will manage it separately.

Steps to keep application state consistent across rollback

1. Determine how /var is stored on your system (btrfs subvolume, LVM logical volume, or plain directory).
2. If the root filesystem is btrfs:
   1. Create a dedicated subvolume for /var, e.g. btrfs subvolume create /@var and mount it at /var.
   2. Enable grub-btrfs so that each boot entry gets a matching snapshot of @var.
   3. After an upgrade, rpm-ostree rollback will automatically revert the @var snapshot together with the OS tree.
3. If the root filesystem uses LVM:
   1. Place /var on a thin‑provisioned logical volume.
   2. Before each upgrade, take a snapshot of that LV (e.g. lvcreate -s -n var_snap /dev/vg0/var_lv).
   3. After rollback, restore the snapshot with lvconvert --merge or boot from the snapshot LV.
4. If neither btrfs nor LVM is available, make the application stateless or store its data outside /var (e.g., in a separate directory that is snapshotted by your backup solution) and ensure migration scripts are idempotent so they can run safely after a rollback.

Verification

# Check current deployment
rpm-ostree status
# Create a test file
sudo touch /var/lib/myapp/testfile
# Perform an upgrade (or simulate)
sudo rpm-ostree upgrade
# Reboot into the new deployment
# Rollback
sudo rpm-ostree rollback
# Reboot again
# Verify the test file still exists
ls -l /var/lib/myapp/testfile

If you are using btrfs subvolume snapshots, also verify that a matching @var snapshot exists for each boot entry:

btrfs subvolume list / | grep @var

Missing diagnostic detail

To give a precise recommendation, please confirm whether your system’s root filesystem is btrfs, LVM, or a plain ext4/xfs layout, as the snapshot strategy depends on that.