Omarchy on…：在 Apple 芯片、虚拟机、Steam Deck 与 NixOS 等非默认平台上运行 Omarchy 的实践指南

Omarchy on…：在 Apple 芯片、虚拟机、Steam Deck 与 NixOS 等非默认平台上运行 Omarchy 的实践指南

【免费下载链接】omarchyBeautiful, Modern & Opinionated Linux项目地址: https://gitcode.com/GitHub_Trending/om/omarchy

Omarchy 是一款基于 Arch、Hyprland 与 Quickshell 的 Linux 发行版，默认安装流程针对标准 PC 硬件设计，但它的内核与组件高度可移植。本指南汇总官方手册中“Omarchy on…”一章关于非默认硬件的全部部署路线——Apple M1/M2、macOS 内的 Parallels、VirtualBox、Windows 11 上的 VMware、Steam Deck 与 NixOS——并结合当前仓库中的硬件适配脚本与相邻手册章节，帮助你在决定尝试某条路线之前，准确判断可行性、前置条件与性能预期。

本文是官方手册 manual/49-omarchy-on.md 的直接延伸，逐条覆盖其中提到的每一种“Omarchy on other hardware”方案，并补充与它们强相关的官方支持边界与仓库证据，方便你在阅读社区指南前先建立正确的预期。

先理解前提：Omarchy 是什么，以及它对硬件的基本要求

要在“非默认平台”上跑 Omarchy，首先得明白默认平台上的安装契约是什么。正如 manual/01-welcome-to-omarchy.md 所述，Omarchy 是建立在三条开源地基之上的发行版：

• Arch Linux作为系统底座与软件仓库来源；
• Hyprland作为平铺式 Wayland 合成器，负责全部的窗口布局、工作区与键盘驱动体验；
• Quickshell作为桌面“构建套件”，承载顶栏、菜单、锁屏等 shell/ 目录下的 QML 界面组件。

换句话说，只要一条路线能拿到 Arch 内核与基础用户态（或能把 Omarchy 的核心配置复刻到类似环境），Hyprland/Quickshell 这层桌面经验就可以被复用——这正是 Steam Deck（本身跑 Arch）与 NixOS（可声明式复刻）两条社区移植路线的逻辑起点。

同时，安装层面存在几条通用前置条件，无论在哪种目标上都成立：

• 官方安装走 ISO 流程，可选择全盘安装或“空闲空间安装”（free-space install），默认启用全盘加密，详见 manual/02-getting-started.md；
• 需要关闭 BIOS/固件里的 Secure Boot 与 TPM 才能启动安装介质；
• 默认安装会抹掉所选磁盘，因此评估任何虚拟机或实体机路线前，都要先准备好备份或专门的测试盘。

Apple M1/M2 芯片：基于 Asahi Linux 的社区路线

Apple 自研芯片（M 系列）不属于 Omarchy 官方支持范围——官方手册的 Mac 支持章节明确表示“目前不支持直接在 M 系列 Mac 上安装”。但社区把它跑起来的方式依托于Asahi Linux生态：Asahi Linux 为 Apple Silicon 提供了可用的 Linux 内核与硬件驱动，而 Asahi Alarm 是构建在 Asahi Linux 之上、面向 Apple M1/M2 的 Arch Linux 发行。

由于 Omarchy 本身就是 Arch 系的发行版，理论上它具备在 Asahi Alarm 这套 Arch 底座上运行的条件——正如原手册所说，你可以费一些功夫让 Omarchy 跑在它上面。这条路线目前由社区维护，存在一份用户驱动的完整指南（仓库为omarchy-mac/omarchy-mac）供参考。动手前需要明确的预期是：

• 这是一条“用户驱动”的移植路线，不是官方安装流程，更新节奏与官方 ISO 未必同步；
• 需要在 Asahi Linux 的安装基础上手工叠加 Omarchy 的组件与配置，因此更适合熟悉 Arch 包管理、愿意排障的用户。

顺带一提：Intel Mac 才是官方支持的 Apple 平台

不要因为 Apple Silicon 不在官方支持之列，就以为 Omarchy 与 Mac 无缘。官方手册 manual/44-mac-support.md 记录了完整的Intel Mac 官方支持：安装器会自动探测 Mac 硬件并应用所需的修复。仓库中的安装脚本（install/hardware/apple/）正是这些自动修复的实现证据：

