Omarchy 很适合这样一种 Linux 用户：喜欢 Arch Linux 的简洁和可控，又不太想从零开始花几天时间配置 Hyprland、终端、主题、快捷键和各种桌面工具。

问题是，如果你的电脑是一台 Apple Silicon Mac，事情就没那么简单了。

Omarchy 官方 ISO 面向 x86_64，而 M1、M2、M3、M4 Mac 是 aarch64。Parallels 虽然可以非常高效地虚拟化 ARM Linux，但它不能把一个 x86 Linux 发行版凭空变成 ARM。

因此，在 Apple Silicon 上运行 Omarchy 4，真正的问题并不是： 如何把 Omarchy ISO 装进 Parallels？ 而是：如何先建立一个 ARM64 Arch Linux，再把 Omarchy 4 的桌面环境和软件栈移植到它上面？ 这两者有本质区别。

一条并不存在的官方安装路径

Omarchy 4，也就是 Quattro，相比之前的版本已经发生了相当大的变化。

它仍然建立在 Arch Linux 和 Hyprland 之上，但桌面 Shell 已经重新设计：Waybar、Walker、Mako、SwayOSD、hyprlock、hypridle、swaybg 等多个独立组件，被整合进一个基于 Quickshell 的长期运行 Shell 进程。

这让 Omarchy 4 更像一个完整的、具有明确设计语言的桌面环境，而不再只是“一套配置好的 Arch + Hyprland”。

但官方安装链仍然主要假定：

x86_64 PC
   ↓
Omarchy ISO
   ↓
Arch Linux
   ↓
Omarchy packages
   ↓
Hyprland + Quickshell

Apple Silicon + Parallels 则是：

Apple Silicon
      ↓
Parallels ARM VM
      ↓
Arch Linux ARM
      ↓
ARM64 Omarchy packages
      ↓
Hyprland + Quickshell

真正困难的地方，恰恰发生在中间两层。Omarchy 官方 ISO 是 x86_64；官方软件源和不少安装逻辑同样默认 x86_64。

所以不能简单执行：

curl <https://omarchy.org/install> | bash

事实上，在这种 ARM 环境中最好不要运行官方安装脚本，因为它会修改 Pacman 配置并指向 Omarchy 的 x86 软件源，随后 ARM 环境中的 Pacman 就会开始出现 404 等错误。

第一步：先安装一个干净的 Arch Linux ARM

解决问题的思路其实很 Unix：

既然 Omarchy ISO 不能启动，那就不要从 Omarchy ISO 开始。

先建立一个正常工作的 Arch Linux ARM。

可以使用 Archboot 提供的 aarch64 ISO，在 Parallels 创建：

Type: Other Linux
CPU: 4 cores
Memory: 8 GB
Disk: 128 GB
Architecture: ARM64

这些并不是严格的最低配置，只是一个比较舒服的实验环境。

磁盘可以采用类似：

/dev/sda
├── EFI       512 MB
├── SWAP        8 GB
└── ROOT       剩余空间

使用 GPT 分区表。

然后安装最基本的 Arch 环境：

pacstrap /mnt \
  base \
  base-devel \
  linux \
  grub \
  efibootmgr \
  networkmanager \
  git \
  terminus-font \
  nano

接着：

genfstab -U /mnt >> /mnt/etc/fstab
arch-chroot /mnt

完成正常的 Arch Linux 初始化，包括：

timezone
locale
hostname
root password
普通用户
sudo
NetworkManager
GRUB

在 ARM64 UEFI 环境中安装 GRUB：

grub-install \
  --target=arm64-efi \
  --efi-directory=/boot \
  --bootloader-id=GRUB

grub-mkconfig -o /boot/grub/grub.cfg

至此，我们还没有安装 Omarchy。

得到的只是：

Arch Linux ARM running inside Parallels。

但这恰恰是整个方案最重要的基础。

第二步：第一时间配置 SSH

这是整个安装过程中非常值得借鉴的一个技巧。

