Install menu offers x86_64-only packages on aarch64: every entry fails with `target not found` in a floating terminal that closes

[alexandru-savinov]

Summary

Omarchy's install paths name packages that only exist for x86_64, and nothing in
the tree checks the running architecture, so on aarch64 the Install menu offers
entries that can never succeed. Each one fails in a floating terminal that prints
error: target not found: <pkg> and closes, usually faster than it can be read.

System details

• Omarchy 4.0.0.alpha (from /usr/share/omarchy/version)
• Arch Linux ARM, uname -m = aarch64, kernel 7.2.0-2-aarch64-ARCH (not Asahi)
• QEMU/UTM guest on an Apple Silicon host (product_name = QEMU Virtual Machine,
  /proc/device-tree/compatible empty)
• pacman repositories configured: core, extra, alarm, aur

Mechanism

Three pieces combine:

1. bin/omarchy-pkg-add is pacman-only. It runs
   sudo pacman -S --noconfirm --needed "$@" and never touches the AUR
   (bin/omarchy-pkg-aur-add is the separate yay path). Any name that is not in a
   configured sync repository fails outright.
2. bin/omarchy-install-app hides the failure. It wraps omarchy-pkg-add in
   omarchy-launch-floating-terminal-with-presentation, so the pacman error appears
   in a transient floating window and disappears. The same is true of every
   omarchy-launch-floating-terminal-with-presentation omarchy-install-* menu action.
3. Nothing anywhere checks the architecture. In 4.0.0.alpha,
   grep -rIn 'x86_64\|aarch64\|uname -m\|arm64\|HOSTTYPE\|MACHTYPE' bin default install config etc shell
   returns no hits. The omarchy-hw-* predicate family covers CPU vendor, GPU,
   chassis and peripherals, but has no architecture predicate, so no menu entry can
   currently gate on one.

The [omarchy] repository compounds this. default/pacman/pacman-stable.conf points
it at https://pkgs.omarchy.org/stable/$arch, and that tree is x86_64-only:

$ curl -o /dev/null -w '%{http_code}\n' https://pkgs.omarchy.org/stable/x86_64/omarchy.db
200
$ curl -o /dev/null -w '%{http_code}\n' https://pkgs.omarchy.org/stable/aarch64/omarchy.db
404

Most of the AUR-derived apps in the Install menu resolve out of [omarchy] on x86_64
(1password, cursor-bin, dropbox, lmstudio-bin, once-bin,
openai-codex-desktop, spotify, sublime-text-4, symfony-cli,
visual-studio-code-bin, voxtype-bin, … — 202 packages in the x86_64 database), so
on aarch64 they have no source at all through the pacman-only path.

Reachable entries whose package cannot exist on aarch64

Every row below is offered from Menu → Install with no hardware or architecture
gate. Their only disabled predicate is omarchy-pkg-present <pkg>, which is false on
a machine where the package could never have installed — so the entry renders enabled.
arch= values are from the authoritative PKGBUILD at
https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=<pkg>; "not in any repo" was
checked with pacman -Si against core/extra/alarm/aur.

