How updates work
SakuraOS updates itself overnight, behind a restore point, and holds back anything Arch has published a manual step for. Falling months behind on a rolling release is more dangerous than updating often.
When it runs
A systemd timer checks nightly at 03:00, with up to twenty minutes of jitter so that every SakuraOS machine in the world does not hit the mirrors in the same second. The timer is persistent: a machine that was asleep at three in the morning runs the check when it next wakes rather than skipping the day.
The time is a setting, along with whether updates apply automatically at all, whether the machine must be on mains power first, and whether it may reboot itself afterwards.
| Setting | Default | What it does |
|---|---|---|
AutoApply | true | Install what is ready, rather than only telling you about it. |
Window | 03:00 | When the nightly check runs. |
RequireACPower | true | Do not update a laptop running on its battery. |
AutoReboot | false | Never restart the machine on its own. You are told when a restart is needed. |
The restore point comes first
Nothing is installed until a snapshot exists. That is the whole reason automatic updates are defensible on a rolling release: the worst case is a reboot and a menu entry, not an afternoon.
See Recovery for what happens when you use it.
What gets held back
Arch publishes a news item when an update needs a human to do something first. The update engine reads that feed, matches the notices against the packages actually queued for your machine, and holds only those packages back, with the reason attached.
The matching is deliberately narrow. Only the leading component of a package
name is tried, because a notice about linux would otherwise
match every linux- package on the system and hold back an entire
update for no reason.
Held updates are not hidden. They are listed with the notice that caused the hold, so the decision is yours rather than the engine's.
What an update tells you
Nobody knows what libjxl is. The list says what a package is for
and what on your system depends on it, so that agreeing to an update is
something you can actually do knowingly rather than by reflex.
Two timers, one promise
Repository packages and everything else are updated by different components on purpose.
| Timer | Runs | Covers |
|---|---|---|
sakura-updates | sakura-update apply | Repository packages, behind a restore point. |
sakura-store-updates | sakura-store update | System Flatpaks and Snaps. |
sakura-store-updates-user | sakura-store update | Per-user Flatpaks and AppImages, which live in a home directory and need no root. |
The store deliberately skips repository packages: the update engine already
runs a full -Syu nightly behind a snapshot, and doing it in both
places would be the same work twice and, worse, the second time without that
snapshot.
Packages installed from the AUR are deliberately excluded. Updating one means running a build script written by somebody else, and doing that unattended at three in the morning is exactly what the AUR being off by default exists to prevent. They are reported for your review instead, and covered in The AUR.
Evidence from our own machines
A machine of ours installs every pending update, reboots, and re-runs the same checks a fresh install has to pass. When that machine does not survive, the packages in that transaction are published as an advisory and held back on yours.
The hold covers everything in the failed transaction rather than one package, because the canary knows the update broke a machine, not which package did it. Narrowing that down is a bisect, and a bisect is a person's job rather than a nightly timer's.
It fails open. If the advisory feed cannot be reached, nothing is held. A machine that cannot reach us must still get its security updates; holding everything back because a web request failed would strand exactly the machines least able to recover. The same is true of the Arch news feed.
This is the RequireCanaryEvidence setting, on by default. Turning
it off means updates reach you without waiting on our test machine.