Variant Switching
cache22-rebase switches between cache22 variants (cachy ↔ arch, server ↔ kde) or pins to a specific image reference.
Synopsis
sudo cache22-rebase # Interactive picker.
sudo cache22-rebase --variant <id> # Switch by variant id.
sudo cache22-rebase --image <oci-ref> # Use any OCI reference.
sudo cache22-rebase --reboot # Reboot when done.
Variant ids
| Id | Image |
|---|---|
cachy-server |
ghcr.io/cmspam/cache22-cachy-server:rolling |
cachy-kde |
ghcr.io/cmspam/cache22-cachy-kde:rolling |
cachy-gnome |
ghcr.io/cmspam/cache22-cachy-gnome:rolling |
cachy-hyprland |
ghcr.io/cmspam/cache22-cachy-hyprland:rolling |
arch-server |
ghcr.io/cmspam/cache22-arch-server:rolling |
arch-kde |
ghcr.io/cmspam/cache22-arch-kde:rolling |
arch-gnome |
ghcr.io/cmspam/cache22-arch-gnome:rolling |
arch-hyprland |
ghcr.io/cmspam/cache22-arch-hyprland:rolling |
Examples
Switch from KDE to server
sudo cache22-rebase --variant cachy-server --reboot
The KDE deploy stays available as a rollback target until the next upgrade after this one. To return to KDE:
sudo cache22-rebase --variant cachy-kde --reboot
Pin to a specific build
sudo cache22-rebase --image ghcr.io/cmspam/cache22-cachy-kde:2026-05-04
sudo cache22-rebase --image ghcr.io/cmspam/cache22-cachy-kde:sha-9065ce1
After pinning, cache22-update follows the pinned reference. To return to the rolling stream:
sudo cache22-rebase --variant cachy-kde
Interactive picker
sudo cache22-rebase
Lists available variants from a live catalog (variants.json in this repo) plus an option to enter a custom image reference. The catalog is fetched live so new variants show up without an OS update; falls back to the catalog baked into the running image (/etc/cache22/variants.json) when offline.
Switch and reboot in one command
sudo cache22-rebase --variant arch-kde --reboot
After staging the new variant, the helper exec’s cache22-reboot. This does a full reboot, or kexec if KERNEL_CHANGE_STRATEGY=kexec.
What happens during rebase
Internally, cache22-rebase is a wrapper around bootc switch. It:
- Validates the target image reference (must be reachable on the registry).
- Calls
bootc switch --transport registry <image>. - bootc pulls layers as needed and stages a new deploy.
- The shutdown sequence finalizes the staged deploy and builds the per-deploy UKI (same path as
cache22-update).
The previous deploy is preserved as a rollback target until the next upgrade. To return to the previous variant before that next upgrade:
sudo bootc rollback
sudo cache22-reboot
Cross-fork rebase
To switch to a fork’s image:
sudo cache22-rebase --image ghcr.io/<your-username>/cache22-<variant>:rolling
The fork’s image must follow cache22’s UKI structure and per-machine signing model. Switching to a non-cache22 bootc image (e.g., ghcr.io/ublue-os/bazzite:latest) is not supported because the new image will not have cache22-resign-uki and will not expect sd-boot + per-machine UKI on the ESP.
For cross-bootc moves, use cache22-repair from the cache22 live ISO instead. See Repair.
See also
cache22-updatefor the within-variant update flow.- Pinning and Rollback for tag mechanics.
- Variants for what each variant ships.