Omarchy 4 (quattro) on Apple Silicon: a one-script build for a native aarch64 UTM VM

[ggalancs]

Every guide I could find for running Omarchy in a VM on an M-series Mac
stops at 3.x or earlier. #452, the thread everyone lands on, was written in the
1.x days — August 2025, Parallels, bootstrapping Arch from an Ubuntu live
session — and the freshest thing in its comments is jondkinney's 3.x fork and
PR #1897, Add aarch64 support for Omarchy 3.x. On bare metal it's a different
story (see prior art below), but that needs an M1 or M2.

I wanted 4, in a VM, on newer silicon, and hit a wall worth writing down — so I
automated the whole thing:

https://github.com/ggalancs/omarchy-arm-utm

git clone https://github.com/ggalancs/omarchy-arm-utm.git
cd omarchy-arm-utm
./build-omarchy-arm.sh

One self-contained script, eight resumable phases, no clicking in UTM. The one
full run I timed took 57 minutes for build through package on an M3 Max,
without OBS and Pinta; add ~50 minutes if you include them.

Or skip the build entirely — the image it produces is on the Internet
Archive, sanitised and with a generic user:

https://archive.org/details/omarchy-arm-utm · 6.5 GB · sha256 9d6afb16843bd868…

Unzip, double-click the .utm, done. User omarchy, password omarchy
(change it with passwd). I verified the whole recipient path on a clean
import: boots to a themed desktop, Hyprland and quickshell up, 436
omarchy-* commands, no SSH keys and a fresh machine-id per VM. It asks six questions, all pre-filled from your Mac (timezone from
/etc/localtime, keyboard from macOS preferences, cores/RAM from sysctl), so
Enter accepts everything. --yes skips them.

The trap that cost me the most

git clone of basecamp/omarchy does not give you master (3.8.5). The
default branch is quattro (4.x), and they are different products:

	master (3.8.5)	quattro (4.x)
Bar	waybar	quickshell (omarchy-shell)
Hyprland config	.conf	Lua (hyprland.lua, bootstrap.lua)
Distribution	scripts in ~/.local/share	pacman package in /usr/share/omarchy

Worth being precise here, because I got it wrong myself at first: that package
is not x86_64-only. Its PKGBUILD says arch=('any') and it installs the
commands into /usr/bin. What is x86_64-only is the repository it's published
in — stable-mirror.omarchy.org/core/os/aarch64/ is a 404 while x86_64 is a
200 — so on ARM there is simply nowhere to install it from.

Copy just the dotfiles instead and OMARCHY_PATH goes unset: bashrc errors
out and Hyprland can't find bootstrap.lua, so you get a bare compositor rather
than a desktop. The build reproduces by hand what the package would have
installed — /usr/share/omarchy, the ~435 omarchy-* commands, profile.d,
the uwsm env.d drop-in and the SDDM theme. One deliberate difference: they go in
/usr/local/bin rather than /usr/bin, so nothing collides with pacman.

Related: quattro retires mako, swayosd, walker and elephant —
quickshell is the bar, the menu, the OSD and the notification daemon. Leaving
mako installed is actively harmful: it grabs
org.freedesktop.Notifications over D-Bus and your toasts come out unstyled.

What works

• Arch Linux ARM aarch64, HVF-accelerated (no emulation), btrfs @/@home,
  systemd-boot
• Hyprland 0.56.1 with the full Omarchy 4 stack, themes, and omarchy-update
  working (with snapper snapshots and a post-update hook that keeps the checkout
  in sync)
• 17 Omarchy tools built for aarch64 that upstream doesn't ship for ARM:
  tensaku, omacalc, omacut, omawrite, aether, cliamp, ttfx,
  omarchy-nvim, mise, tzupdate, hyprland-preview-share-picker, yay…
• Optionally OBS Studio and Pinta, also built for ARM

Of the 148 packages in omarchy-base.packages, 123 already exist in Arch
Linux ARM. The prepare phase computes that intersection against the live
branch on every run, so it does not rot when Omarchy changes packages.

What does not

• No GL acceleration inside the VM. Under virtio-gpu, GPU clients map but
  never paint — only wl_shm clients render. The discriminating test that found
  it: foot draws, alacritty doesn't. Fixed with LIBGL_ALWAYS_SOFTWARE=1,
  which means software rendering and no blur/shadows.
• Resolution is fixed at boot. Changing the mode at runtime whites out the
  screen; applied from boot it's fine.
• herdr needs Zig 0.15; Arch Linux ARM only packages 0.16.
• Single monitor.
• Proprietary apps (1Password, Obsidian, Typora, LocalSend, Chrome) are not
  in the image — shipping them would be redistributing third-party binaries.
  There's an opt-in installer that pulls them from their official source on your
  machine. All of them have official ARM64 builds.

