Rolling updates mean never waiting for a release cycle; the price is that every update carries some risk. Linxira's answer to that price is three layers of insurance: dual-kernel fallback, automatic pre-update snapshots, and direct rollback from the GRUB menu. This article covers what each layer defends against, how they fit together, and what an actual recovery drill should look like.
Arch is a rolling-release distribution: upstream (including security fixes) lands in the repositories as soon as it is published, and the system keeps receiving updates via sudo pacman -Syu. The upside is always-current software and immediate security fixes; the risk is that a bad update can break the system — a regression in a new package version, a dependency resolution error, or a kernel update that refuses to boot.
Traditional distributions absorb this kind of problem with release cycles: wait for the next point release to fix it. On a rolling distribution fixes are usually fast too, but the time during which "the system is currently broken" has to be handled by the user. The way to handle it is not to pray that updates never break anything, but to give the system the ability to return to its pre-update state — that is exactly what snapshot rollback is for.
To be concrete: a bad update is usually not "everything broke" but "one thing broke" — the new kernel fails to boot, a library version is incompatible with the applications depending on it, a driver update leaves the GPU black. What these failures share is that they are only discovered afterwards: the update itself looks fine, and the problem surfaces at reboot or during use. So "leave a way back before updating" is not conservatism; it is the only sensible default strategy under the rolling model.
The first layer is kernel-level redundancy: the system installs two Arch general-purpose kernels side by side — linux as primary and linux-lts as fallback, with the GRUB flat menu booting the newest kernel by default. When a single kernel update misbehaves (say, the new kernel fails to boot), you pick the other kernel from GRUB at reboot.
Dual kernels handle the "kernel update anomaly" class of problems: no recovery procedure needed, just a different menu entry at reboot. They do not fix "userspace package update broke something" — that is the snapshot's job. The division of labor between the two layers is clear: kernel anomalies are covered by dual kernels; system-level damage is rolled back with snapshots.
The GRUB flat menu plays the key role here: both kernels are listed side by side, the newest is the default, but the older one is always in the menu. In effect this is equivalent to always having "the last known-good kernel" on hand — it adds no recovery procedure, only one more selectable entry at boot. The linux-lts kernel follows a more conservative cadence, complementing the aggressively rolling mainline kernel.
Snapshots build on the btrfs filesystem: the system is installed on btrfs subvolumes, and a snapshot records the complete state of a subvolume at a point in time, managed by Timeshift. This is exactly why the installation guide recommends the btrfs + Timeshift partitioning scheme — the scheme is decided at install time, so snapshot capability exists from day one instead of being retrofitted after the system is set up.
Snapshots are cheap: btrfs snapshots are copy-on-write, taking almost no space initially, with only subsequently modified data producing deltas. That makes "take a snapshot before every update" effectively free, while buying the certainty that any broken update can be reverted to the pre-update state.
The subvolume layout determines what snapshots can cover: the system is installed on a documented btrfs subvolume structure, Timeshift snapshots the subvolumes, and both data and system state fall under the same mechanism's management. The installation guide writes btrfs + Timeshift into the recommended partitioning flow precisely because the partition structure at install time decides the boundary of snapshot capability — retrofitting it later is usually too late.
A word on disk space, since snapshots live on the same btrfs filesystem: each snapshot's initial cost is near zero thanks to copy-on-write, and the space it consumes grows only as the system changes after the snapshot is taken. Practical guidance follows from that: keep a reasonable retention policy (Timeshift's scheduling handles this), and you get continuous safety without watching your free space evaporate — the storage cost scales with how much you change the system, not with how many snapshots you keep.
Having snapshots is one thing; restoring conveniently is another. A manual restore flow — mounting, copying, repairing the bootloader — is too complicated for most users to learn from scratch while the system is broken. Linxira's answer is grub-btrfs: it adds snapshots to the GRUB boot menu.
Once enabled, the GRUB menu lists existing snapshots alongside the normal kernel entries. Rolling back needs no terminal work — reboot, pick the target snapshot in GRUB, and the system boots directly from it. This design turns "recovery" from a technical procedure into a menu selection.
The difference between booting a snapshot and booting a kernel is worth making explicit: a snapshot entry boots the complete system at that moment in time, including its kernel, drivers, and userspace software — exactly the semantics "back to before the update" needs. Snapshots have a clear chronological order, the GRUB menu organizes them by time, and picking "the one before the update" is literally a rollback, with no extra judgment required in a recovery environment.
One practical note for after a real rollback: a snapshot restores the system to the state it was in, which also means the problematic update is gone — if you later want to retry it, the pre-update snapshot flow will take care of the safety again automatically. In other words, rollback is not a dead end; it is a clean restart of the update cycle, with the same safety net in place.
Relying on users to remember to take snapshots is unreliable, so snapshot creation is automated:
linxira-update: the system update notification and maintenance assistant, which creates a Timeshift snapshot automatically before updates by default — when you update the system through its prompts, the pre-update state has already been recorded.linxira-config timeshift enable: one-command enablement of Timeshift's automatic snapshot configuration, taking snapshots on a schedule / boot cadence.The division between the two tools: the former guarantees "every update has a pre-update snapshot", the latter guarantees "even if you rarely update, the system has periodic snapshots". The update assistant also supports custom pre/post-update tasks, driven by a systemd user service.
The value of automation is removing "forgetting" as a variable: a person in a hurry may skip a manual step, but an automatic snapshot enabled by default does not need to be remembered. Turning the act of updating itself into a safe operation — snapshot first, then touch the system — is a more fundamental advantage than "figure it out when something breaks". This is also why the snapshot flow is wired into the update assistant rather than left as a separate tool users must remember to invoke.
Putting the layers together for a typical update: you run the update (or linxira-update prompts you), a Timeshift snapshot of the pre-update state already exists, pacman applies the update, and you reboot into the new kernel via the GRUB flat menu. If everything works, nothing more to do; if the new kernel misbehaves, reboot into linux-lts; if the system is damaged beyond that, reboot into the snapshot. The three layers are not alternatives to choose from — they are a graduated response, each one cheaper to invoke than the last.
The snapshot system only has value if you actually know how to use it when it matters. Run a drill once while the system is healthy and turn the flow into muscle memory:
linxira-config timeshift enable sets up periodic snapshots).The point of the drill is not "restoring" itself, but confirming: when a bad update really happens, you only need to reboot, pick a snapshot, and keep working — not look up documentation on a broken system.
There is also a psychological layer: knowing you can always go back changes how you treat updates. Users of rolling systems tend toward two extremes — never updating for fear of breakage, or updating blindly and gambling. Snapshot rollback makes a third option real: update with confidence, and come back if something goes wrong. Self-healing is not a promise to never fail; it is a promise that failure has a way back, and the way back is prepared in advance.