不要试图一直在 Parallels 虚拟机窗口里敲几十行命令。ARM Arch 下 Parallels Tools 的支持并不完整，因此你可能没有习惯中的：

• macOS / VM Clipboard Sharing
• Dynamic Resolution
• 完整的桌面集成

最简单的方法是先安装 SSH：

sudo pacman -S openssh
sudo systemctl enable --now sshd

查看虚拟机 IP：

ip a

然后直接从 Mac：

ssh username@VM_IP

之后绝大多数安装工作都可以在 macOS Terminal、Ghostty 或其他终端中完成。

这不仅解决复制粘贴问题，也意味着你可以很方便地让 Claude、ChatGPT 或 Codex 生成命令，再直接复制到 SSH Session 中执行。

如果使用 Ghostty，还可能碰到一个小问题：

unknown terminal type

可以临时让 ARM Linux 使用更通用的 terminal definition：

export TERM=xterm-256color

或者写进：

~/.bashrc

第三个问题才是真正的坑：Pacman

安装过程最容易让人误判的问题，不是 Hyprland，也不是 Parallels，而是：

Pacman repository architecture。

Arch Linux ARM 使用自己的 repository：

mirror.archlinuxarm.org

而 Omarchy 的安装脚本默认认为当前系统是 x86_64，因此会把 /etc/pacman.conf 和 mirrorlist 修改成 Omarchy 自己的 x86 配置。结果通常就是：

404
failed retrieving file
database not found

而且这个问题并不是修一次就结束。Omarchy 自己的一些 Setup / Update 脚本也可能再次把配置恢复成 x86 模板。因此必须始终记住：

Omarchy configuration
        ↓
assumes x86_64
        ↓
may overwrite pacman.conf
        ↓
ARM repositories disappear
        ↓
pacman fails

Arch Linux ARM 的 mirrorlist 应保持类似：

Server = <http://mirror.archlinuxarm.org/$arch/$repo>

这里还有一个很容易忽略的区别。

Arch Linux ARM 使用：

$arch/$repo

而不是普通 Arch 镜像中经常看到的：

$repo/$arch

一个变量顺序就足以让你浪费很长时间排查。

Omarchy 4 的 ARM 包从哪里来？

这里是整个方案最有意思的部分。

社区项目 omarchy-mx-mac 已经在尝试解决 Apple Silicon 上运行 Omarchy 的问题，其主要目标是：

Apple Silicon
      ↓
Asahi Linux
      ↓
Omarchy

也就是直接在 Mac 裸机上运行，而不是运行在 Parallels VM 中。但其中很多 Omarchy 软件包本身并不依赖 Asahi 硬件。

例如：

omarchy-keyring
omarchy-settings-dev
omarchy-dev
omarchy-nvim
quickshell-git
ttf-jetbrains-mono-nerd-basic

这些包要么是：

aarch64

要么与体系结构无关。于是就出现了一条很巧妙的路径：

omarchy-mx-mac
      │
      ├── ARM64 Omarchy packages
      │
      └── installation logic
                 ↓
          借用这些成果
                 ↓
      Arch Linux ARM VM
                 ↓
            Parallels

换句话说，我们并不是在 Parallels 中运行 Asahi Linux。只是借用了社区为 Asahi / Apple Silicon 构建出来的 ARM64 Omarchy 软件包。这是整个移植方案的核心。

不要把 Asahi 的硬件依赖一起装进去

社区 ARM bundle 中包含 Omarchy 本身需要的软件列表，但其中一些依赖是专门针对 Asahi Linux 的。例如：

linux-asahi
linux-asahi-headers
asahi-fwextract
asahi-desktop-meta

Parallels VM 根本不需要这些东西。因此安装逻辑应该是：

Omarchy dependencies
        ↓
过滤 Asahi hardware packages
        ↓
检查 Arch Linux ARM repository
        ↓
安装能够直接获得的 ARM packages
        ↓
单独处理缺失的软件

原始实践中，大部分依赖都能从 Arch Linux ARM 获得。真正需要额外处理的只有少量软件，例如：