Other things that took a while to find

• The ESP must be mounted after extracting the rootfs: the ALARM tarball has
  symlinks in /boot and vfat can't hold them.
• bootctl install --no-variables — the build VM's NVRAM doesn't travel to UTM,
  so boot relies on the fallback \EFI\BOOT\BOOTAA64.EFI.
• The .utm bundle has to be written by hand: utmctl can't create VMs, UTM
  only scans Documents/ at launch, and config.plist needs all ten
  top-level keys (they're decoded with decode(), not decodeIfPresent()).
• The VARS half of aarch64 UEFI is edk2-arm-vars.fd, not
  edk2-aarch64-vars.fd, which doesn't exist.
• Seal the migrations. A normal Omarchy install marks them all on
  completion. Without that, omarchy-update replays ~80 historical migrations
  and dies on the first x86-only package.
• macOS eats Cmd before UTM sees it, so the VM ships with
  altwin:swap_lalt_lwin: Option (⌥) acts as SUPER.

Full write-up (in Spanish, but the code blocks and tables carry most of it):
ARTICULO.md.
Step-by-step run guide: EMPEZAR.md.

Prior art — and when not to use this

Checking before posting saved me from overclaiming, so, honestly:

• omarchy-mac/omarchy-mac (active,
  thousands of users) already does Omarchy 4 on Asahi Alarm, M1/M2 bare metal, one
  command, with LUKS. It even publishes
  the aarch64 pacman repo
  that upstream doesn't. If you have an M1 or M2 and want it on the metal, use
  that, not this — you get a real GPU.
• jondkinney/armarchy covers Omarchy
  3.x on Asahi and VMs.

A VM is worth it for the cases those can't reach: M3, M4 and newer (Asahi's
installer is M1/M2 only, M3 is WIP, M4 hasn't started), keeping macOS untouched
with no repartitioning or reduced-security boot, and external monitors —
Asahi still lists USB-C displays and Thunderbolt as unsupported.

One correction, since it gets repeated

Omarchy 4 does not refuse to run on ARM64. The uname -m guard people cite
is install/preflight/guard.sh on master (3.x). On quattro the
preflight/ directory doesn't exist and uname -m appears zero times in the
branch. What's missing is the repository: stable-mirror.omarchy.org serves
core/os/x86_64/core.db (200) and not core/os/aarch64/ (404), and
install/post-install/pacman.sh points pacman there. The tree itself is shell,
Lua and QML, and the omarchy package is arch=('any').

That reframes the problem: it's a packaging gap, not a porting one. Of the
148 packages in omarchy-base.packages, 121 are already in Arch Linux ARM
by name (123 with two obvious substitutions); publishing the rest would close
most of the gap for everyone at once —
which is presumably what plans/aarch64-support.md is for.

Unofficial work, no affiliation with Basecamp. When the aarch64 ISO that's
already on the roadmap ships, none of this will be needed.

[ggalancs]

Update — a smaller image, and two bugs fixed.

There is now a omarchy-arm-utm-v2.zip (3.6 GB) on the same item:
https://archive.org/details/omarchy-arm-utm

It is 45% smaller than the first upload, and nothing you would use was removed —
it dropped 675 MB of firmware for hardware a VM cannot have, 458 MB of
documentation, and the .NET SDK that was only needed to build Pinta and OBS.
The Rust and Go toolchains stay, so yay still works.

More importantly it fixes two notifications that never went away:

• "Update System" on every boot, even with nothing pending. The six user
  .service files were never installed into /usr/lib/systemd/user/ —
  upstream ships them in the omarchy-settings package, which has no ARM
  build. So enable-user-units.sh failed every login, and
  omarchy-provision-first-run only marks first-run done if no step fails.
  It repeated forever, re-sending the notification each time.
• "Linux kernel has been updated. Reboot?" after every update.
  omarchy-update-restart looks for a package-owned
  /usr/lib/modules/<ver>/vmlinuz. Arch x86_64's linux ships one; Arch Linux
  ARM's linux-aarch64 puts the image in /boot/Image and ships none, so the
  check can never pass and rebooting does not help.

Already downloaded the first one? You don't need to fetch 3.6 GB again — run
this inside the VM:

curl -fsSL https://raw.githubusercontent.com/ggalancs/omarchy-arm-utm/main/fixes/18-avisos-que-no-se-apagan.sh | bash

The original omarchy-arm-utm.zip stays up until 30 November 2026 so any
link already pointing at it keeps working, then it gets removed.