• Broadcom Wi-Fi 固件与驱动：脚本 fix-brcmfmac-supplicant.sh 处理了 brcmfmac 驱动的固件 WPA 握手缺陷，改为在软件层完成握手；
• SPI 键盘驱动：脚本 fix-spi-keyboard.sh 为需要它的 MacBook 型号注入applespi、spi_pxa2xx_platform等内核模块；
• NVMe 挂起修复：脚本 fix-suspend-nvme.sh 针对相同型号修复了从挂起状态恢复的问题；
• T2 芯片机型：脚本 fix-t2.sh 会安装打补丁的linux-t2内核、apple-t2-audio-config音频配置、Apple Broadcom Wi-Fi/蓝牙固件与t2fanrd风扇控制服务，并配置内核模块t2bce_vhci等以支持 Touch Bar 的 Boot Camp 式显示。

如果你手里正是一台 T1/T2 芯片的 Intel MacBook 或 iMac，且接受官方手册中列出的已知限制（例如 T1 机型的 Touch Bar 与声音不可用、T2 机型需要依赖打补丁内核），官方支持路径远比 M 系列上的社区移植稳妥——那条路线也值得先研究。

Apple 虚拟机：在 Parallels 里跑 Omarchy

苹果生态内的第二种常见诉求是“不放弃 macOS，用虚拟机体验 Omarchy”。官方手册给出的事实是：可以在Parallels VM内安装 Omarchy，但这是相当繁琐的过程——Parallels 以虚拟化 macOS 的兼容性著称，而对非 macOS 客户机（尤其需要关闭安全设置、以 EFI 方式启动 Linux ISO 的发行版）支持并不顺畅。

仓库里有一份社区驱动的操作指南（讨论编号 #452，位于 basecamp/omarchy 仓库讨论区）记录了完整步骤。需要特别注意的坑位包括：

• Omarchy 默认全盘加密，虚拟机内同样要输入 LUKS 密码才能启动，这与实体机体验一致；
• 需要在虚拟机设置中处理好 EFI 启动、显存与磁盘控制器类型，避免图形界面无法正常初始化。

为什么“在 VM 里跑 Omarchy”本身是被官方认真对待的用例

尽管 49 章的虚拟机段落语气轻松（“性能大概率不太好”），虚拟化运行 Omarchy 却是官方工程流程的一部分：仓库的验收测试即约定在一次性虚拟机中执行（见 agents/skills/acceptance-tests.md），ISO 测试甚至通过 QMP 虚拟键盘驱动合成器级快捷键。此外 manual/02-getting-started.md 专门介绍了无人值守安装：当 ISO 在第二块驱动器上拿到配置后可以完全自动安装，官方明确表示这适合“把 Omarchy 当作 VM 与机器集群的基础镜像”。所以，在虚拟机里安装 Omarchy 的可行性是官方测试覆盖过的——只是消费级虚拟机软件（VirtualBox/Parallels）的图形与性能体验各有取舍。

VirtualBox 与 Windows 11 上的 VMware Workstation

VirtualBox

VirtualBox 是最普及的免费虚拟机软件，官方手册确认 Omarchy 可以跑在 VirtualBox 里（社区讨论 #176），但明确提醒性能大概率不佳。这符合 VirtualBox 对 Linux Wayland 图形栈支持的现状：缺少硬件加速、3D 支持有限，而 Hyprland 这类合成器对 GPU 与 Wayland 协议的依赖较敏感。如果你只是快速体验 Omarchy 的界面与操作逻辑，VirtualBox 够用；如果要长期使用，建议优先考虑 KVM/QEMU 类方案或实体机。

VMware Workstation（Windows 11）

VMware Workstation 是 Windows 生态中另一款主流虚拟机软件，官方手册记录社区已在其中成功搭建 Omarchy（讨论 #572）。与 VirtualBox 相比，VMware 的图形栈与 3D 加速通常更好，Linux 桌面的体验会顺滑一些。这条路线意味着：宿主是 Windows 11，Omarchy 作为客户机运行在 VMware 之内。

无论选 VirtualBox 还是 VMware，建议先阅读 manual/02-getting-started.md 掌握 ISO 安装与加密要求，并了解以下配套知识：

