Arch Linux

2be23ebc5976d4cd

Member

Registered: 2026-03-15

Posts: 5

atomic-upgrade: NixOS/Silverblue-Style upgrades for plain Arch

I made a tool that brings NixOS/Silverblue-style generational upgrades to plain Arch Linux. Looking for testers to try it on real hardware before I call it stable.

What it does

Btrfs snapshot -> chroot -> pacman -Syu -> build UKI -> sign for Secure Boot -> reboot into new generation. Rollback = pick a previous UKI entry in the boot menu.

sudo atomic-upgrade

That's it. Old generations are garbage collected automatically.

How it differs from snapper/timeshift + grub-btrfs

Those are snapshot tools. They snapshot the live system before/after an upgrade, so both the snapshot and the running system can end up in a partially upgraded state. atomic-upgrade runs the entire upgrade inside a chroot on a new snapshot — the running system is never touched. Rollback is just a boot menu entry.

Prerequisites

• Btrfs root on a subvolume (not top-level subvolid=5 directly)

• A bootloader or UEFI firmware that discovers UKI files (Type #2 entries) — systemd-boot, rEFInd, direct UEFI boot, etc. The tool just drops a .efi into ESP/EFI/Linux/.

• Stateful data (/home, and optionally /var/log, /var/cache, etc.) must live outside the root subvolume — either as separate Btrfs subvolumes or on separate filesystems. The entire root subvolume is snapshotted and rolled back, including everything inside it. If /home or other stateful data is not on a separate subvolume, it will be rolled back too.

• Secure Boot with sbctl (optional)

If your stateful directories are still on the root subvolume, they need to be moved out before use. The README has the expected layout.

Why snapshot and UKI are a single operation

Each generation is a snapshot + UKI pair. The UKI contains the kernel and initramfs from that snapshot, and its cmdline points to that specific subvolume. Splitting the two would break this link — a kernel update without a snapshot produces a boot entry pointing at the old root, and a package update without a UKI produces a snapshot with no boot entry. Rollback works precisely because each boot menu entry maps to one complete system state.

What I'm looking for

People running Arch on Btrfs who are willing to test on real hardware (or a VM that mirrors their setup). LUKS, LVM, LUKS+LVM, and plain Btrfs are all supported.

I've been running this on my daily driver since late January with no issues, but my own machines are not enough edge cases.

What would help most

• Non-standard partition layouts (LUKS+LVM, multiple Btrfs subvolumes, unusual mount options)

• Systems with linux-lts, linux-zen, or custom kernels

• Bootloaders other than systemd-boot (rEFInd, direct UEFI boot, etc.) — the tool drops .efi files into ESP/EFI/Linux/ and should work with anything that picks up Type #2 entries, but I've only tested with systemd-boot

• Reporting anything that breaks, feels wrong, or is unclear in the docs

Links

• GitLab: https://gitlab.com/fkzys/atomic-upgrade

• CI Status: https://github.com/rpPH4kQocMjkm2Ve/Ato … de/actions

• AUR: https://aur.archlinux.org/packages/atomic-upgrade

Install:

yay -S atomic-upgrade

There's a --dry-run flag if you want to see what it would do before committing.

Feedback, bug reports, and "this broke on my setup" are all welcome.

Last edited by 2be23ebc5976d4cd (2026-03-17 19:42:36)

cryptearth

Member

Registered: 2024-02-03

Posts: 2,049

Re: atomic-upgrade: NixOS/Silverblue-Style upgrades for plain Arch

Reporting anything that feels wrong

- BtrFS
- secure boot
- chroot

you basically reinvented immutable os root - there're already well working solutions

2be23ebc5976d4cd

Member

Registered: 2026-03-15

Posts: 5

Re: atomic-upgrade: NixOS/Silverblue-Style upgrades for plain Arch

Reporting anything that feels wrong

- BtrFS
- secure boot
- chroot

you basically reinvented immutable os root - there're already well working solutions

Root is mutable. After reboot you're on a regular read-write Arch system — pacman -S foo works as usual. This is not an immutable OS; it's upgrade isolation. The snapshot+chroot approach keeps the running system untouched during the upgrade, but the result is a normal mutable root.

If you know of an existing tool in the Arch ecosystem that provides atomic upgrade isolation (not pre/post snapshots of a live system), per-generation UKIs, and rollback via boot menu — genuinely interested, I haven't found one. Snapper and Timeshift snapshot the live system, NixOS and Silverblue are different distros entirely.

Last edited by 2be23ebc5976d4cd (2026-03-16 10:23:31)

cryptearth

Member

Registered: 2024-02-03

Posts: 2,049

Re: atomic-upgrade: NixOS/Silverblue-Style upgrades for plain Arch

have a look at how steam does it for the steamdeck os: two root partitions, updates installed in the one not currently mounted, flip a setting in the bootloader to load that other one next time
for everything in between the question of Why? comes up: what is the SPECIFIC reason to go that way and why EXACTLY existing ones not fit your needs?

2be23ebc5976d4cd

Member

Registered: 2026-03-15

Posts: 5

Re: atomic-upgrade: NixOS/Silverblue-Style upgrades for plain Arch

have a look at how steam does it for the steamdeck os

SteamOS root is read-only by default, pacman -Syu requires disabling that manually, and everything gets wiped on the next Valve update anyway. That's the opposite of what I want — it's an appliance model where the vendor owns the OS. I want to stay on regular Arch with pacman and AUR, just with isolated upgrades.

If something in the Arch ecosystem already does what atomic-upgrade does - I'd like to see it.

Everything2067

Member

Registered: 2025-06-29

Posts: 105

Re: atomic-upgrade: NixOS/Silverblue-Style upgrades for plain Arch

Are you using an LLM? Em dashes, it's not X; it's Y, these are common LLM traits.

---

How it feels to run shred/wipe in a COW system

2be23ebc5976d4cd

Member

Registered: 2026-03-15

Posts: 5

Re: atomic-upgrade: NixOS/Silverblue-Style upgrades for plain Arch

Are you using an LLM?

Yes.
The point of this thread is atomic-upgrade. Feedback on the tool is welcome.

Lone_Wolf

Administrator

From: Netherlands, Europe

Registered: 2005-10-04

Posts: 14,912

Re: atomic-upgrade: NixOS/Silverblue-Style upgrades for plain Arch

Your prerequisites limit the number of potential users severely .

Have you considered separating bootloader/kernel/initramfs updates from 'normal' updates and make this 2 projects instead of one ?

---

Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.

clean chroot building not flexible enough ?
Try clean chroot manager by graysky

2be23ebc5976d4cd

Member

Registered: 2026-03-15

Posts: 5

Re: atomic-upgrade: NixOS/Silverblue-Style upgrades for plain Arch

Your prerequisites limit the number of potential users severely .

Have you considered separating bootloader/kernel/initramfs updates from 'normal' updates and make this 2 projects instead of one ?

Each generation is a snapshot + UKI pair. The UKI contains the kernel and initramfs from that snapshot, and its cmdline points to that specific subvolume. Splitting the two would break this link - a kernel update without a snapshot produces a boot entry pointing at the old root, and a package update without a UKI produces a snapshot with no boot entry. Rollback works precisely because each boot menu entry maps to one complete system state.

On the bootloader point - systemd-boot was listed in the prerequisites because it's what I test with, but the tool just drops an .efi into ESP/EFI/Linux/ (signed or unsigned, depending on SBCTL_SIGN in atomic.conf). Any bootloader or UEFI firmware that discovers Type #2 entries (rEFInd, direct UEFI boot, etc.) should work. I've updated the README and the post to reflect that.