aether
cliamp
localsend
mise
python-terminaltexteffects
ttf-ia-writer
ufw-docker
xdg-terminal-exec
yaru-icon-theme
yay

其中不少可以通过 PKGBUILD 在 ARM 环境直接构建。这也是 Arch Linux 生态非常强大的地方：

**没有 binary package，并不意味着软件不能运行。**只要源代码和 PKGBUILD 本身没有强依赖 x86，很多软件都可以直接：

makepkg -si

重新构建为 ARM64。

安装 Omarchy，本质上是在重放它的 Provisioning

到了这里，就会发现 Omarchy 一个很有意思的设计特点。Omarchy 并不是一个传统意义上“所有东西都封装在 ISO 中”的 Linux Distribution。

它很大程度上是一套：

Arch Linux
+
Packages
+
Configuration
+
Provisioning Scripts
+
Migration Scripts

因此只要能够：

1. 安装正确的软件包；
2. 满足依赖；
3. 重放系统 Provisioning；
4. 重放用户 Provisioning；

理论上就能在一个非标准 Arch 环境中“生成”出 Omarchy。

核心流程类似：

omarchy-apply-system

以及：

omarchy-provision-user

这也是为什么这种看似“不受支持”的移植最终能够成功。我们并不是复制一个 Omarchy 系统。

而是在另一个 Arch Linux 上：重新执行 Omarchy 用来构造自己的过程。

Provisioning 失败时，不要只看终端

Omarchy 的 Setup 脚本还有一个很容易踩坑的特点：终端上可能看不到多少信息。

真正有用的日志在：

/var/log/omarchy-install.log

如果 Provisioning 中途停止，应首先：

less /var/log/omarchy-install.log

找到：

Failed:

再判断这个失败到底属于：

真正的软件依赖问题

还是：

VM 中根本不存在的硬件功能

例如 Snapper 配置就是典型例子。如果虚拟机根文件系统不是 Btrfs，而是 ext4：

snapper.sh

自然可能失败。

类似地，某些脚本可能：

• 假设存在 Asahi kernel；
• 下载 x86 Node.js；
• 假设存在某个 x86-only package；
• 配置裸机环境才需要的功能。

这些并不意味着 Omarchy 无法运行。

只是说明：Omarchy 的 Provisioning 对运行环境存在一些隐含假设。

VM 移植的工作，就是逐个识别这些假设。

第一次进入桌面还有两个坑

即使安装完成，也不一定马上看到漂亮的 Omarchy Desktop。

第一个问题可能出现在登录界面。

因为这个用户是在安装 Omarchy 之前创建的，而 Omarchy 官方 ISO 安装过程中通常会预先配置用户名。手工安装没有经过这个步骤，因此 Login Manager 可能拿不到用户名。一种简单解决办法是启用 Autologin。

第二个问题更加隐蔽。

第一次进入桌面时，你可能看到的只是：

Plain Hyprland。

甚至还有 Hyprland 默认的黄色 Warning Bar。

原因同样与安装顺序有关。

Omarchy 的用户配置通过：/etc/skel 提供。

但 Linux 的 /etc/skel 只会在创建新用户时复制到：/home/username

我们的用户却是在 Omarchy 安装之前创建的。

因此这些配置自然不会出现。

重新安装 Omarchy 用户配置：

omarchy-reinstall-configs

再重新进入 Session，真正的 Omarchy Desktop 才会出现。

这个问题其实很好地说明了 Linux 中 /etc/skel 的工作方式。

分辨率问题

Parallels Tools 在这个组合下并不能提供完整的动态分辨率支持。

虚拟机可能默认只有：1024 × 768

一个实用的 workaround 是直接通过 Kernel Video Mode 指定虚拟显示器分辨率。

例如：video=Virtual-1:2560x1600@60 加入：/etc/default/grub 中的：GRUB_CMDLINE_LINUX_DEFAULT

然后重新生成：