Menu path	Command it runs	Package	Why it fails on aarch64
Install → AI → Ollama	omarchy-install-app Ollama ollama	ollama	AUR arch=('x86_64'); not in any aarch64 repo. Reproduced on this host — /var/log/pacman.log [2026-08-27T20:41:18+0300] [PACMAN] Running 'pacman -S --noconfirm --needed ollama', error: target not found: ollama. Ollama does publish ollama-linux-arm64.tar.zst upstream, so this is a packaging assumption rather than a support gap.
Install → AI → LM Studio	omarchy-install-app 'LM Studio' lmstudio-bin	lmstudio-bin	AUR arch=('x86_64')
Install → Editor → Cursor	omarchy-install-and-launch Cursor cursor-bin cursor	cursor-bin	AUR arch=('x86_64')
Install → Editor → Zed	omarchy-install-editor-zed → omarchy-pkg-add zed omazed	zed, omazed	no aarch64 zed in extra/alarm; AUR zed is arch=('x86_64'). omazed is arch=('any') but AUR-only, which the pacman-only path cannot reach.
Install → Service → 1Password	omarchy-install-service-1password → omarchy-pkg-add 1password 1password-cli	1password	AUR arch=('x86_64') (1password-cli does list aarch64)
Install → Service → Spotify	omarchy-install-service-spotify → omarchy-pkg-add spotify	spotify	AUR arch=('x86_64')
Install → Service → Dropbox	omarchy-install-service-dropbox → omarchy-pkg-add dropbox …	dropbox, nautilus-dropbox	AUR arch=("x86_64") for both
Install → Development → PHP → Symfony	omarchy-install-dev-env symfony → omarchy-pkg-add symfony-cli	symfony-cli	AUR arch=('x86_64')
Install → Browser → Edge	omarchy-install-browser edge → omarchy-pkg-aur-add microsoft-edge-stable-bin	microsoft-edge-stable-bin	AUR arch=('x86_64') — fails in yay rather than pacman, but is equally unreachable

Reachable entries whose package could work on aarch64

These are a milder case of the same mechanism: the upstream PKGBUILD does list
aarch64, but the package lives only in the AUR and in [omarchy], and
omarchy-pkg-add is pacman-only while pkgs.omarchy.org has no aarch64 tree. So they
fail too, even though nothing about them is architecture-bound.

Menu path	Package	Upstream arch=
Install → AI → ChatGPT Desktop	openai-codex-desktop	('x86_64' 'aarch64')
Install → Editor → VSCode	visual-studio-code-bin	('x86_64' 'aarch64' 'armv7h')
Install → Editor → Sublime Text	sublime-text-4	('x86_64' 'aarch64')
Install → Service → ONCE	once-bin	('x86_64' 'aarch64')
Install → Service → NordVPN	nordvpn-bin	('x86_64' 'i686' 'armv7h' 'aarch64' 'armeabi')

What is not affected

For completeness, I traced every x86-only package name in bin/, install/ and
default/ and confirmed the following are correctly gated behind an omarchy-hw-*
predicate or a hardware-detection guard, so they never run on ARM and are not part
of this report: intel-lpmd, thermald, intel-media-driver, libvpl, vpl-gpu-rt,
libva-intel-driver, intel-ipu7-camera, linux-ptl, linux-ptl-headers,
sof-firmware, asusctl, supergfxctl (when: omarchy-hw-hybrid-gpu),
broadcom-wl, macbook12-spi-driver-dkms, dell-xps-touchpad-haptics,
dell-xps13-sidecar-amps, qmk-hid, tuxedo-drivers-nocompatcheck-dkms,
yt6801-dkms, linux-firmware-marvell, the nvidia.sh kernel/driver set, and the
ollama-cuda / ollama-rocm branches of install.ai.ollama (guarded by
omarchy-cmd-present nvidia-smi / rocminfo).

I also deliberately left the gaming entries (install.gaming.steam,
.lutris, .heroic) out of the tables. They are ungated and they do fail
(steam is multilib-only, wine-staging is arch=('x86_64' 'i686'),
heroic-games-launcher-bin is arch=('x86_64')), but the whole stack is x86-bound by
nature and arguably belongs to a different discussion.

One adjacent case I could not classify cleanly and am flagging as unverified:
install.gaming.xbox-controllers runs omarchy-pkg-add linux-headers xpadneo-dkms.
xpadneo-dkms is arch=(any), but linux-headers does not exist under that name on
ALARM (linux-aarch64-headers) or Asahi (linux-asahi-headers). That is a kernel
package-naming assumption rather than an architecture one, and several
hardware-gated scripts share it.

How this differs from the existing reports

• Dictation installer offers x86-only voxtype-bin on Apple Silicon, making Voxtype uninstallable #8530 and PR Offer a source-build fallback when Voxtype's binary needs AVX2 #8316 address the Voxtype install path specifically, and Offer a source-build fallback when Voxtype's binary needs AVX2 #8316
  is the right shape for it — a source-build fallback gated on the new
  omarchy-hw-x86-64-v3 predicate. But that fix is local to
  bin/omarchy-voxtype-install; the same class of failure remains in every other
  ungated Install entry above.