• Omarchy 侧有官方的 Windows 互补方案：想反过来在 Omarchy 里跑 Windows，可走 Docker/KVM 虚拟机路线，详见 manual/28-windows-vm.md（需要宿主机开启 KVM，通过 RDP 全屏连接）；
• 如果目标不是“虚拟化共存”而是双系统共存，Omarchy 支持与 Windows 并排安装到同一块磁盘，安装后可用limine-scan把 Windows 引导项加入 Limine 引导器，详见 manual/50-dual-boot-install.md（注意 BitLocker 与该方法不兼容，需先在 Windows 中关闭设备加密）。

Steam Deck：Arch 本家上的“同类相吸”

Steam Deck 出厂系统（SteamOS）基于 Arch，而其桌面/启动底层与 Omarchy 同源——这使它成为最容易跑起来 Omarchy 的消费级“特殊硬件”之一。Altynbek Orumbayev 维护了一份完整的部署脚本与说明（仓库aorumbayev/deckarchy），把 Omarchy 装到 Deck 上。

这类路线本质上是“在另一份 Arch 系根文件系统上叠加 Omarchy”，因此相比在非 Arch 平台移植要直白得多。补充背景：

• Omarchy 的控制台哲学与手柄/触屏场景并不天然匹配，但接上键盘鼠标后就是一台可用的便携 Arch 桌面；
• Deck 的掌机形态让“用 Omarchy 打游戏”成为自然延伸，官方手册 manual/26-gaming.md 收录了 Steam、RetroArch 等游戏栈的配置方法可供参考。

NixOS：把 Omarchy 的“本质”声明式复刻出来

NixOS 移植路线的前提，是官方手册对 Omarchy 的一句精辟概括：Omarchy 本质上是 Arch + Hyprland。基于这一点，Henry Sipp 将 Omarchy 这套桌面组合的“精髓”移植到了 NixOS（仓库henrysipp/omarchy-nix），给 Nix 用户一个很好的起点。

原手册对该路线给出的诚实评价值得保留：移植版未必会与最新的 Omarchy 变更保持同步——毕竟 NixOS 的包、服务与配置模型和 Arch 的滚动发布差异巨大，任何上游改动（Hyprland 配置、Quickshell 面板、主题系统）都需要人工跟进移植。

有趣的是，“用 Nix 替代 Arch 底座”这件事在本仓库内部同样是被严肃研究的议题：仓库根下的 plans/nix.md 是一份相当详细的规划文档，探讨将 Omarchy 迁移到一个“主权 Nix 基础”上（自建 nixpkgs 镜像、签名二进制缓存、以“世代切换”取代 pacman 事务），以换取不可变、原子升级与可回滚的系统层。这与社区 omarchy-nix 移植形成对照——一个是社区面向既有 NixOS 用户的“逆向移植”，一个是项目内部面向未来的架构探索，两者目前都不是官方支持的安装路径，别把任何一方当成现成的 Omarchy ISO。

其它一切“非默认”平台：先评估，再动手

如果你尝试的平台不在上述任何一类里，官方手册的建议依然适用：加入社区 Discord 的#omarchy-on-other频道寻求最新方法。不过动手之前，结合本仓库可以得到一条更系统的评估清单：

1. 内核与驱动层：平台能否跑起足够新的 Linux 内核？Wi-Fi、键盘、声卡、GPU 是否有驱动？（对照 install/hardware/apple/ 中官方为 Intel Mac 编写自动修复的粒度，就能反推非官方平台你需要自己搞定多少东西。）
2. Arch 底座：平台要么能装 Arch（如 Asahi Alarm、Steam Deck），要么能声明式复刻（如 NixOS），否则需要手工搬运整个包栈。
3. 显示与输入：Hyprland 依赖现代 GPU 驱动与 Wayland 支持，弱图形栈（如部分虚拟机）会直接影响体验。
4. 官方支持边界：默认安装会抹盘并默认全盘加密（LUKS），虚拟机场景务必预留独立虚拟磁盘；manual/02-getting-started.md 中的无人值守安装是为 VM/集群准备的官方路径，比手工折腾更可靠。

小结：各路线一句话速览

官方手册 manual/49-omarchy-on.md 的定位很清晰：它是一张“引路地图”，而不是一份逐平台的安装手册——每一条具体路线都由社区文档给出操作细节。本文在此之上补充了本仓库内可交叉验证的官方支持边界与实现证据，帮助你快速判断哪条路线最匹配自己的硬件与容忍度。

【免费下载链接】omarchyBeautiful, Modern & Opinionated Linux项目地址: https://gitcode.com/GitHub_Trending/om/omarchy