| 1 |
# 8. Updating and rolling back |
| 2 |
|
| 3 |
Alloy publishes no images, so there is nothing for your machine to download. |
| 4 |
Updating means rebuilding the image on a machine you own and switching to it. |
| 5 |
Rolling back means picking last boot's deployment from the boot menu. |
| 6 |
|
| 7 |
## What your machine is running |
| 8 |
|
| 9 |
alloy update |
| 10 |
|
| 11 |
shows the deployments: which image is booted, which is staged for the next |
| 12 |
boot, and what can be rolled back to. It fronts `rpm-ostree status`, so the |
| 13 |
same information is available as: |
| 14 |
|
| 15 |
rpm-ostree status |
| 16 |
|
| 17 |
Deployments are the whole model. Nothing is ever edited in place. An update, |
| 18 |
a layered package, and a rollback all produce or select a deployment, and the |
| 19 |
switch happens at boot. |
| 20 |
|
| 21 |
## Updating |
| 22 |
|
| 23 |
On the machine where you keep the source: |
| 24 |
|
| 25 |
cd alloy |
| 26 |
git pull |
| 27 |
build/build-iso.sh --skip-source # or build/build-image.sh |
| 28 |
|
| 29 |
Either one rebuilds `localhost/alloy:local`. Then, on the machine to update: |
| 30 |
|
| 31 |
bootc switch --transport containers-storage localhost/alloy:local |
| 32 |
systemctl reboot |
| 33 |
|
| 34 |
That adopts the locally built image in place. It is staged with A/B rollback, |
| 35 |
exactly like a registry-fed update would be, with the image coming from local |
| 36 |
container storage instead of the network. |
| 37 |
|
| 38 |
You do not reinstall. Your home directory, your accounts, and your layered |
| 39 |
packages survive. What you give up against a published image is the build time, |
| 40 |
not the machine. |
| 41 |
|
| 42 |
If the build happened somewhere else, move the image the way you would move any |
| 43 |
container image (`podman save` / `podman load`, or a local registry) and switch |
| 44 |
against that. |
| 45 |
|
| 46 |
## Rolling back |
| 47 |
|
| 48 |
If a new image is worse: |
| 49 |
|
| 50 |
rpm-ostree rollback |
| 51 |
systemctl reboot |
| 52 |
|
| 53 |
The previous deployment is still on disk, so this is fast and does not need a |
| 54 |
network. It swaps which deployment boots by default. |
| 55 |
|
| 56 |
You can also do it without booting the broken image at all: hold `Esc` or |
| 57 |
`Shift` at boot to get the GRUB menu, and pick the older entry. That boots it |
| 58 |
once. If the older one is the one you want to keep, run `rpm-ostree rollback` |
| 59 |
from it. |
| 60 |
|
| 61 |
## Why nothing updates itself |
| 62 |
|
| 63 |
An installed machine does not poll for updates. The timer that would do it is |
| 64 |
enabled only when the installer medium named an update target, which only a |
| 65 |
development build does. |
| 66 |
|
| 67 |
The consequence worth stating: **an image built in January and run until June |
| 68 |
carries January's packages**, including the browser, which is the program on |
| 69 |
your machine that faces the whole internet all day. If you run Alloy as a daily |
| 70 |
driver, rebuild on a rhythm you decide rather than when something breaks. |
| 71 |
|
| 72 |
`alloy update` reporting how far behind the image has fallen, with the browser |
| 73 |
called out rather than buried in a package count, is filed work and not yet |
| 74 |
shipped. Until it is, the honest answer is that the date of your last rebuild |
| 75 |
is the number that matters, and only you know it. |
| 76 |
|
| 77 |
## What about `bootc upgrade` |
| 78 |
|
| 79 |
It works, and does nothing useful here: there is no registry for it to fetch |
| 80 |
from unless you set one up yourself. If you run your own registry, point the |
| 81 |
build at it with `build/build-iso.sh --update-target <registry>/alloy:43` and |
| 82 |
the installed machines will use the standard bootc update path. |
| 83 |
|