Channels and updates

A channel decides two things: which signed image a new install writes, and which kernel an installed Mac follows. Macs are offered two, stable and rc.

Channel	What a new install gets today	Who it is for
stable	os-v4.0.4-mac.1.20260924-rc, the Aurora kernel on the stable lane	Daily drivers
rc	os-v4.0.4-mac.1.20260924-rc, the Aurora kernel on the release-candidate pin	Macs that should take new Aurora kernels first

Kernels#

The default kernel is linux-aurora, built here from aurora-silicon/linux. It builds on the Asahi Linux kernel and adds DisplayPort alt-mode and USB4 external monitors, variable refresh rate, the camera signal processor and the always-on processor; see Hardware support. Macs installed from the earlier Asahi stable image still run linux-asahi, which comes from the Asahi Linux project through the [asahi-alarm] repository.

An installed Mac is therefore in one of three states, and the updater refuses any other combination:

Channel	Kernel	Meaning
stable	linux-asahi	A legacy Asahi Mac, installed from the stable image before 2026-09-23
stable	linux-aurora	An Aurora Mac on the stable lane, which carries rc's hardware-qualified kernel; includes new Stable installs
rc	linux-aurora	An Aurora Mac on the release-candidate pin

New installs on both channels get Aurora. What remains is migrating the legacy Asahi Macs and retiring the Asahi kernel; they are migrated rather than stranded. Until that finishes, "stable" describes a channel, not a single kernel.

There is a third Aurora lane, edge, which floats on the upstream branch head. It is for lab Macs. The installer does not offer it and omarchy-channel-set refuses it on a Mac.

Picking a channel#

The installer opens on Stable at every launch. To install on rc, choose it in the Release Channel menu before the download starts; the choice lasts until the app quits.

Choose at install time, because the kernel family stays. A Mac installed on the Asahi kernel stays on it, and the switch command refuses: moving between kernel families is not available. A Mac on the Aurora kernel can move between the Aurora lanes, stable and rc, with the ordinary Omarchy command, which records the request, takes the update lock and runs an update that moves the kernel and proves it boots:

omarchy-channel-set rc

The Mac's own record lives in /var/lib/omarchy/apple-silicon-channel, and the installed kernel is named in /usr/share/omarchy/apple-silicon-kernel. A lane switch is a request until an update has proven the new kernel boots; only then is it recorded as done.

How an update arrives#

omarchy update behaves as it does on x86, with three Apple-specific steps in front:

1. Runtime bundle. omarchy-update-asahi-bundle reads the runtime channel pointer, verifies the release descriptor, the six-package manifest, the checksums and the signatures, then installs omarchy-keyring, omarchy-settings-dev, omarchy-dev, omarchy-nvim, quickshell-git and ttf-jetbrains-mono-nerd-basic as one transaction. It refuses to downgrade any of them, with one exception: a package the retired [omarchy-aarch64] repository built, proven by its name, version and build date in that repository's sync database.
2. Legacy repository cleanup. On a Mac that came from the omarchy-mac project, omarchy-update-asahi-legacy-repository removes its unsigned [omarchy-aarch64] repository from /etc/pacman.conf (backup under /var/lib/omarchy/backups/), keeps [omarchy] ahead of what that repository shadowed, and replaces obsidian-appimage and hyprland-preview-share-picker-git with the [omarchy] packages. It also replaces those two packages where they came from elsewhere, such as the AUR. Once no pacman configuration file lists the repository, it takes that repository's leftover sync files out of /var/lib/pacman/sync/. Signatures and file lists are deleted. The database moves to /var/lib/omarchy/retired-repositories/, where the bundle step still reads it, while an installed package still has a build from it (same name, version and build date), and is deleted once none does. When that cannot be decided (an unreadable database or local package entry), or an earlier kept copy that differs still proves a package, the database stays. On a Mac with none of the repository, those packages or those files it does nothing. A step that cannot finish keeps the section, the legacy package or the database in place and the next update tries again; the update carries on either way.
3. Package repository. omarchy-update-asahi-repository points [omarchy] at the current promoted package channel. Rollbacks of the package or release sequence are refused.
4. Everything else comes from the live Arch Linux ARM and Asahi mirrors, as upstream.

A snapper snapshot is taken before the package sync. snapper list shows it. On a lab Mac with /var/lib/omarchy/snapshot-restore.enabled, omarchy-snapshot restore <number> reboots into a writable clone of a snapshot.

When a new kernel is installed the updater rebuilds the initramfs, refreshes m1n1 and the device trees, runs the boot check and offers a reboot.

What is signed, and by what#

Artefact	Key
Packages in [omarchy]	The ARM repository signing subkey
Runtime bundle and release descriptors	The Omarchy MX Mac release key, 5983B1CA…5959
Channel catalogs read by the installer	One Ed25519 key that never leaves the owner's Keychain
Installer app and .pkg	Apple Developer ID T2C384FJBD, notarized

Only four keys on the download host are ever rewritten: each channel's catalog.signed.json and channel.json, and each channel's installer .pkg and installer.json. Everything under releases/ is immutable and held by a bucket lock.