• Dictation installer offers AVX2-only Voxtype on CPUs without AVX2 #7883 and PR Skip Claude and Pi on CPUs without SSE4.2/POPCNT #8149 cover the related AVX2/SSE4.2 baseline problem within
  x86_64.
• PR Guard three x86-only assumptions so Omarchy can install on aarch64 #8039 covers the aarch64 install-time path (mkinitcpio thunderbolt,
  [multilib] in pacman.conf, mise-work) and notes the pkgs.omarchy.org aarch64
  gap as out of scope. This issue is about the post-install, user-facing menu.
• ERROR: 1password-beta is not available for 'aarch64' arch #87 (closed) and om-arm-archy ? #803 (closed) are much older and predate the current menu.

I did not find an open report covering the general case.

Suggested direction

Offered as options, not a prescription:

1. A preflight in omarchy-pkg-add. Before shelling out to pacman, check that each
   name resolves for the running architecture and, when it does not, fail with a
   message that says so — instead of letting error: target not found scroll past in a
   window that closes. This would cover every call site at once, including the ones
   reached from scripts rather than the menu.
2. disabled predicates on the menu entries whose package cannot exist on the
   running architecture, so the entry is greyed out rather than offered. PR Offer a source-build fallback when Voxtype's binary needs AVX2 #8316's
   bin/omarchy-hw-x86-64-v3 already returns false for any non-x86_64 machine
   ([[ $machine == "x86_64" ]] || exit 1 before the flag checks), so it could serve as
   that gate directly, or a narrower omarchy-hw-x86-64 predicate could be split out of
   it.
3. Publishing an aarch64 tree on pkgs.omarchy.org would independently fix the
   second table, since those packages already build for ARM.

(1) and (2) are complementary: (2) keeps the dead entries out of the user's way, (1)
catches the script-level call sites and gives a readable error when a package is missing
for any other reason.

Happy to open a PR for whichever of these you'd prefer — the omarchy-hw-x86-64
predicate plus disabled gates is the smallest change, and the omarchy-pkg-add
preflight is the one that covers the most ground.

[birkskyum]

Confirmed the ChatGPT case on a physical Lenovo Yoga Slim 7x / Snapdragon X Elite running Omarchy 4.0.1rc3-1.5 on Arch Linux ARM. Before installing anything, the normal installer command failed with:

$ omarchy-install-ai-chatgpt
Installing ChatGPT...
error: target not found: openai-codex-desktop

The command returned 1 before reaching its launch step. The install window disappearing was the user-visible symptom. This machine had only core, extra, alarm, and aur configured, with no [omarchy] repository.

An important availability update as of September 6:

• https://pkgs.omarchy.org/edge/aarch64/omarchy.db now returns 200 and contains 115 packages. Stable and RC still return 404 for aarch64.
• ChatGPT 26.901.20858-1, VS Code, 1Password, LocalSend, NordVPN, ONCE, Perplexity, OpenClaw, Sublime Text, and Voxtype are in that ARM edge database. The corresponding package download URLs return 200.
• I downloaded the ChatGPT ARM package, verified its checksum and trusted Omarchy signature, and installed only that package without switching repositories or upgrading the system. It launched as the desktop user and created a visible, mapped ChatGPT window in Hyprland. This is an installation/launch smoke test, not a claim that every application feature is tested.

So ChatGPT is not an x86-only application. OpenAI publishes a Linux ARM64 build, and the current Omarchy recipe already packages it.

I think the useful distinction here is package availability in the configured repositories versus genuine architecture support. Keeping the failure visible and explaining a missing repository/package would help without hiding ARM-capable apps behind a blanket x86 gate. Stable/RC publishing and the supported setup for existing ARM installations are tracked in omacom/omarchy-pkgs#199. Further app packaging is proposed in omacom/omarchy-pkgs#240.