Automatic rollback trigger criteria on Fedora Atomic variants

What triggers automatic rollback

Automatic rollback on Fedora Atomic variants occurs only when the boot process does not reach the systemd success target (multi-user.target or graphical.target). The bootloader treats a kernel panic, initramfs failure, or a boot that hangs before that target as a failure and decrements its per‑entry failure counter. After the configured threshold (default 2 consecutive failures) the bootloader selects the previous deployment.

Confirmed facts

• The mechanism is implemented by boot-count.service and boot-success.service for systemd‑boot, or by grub2-boot-success.service and the GRUB blscfg plugin for GRUB2.
• The success target is reached when the systemd unit multi-user.target (or graphical.target for desktop spins) becomes active.
• Only the two most recent deployments are retained by default; older states are garbage‑collected.

Likely explanation for post‑boot issues

Service‑level or application failures that happen after the success target do not increment the failure counter, so they do not trigger automatic rollback. Administrators must add their own health‑check or watchdog to initiate a rollback in those cases.

Steps to verify and configure

1. Confirm which bootloader is in use: bootctl status (systemd‑boot) or grub2-editenv list (GRUB2).
2. Check that the success service ran on the last boot: systemctl status boot-success.service (systemd‑boot) or systemctl status grub2-boot-success.service (GRUB2). Look for 'Active: active (exited)' in the journal.
3. Inspect the failure counter:
   • systemd‑boot: bootctl get-variable LoaderEntryOption-$(sudo blkid -s PARTUUID -o value $(mountpoint /boot))
   • GRUB2: sudo grub2-editenv list and note boot_success and boot_failures variables.
4. To test the threshold, temporarily add systemd.unit=emergency.target to the kernel command line of the newest deployment, reboot twice, and verify that the system boots the previous deployment. Then remove the parameter and confirm normal boot resumes.

Handling partial failures after boot

If you need rollback for failures that appear after the success target, create a custom health‑check unit ordered after your critical services:

[Unit]
Description='Post‑boot deployment health check'
After=multi-user.target myapp.service

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/deployment-healthcheck
OnFailure=rollback-on-failure.service

[Install]
WantedBy=multi-user.target

The rollback-on-failure.service can simply run rpm-ostree rollback followed by systemctl reboot. This extends the success criterion beyond the boot target.

Missing diagnostic detail

If you are unsure whether your image uses systemd‑boot or GRUB2, run bootctl status; if it reports 'System: Not booted with systemd‑boot', assume GRUB2 and verify with grub2-editenv list. Knowing the bootloader changes which journal units you inspect, but the rollback logic itself is the same.