Updates and rollback
A new image is built every night, downloaded in the background, and used from your next restart. The previous one stays in the boot menu. Nothing restarts on its own. Each night's build is public while it runs, at beacon.getpulsar.dev.
How you hear about one
Your session checks for a newer build 10–40 minutes after login, then about every six hours. Each build gets one notice:
- Pulsar <version> is ready: already downloaded. Restart opens GNOME’s restart dialog.
- Pulsar <version> is available: not downloaded a day after publishing (on battery, metered), or at once if background downloads are off. Update downloads it now.
Check yourself (no root):
$ pulsar update --check
up to date: 44.20260928.0 (ghcr.io/arclight-digital/pulsar-nvidia:latest)
up to date: <version> (<image>) exit 0
staged: <version> -- reboot to apply exit 0
update available: <booted> -> <latest> exit 10
(could not reach the registry) exit 1
The exit status is the answer; --json gives
{status, booted, latest, image, staged}. GNOME Software’s update downloads and
bootc’s auto-update timer (which reboots on its own) are off.
Taking an update
sudo pulsar update # fetch and stage; applies at the next restart
sudo pulsar update --apply # the same, then restart into it
pulsar update fetches and stages the new image; it becomes the
default at the next boot. On the NVIDIA image it also fetches the next driver’s Flatpak GL
extension, so Steam has it on boot.
In the background
pulsar-update-auto.timer runs pulsar update --background 20 minutes
after boot, then every 12 hours awake, at the lowest priority. It skips (and logs why) on
battery, on a metered connection, or when the newest build is already staged. It never
restarts and never uses --apply.
sudo systemctl disable --now pulsar-update-auto.timer # stop downloading in the background
The notification’s Update button starts the same download. A local admin isn’t asked for a password; it can only stage the published image, never apply it.
With layered packages (rpm-ostree install), pulsar update uses
rpm-ostree upgrade to keep them; plain bootc upgrade would drop them.
pulsar status shows the booted, staged and previous deployments.
$ pulsar status
STATE VERSION IMAGE PINNED
booted 44.20260928.0 ghcr.io/arclight-digital/pulsar-nvidia:latest no
- 44.20260927.0 ghcr.io/arclight-digital/pulsar-nvidia:latest no
Installed from an ISO before September 25, 2026?
pulsar doctor
(the origin check) and pulsar update print the command that points
them at :latest.
Going back
The previous deployment stays on disk. Make it the default and restart:
sudo pulsar rollback # the previous deployment boots next time
systemctl reboot
It doesn’t restart for you. For a one-off, pick the older version in the boot menu. To discard a staged update you haven’t booted:
sudo rpm-ostree cleanup --pending # drop a staged update before it boots
When a boot fails
greenboot requires the login screen or a desktop within two minutes of boot. After three failed
boots, the machine rolls back to the previous deployment on its own. The scheduler and network
checks only warn. pulsar doctor greenboot shows this boot’s result.
Pinning
Updates clean up old deployments. A pin keeps the booted one on disk through any number of updates.
$ pulsar pin
the booted deployment is not pinned (sudo pulsar pin on to keep it)
$ sudo pulsar pin on
pinned the booted deployment; it will survive GC
sudo pulsar pin off lets it go again.
Checkpoints
Rollback covers the OS image, not /etc or your home folder. A checkpoint covers
both. Take one before a risky session:
sudo pulsar checkpoint "before the agent" # take one, with a note
sudo pulsar checkpoint list # every checkpoint
sudo pulsar checkpoint diff # what changed since the newest one
sudo pulsar checkpoint restore <id> # put changed and deleted files back
sudo pulsar checkpoint drop <id> # delete it, and unpin what it pinned
checkpoint <id>
/etc <n> paths saved
home <n> paths saved from /var/home/you (dotfiles, ~/.config, ~/.local/bin, ~/.ssh)
deployment 44.20260928.0 pinned
see what changed: sudo pulsar checkpoint diff <id>
undo it: sudo pulsar checkpoint restore <id>
A checkpoint keeps three things:
- All of
/etc, with owners, modes, ACLs and SELinux labels. -
Your settings (the
sudouser’s): home dotfiles,~/.configminus caches,~/.local/bin,~/.ssh. Not documents, projects or~/.local/share. Skipped over 512 MB, or with--no-home. - A pin on the booted deployment.
-
diff: every pathchanged,addedorremovedin/etcand your settings, and any deployment staged or booted since. -
restore: puts back changed and deleted files and discards a deployment staged since. Added files are listed, not deleted. Nothing is restarted: restart affected services, and log out for GNOME settings.
Read the diff before you restore
list: checkpoints hold
/etc/shadow and your SSH keys.
What each one covers
| What changed | Rollback | Checkpoint |
|---|---|---|
| The OS image (/usr) | yes | yes, pinned |
| Layered packages | yes: they belong to the deployment | yes, pinned |
| /etc | no: you boot the old deployment’s copy, which can lose later edits | yes |
| Your settings: dotfiles, ~/.config, ~/.local/bin, ~/.ssh | no | yes |
| Documents, projects, ~/.local/share | no | no |
| Flatpak apps and their data, toolboxes, containers | no | no |
| /usr/local, /opt, the rest of /var | no | no |
What an agent can change without asking: Agents and safety.
Written with help from AI and reviewed by a person before publishing. Spotted a mistake? Let us know.