You are not logged in.
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 entry in systemd-boot.
sudo atomic-upgradeThat'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)
systemd-boot
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.
What I'm looking for
People running Arch on Btrfs with systemd-boot 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
Reporting anything that breaks, feels wrong, or is unclear in the docs
Links
Install:
yay -S atomic-upgradeThere'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 (Yesterday 01:31:46)
Offline
Reporting anything that feels wrong
- BtrFS
- secure boot
- chroot
you basically reinvented immutable os root - there're already well working solutions
Offline
2be23ebc5976d4cd wrote:Reporting anything that feels wrong
- BtrFS
- secure boot
- chrootyou 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 (Yesterday 10:23:31)
Offline
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?
Offline
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.
Offline
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
Offline