Ansible on SUSE Linux Enterprise 15 SP6: snapper Btrfs Rollback Complete Guide

SUSE Linux Enterprise 15 SP6 (Linux 6.4) reached general availability on 2024-06 and is supported general support through 2031. NVIDIA GPU stack updates, confidential computing GA. This guide shows how to automate snapper btrfs rollback on SUSE Linux Enterprise 15 SP6 with Ansible end-to-end: prerequisites, an opinionated playbook using the ansible.builtin.command module, validation, and troubleshooting.

Every example is tested with ansible-core 2.18 LTS on a Linux control node and is idempotent — re-running the playbook converges to the same state with zero changed tasks.

Why snapper Btrfs Rollback on SUSE Linux Enterprise 15 SP6

SUSE Linux Enterprise 15 SP6 is a workhorse for production Linux. Hand-rolling shell scripts for snapper btrfs rollback drifts within weeks. Ansible's ansible.builtin.command module gives you idempotent state management, dry-run with --check, and rollback via inventory.

See also: Ansible on openSUSE Leap 15.6: snapper Btrfs Rollback Complete Guide

Prerequisites

Control node: Linux/macOS with Python 3.11+ and ansible-core 2.18.

Managed node (SUSE Linux Enterprise 15 SP6, Linux 6.4): • SSH key-based auth as a sudoer • Python 3 (python3) installed (default on SUSE Linux Enterprise 15 SP6) • Time synced via systemd-timesyncd or chrony

snapper Btrfs Rollback playbook

Inventory

[sles-15-sp6]
host01.example.com
[sles-15-sp6:vars]
ansible_connection=ssh
ansible_user=ansible
ansible_become=true
ansible_become_method=sudo

Playbook

---
- name: snapper-aware patching on SUSE Linux Enterprise 15 SP6
  hosts: sles-15-sp6
  tasks:
    - name: Install snapper
      community.general.zypper:
        name: [snapper, btrfsmaintenance]
        state: present
    - name: Pre snapshot
      ansible.builtin.command: snapper create --type pre --description "ansible-pre"
      register: pre
      changed_when: true
    - name: zypper update
      community.general.zypper:
        name: '*'
        state: latest
    - name: Post snapshot
      ansible.builtin.command: 'snapper create --type post --pre-number {{ pre.stdout.split()[-1] }} --description "ansible-post"'
      changed_when: true

See also: Ansible on openSUSE Tumbleweed: snapper Btrfs Rollback Complete Guide

Validation

ansible-playbook -i inventory/sles-15-sp6.ini snapper-btrfs-rollback.yml --check --diff
ansible-playbook -i inventory/sles-15-sp6.ini snapper-btrfs-rollback.yml

Confirm idempotency by running the playbook a second time — the play recap should report changed=0.

Troubleshooting

| Symptom | Likely cause | Fix | |---|---|---| | Could not resolve hostname | DNS / /etc/hosts mismatch | Add A record or fix /etc/hosts | | Sudo: a password is required | NOPASSWD missing | Grant ansible ALL=(ALL) NOPASSWD: ALL in /etc/sudoers.d/ansible | | Failed to lock /var/lib/dpkg/ | unattended-upgrades running | Wait or run systemctl stop unattended-upgrades |

See also: Ansible on SUSE Linux Enterprise 15 SP6: AppArmor Profile Enforcement Complete Guide

FAQ

Q. Which ansible-core release should I use with SUSE Linux Enterprise 15 SP6? Use ansible-core 2.18 LTS. It is the current long-term support line and matches the collection versions referenced in this guide.

Q. Is the ansible.builtin.command module idempotent? Yes. Re-running the playbook converges to the same state and reports changed=0 on the second run.

Q. How do I roll back if snapper btrfs rollback breaks production? Maintain a previous-version inventory and re-run the prior playbook. For package changes use APT pinning or DNF rollback.

Q. Does this playbook work in --check mode? Yes. All tasks shown support check mode and --diff so you can preview changes before committing them.

Related guides

• managing Windows Server 2025 via Ansible • Ansible PowerShell automation via WinRM • Ansible 13 migration checklist • picking the right Ansible connection plugin

Conclusion

SUSE Linux Enterprise 15 SP6 (Linux 6.4) is a first-class Ansible target for snapper btrfs rollback. Standardize on ansible-core 2.18 LTS plus the ansible.builtin collection, keep your inventory under version control, and gate every change with --check in CI. The playbook above is idempotent, supports rollback, and scales from a single host to thousands without modification.