sudo grub-mkconfig -o /boot/grub/grub.cfg

重启后即可获得适合 Mac 屏幕的分辨率。

不如 Parallels Desktop 中的动态 Retina Resize 优雅，但至少 Omarchy 已经真正可用了。

最终得到的是什么？

整个架构可以概括成：

┌─────────────────────────────┐
│          macOS              │
│      Apple Silicon          │
└──────────────┬──────────────┘
               │
       Apple Virtualization
               │
┌──────────────▼──────────────┐
│      Parallels Desktop      │
│        ARM64 VM             │
└──────────────┬──────────────┘
               │
┌──────────────▼──────────────┐
│      Arch Linux ARM         │
│          aarch64            │
└──────────────┬──────────────┘
               │
│  ARM Omarchy packages
│  + PKGBUILD
│  + provisioning
│
┌──────────────▼──────────────┐
│       Omarchy 4             │
│                             │
│  Hyprland                   │
│  Quickshell                 │
│  Omarchy configs            │
│  Omarchy applications       │
└─────────────────────────────┘

最终得到的并不是模拟运行的 x86 Linux。

从：

Arch Linux

到：

Hyprland
Quickshell
Omarchy

整个 Linux 用户空间基本都是：

aarch64

原生 ARM64。

这也是为什么它在 Apple Silicon 上能够拥有相当不错的性能。

但它仍然不是一个“正常”的 Omarchy

这点必须说清楚。

能够运行：

不等于得到官方支持。

目前这套环境仍然存在几个明显限制。

首先是升级。

omarchy update 可能重新写入 x86 Pacman 配置，因此升级之后可能需要再次恢复 Arch Linux ARM repository。

这意味着：

Update
   ↓
Omarchy restores x86 config
   ↓
Pacman breaks
   ↓
restore ARM config

在这个问题被上游正式解决之前，这仍然是一套需要维护者意识的系统。

其次是 Parallels Integration。

在这种 ARM Arch 环境中，不要期待和 Ubuntu ARM VM 一样完整的：

Clipboard Sharing
Dynamic Resolution
Multi-monitor
Desktop Integration

SSH 仍然是 Host 与 Guest 之间最可靠的管理通道。

最后是 x86-only applications。

例如某些 Omarchy Application Catalog 中的软件只有 x86_64 binary。

这种软件并不会因为 Omarchy Desktop 成功启动，就自动变成 ARM64。

真正有意思的不是“Omarchy 跑起来了”

折腾完这一圈，我觉得最有价值的其实不是：

Omarchy 4 可以在 M 系列 Mac 的 Parallels 中运行。

而是这次安装揭示了现代 Linux Distribution 的另一种形态。

传统 Linux Distribution 很容易让人想到：

ISO
→ Installer
→ Filesystem
→ Desktop

但 Omarchy 更接近：

Arch Linux
        +
Package Set
        +
Configuration
        +
Provisioning
        +
Migration
        =
Omarchy

ISO 只是这个过程的一种入口。

一旦理解这一点，“Omarchy 不支持 ARM64 VM”这句话的含义就发生了变化。

它并不意味着：

Omarchy fundamentally cannot run on ARM64

更多意味着：

The official installation path
does not support this environment yet.

而 Linux 最有趣的地方，恰恰就在这个 yet。

社区已经为 Apple Silicon / Asahi Linux 构建了 ARM64 Omarchy packages；Arch Linux ARM 提供了完整的 ARM 用户空间；Parallels 提供了高性能 ARM 虚拟化；Omarchy 自己又把大量系统构建逻辑保存在可以重新执行的 Provisioning 脚本中。

把这些原本并不是为彼此设计的东西连接起来：

Parallels
     +
Arch Linux ARM
     +
Omarchy ARM packages
     +
PKGBUILD
     +
Provisioning

一个官方并不存在的系统，就这样出现了。

这大概也是折腾 Linux 最有趣的地方：

很多时候，“不支持”并不是“不可能”。它只是意味着，还没有人为你把那条路铺好。