把 Linxira 装到已有的 Arch 上：从 ISO 到就地接管

2026-09-27 · 路线图讨论稿。这是一篇设计说明，不是发布公告：文中除「已经成立的既成事实」外均为规划，尚未实现，也未排期。

TL;DR

能，但不是所有层都一样容易。[linxira] 是标准 pacman 源，Linxira 包层是普通包——这两层装到任何 Arch 系系统上几乎没有额外成本。真正会咬人的只有一层：引导器与快照策略（GRUB / grub-btrfsd / Timeshift），因为它是唯一有可能让机器开不了机的操作。

所以我们打算做的不是「另一个安装器」，而是把装机路径已经实现的那套事务模型，接到一个命令行入口上，并且明确划出支持边界——能探测就探测，不能满足就拒绝，而不是硬转。

前提是真的：纯 Arch 基线已经存在

这不是宣传语，是仓里已经落地的产品概念。我们给「服务器 · 纯 Arch 最小安装」准备的基线是 13 个包：

base  btrfs-progs  curl  efibootmgr  grub
linux  linux-firmware  linux-headers  linux-lts  linux-lts-headers
networkmanager  openssh  sudo

它的设计意图写在文件的注释里：不包含 Linxira 工具链、桌面管线、[linxira] 源与 keyring，留给用户自己装想要的桌面或组件。

换句话说，「纯正的原版 Arch 打底 → 再往上叠 Linxira」这件事，在 ISO 里已经走通过一次了。缺的只是入口：今天只能在装机时选，无法在一台已经跑起来的机器上做。

Linxira 减掉 Arch，剩下四层

判断一个 Arch 衍生系统能否被接管，只要看这四层各自要付出多少：

层	本质	换到别的 Arch 上的代价
`[linxira]` 签名源	标准 pacman 源	零——任何 pacman 系直接加
Linxira 包层	普通 Arch 包	低，依赖关系已声明
桌面与会话接线	配置 + 包	中，冲突最集中
引导与快照策略	引导器 + btrfs 假设	高，唯一可能开不了机的层

前三层本质上是「装软件」。第四层不是——它动的是这台机器怎么启动。

原版 Arch：最简单的一档，但别低估引导器

装包本身几乎白送。真正需要设计的是三件事。

引导器。 我们的快照叙事绑在 GRUB + grub-bfrfsd 上：内核升级后仍然有可引导的快照，Timeshift 快照能被写进引导菜单（这里还有一个必须保留的细节——GRUB 的字符串排序会把 linux-lts 排到 linux 前面，默认内核是靠显式的 GRUB_TOP_LEVEL 指定的，不是靠菜单排序）。如果目标系统用的是 systemd-boot，接管就意味着装 GRUB 并改默认引导项。这是整个流程里唯一有可能让机器开不了机的操作，因此它必须是独立的一次确认，不能混在批量装包里悄悄发生。

文件系统。 btrfs 子卷 + grub-btrfsd 才有「可引导快照」。ext4 或者别的 btrfs 布局上，Timeshift 与可引导快照这套是打折的。我们倾向于在一期就明确只支持 btrfs + GRUB，其余直接拒绝——一个降级的快照能力配上「我们支持它」的措辞，比明确拒绝更危险。

桌面冲突。 这块我们已经踩过并修过：COSMIC 的会话文件名是 cosmic.desktop 而不是字面意义的 cosmic、基线剔除 xdg-desktop-portal-kde 以避免闭包、COSMIC 需要自带 vulkan-swrast 才能在无 GPU 的虚拟机里有 Vulkan。由此得出的一条硬规则是：先装新的、验证通过，再删旧的。顺序反了，用户会被锁在门外。

其他 Arch 衍生：需要探测，不该假设

「Arch 衍生」不是一类系统，是好几类。诚实的做法是先探测再决定，而不是宣称「支持所有 Arch」：

跟随上游 pacman 语义的（例如同步上游的分支）：基本可行，但仍然要探测 hold 包、仓库优先级、以及是否已有自己的桌面环境。
自建工具链的（有自己的包管理封装或构建目录）：不是「能不能」的问题，而是维护成本陡增。
自称 Arch 但底层不是 pacman 的：那是另一个产品，不该混进来。

因此探测环节只做只读检查，并报告与拒绝：引导器现状、文件系统类型与子卷布局、当前桌面/会话、hold 包、磁盘余量。满足条件就继续，不满足就带着原因拒绝，绝不半途硬转。

我们打算怎么做：不写第二个安装器

关键决定是复用已经存在的事务后端。系统里所有会修改机器的动作都走同一条路径——先算出计划、让用户看清、用户确认、再由 root 执行、执行完留下可核对的凭据，并且计划与执行之间做漂移检查。装机路径和「接管」路径共用这一套，于是 dry-run、凭据、失败回滚全部是同一份实现，而不是两套行为相似但细节漂移的代码。

对应到命令行，大致是：

linxira-adopt --dry-run      # 产出计划：加源 / 装包 / 桌面增删 / 引导器（独立可选）/ 策略变更
linxira-adopt --apply <plan> # 经事务后端执行

只读探测在前，计划在后，执行最后。引导器那一步永远是计划里一个独立条目，需要单独确认。

三条不能让步的不变量

引导器改动必须单独确认，并自带恢复路径（先创建 Timeshift 快照，或依赖 grub-btrfsd 快照）。
不先删旧桌面。 新桌面装好并通过校验，再谈移除。
全程幂等可续。 中断后重跑必须从检测步骤继续，而不是从头再来一遍。这条在别处已经实现过一次，可以照抄。

一处现成的障碍

装机后的校验器目前对已安装包钉死精确版本（例如要求 linxira-components 为某个具体的 版本-构建号）。在装机路径上这是优点：它保证交付出去的系统就是测过的那个版本。但在一台别人的机器上，装的是任意版本。接管模式必须把校验放宽为「不低于」，或者先驱动一次升级到受支持的版本再接管。

这是一个需要明确拍板的产品决策，而不是实现细节。

需要拍板的两件事

非 btrfs 系统是否支持接管？ 快照是我们产品的主要卖点之一，在 ext4 上它会明显降级。我们倾向：一期只支持 btrfs + GRUB，其余明确拒绝。
接管是否包含「换桌面」？ 只往无桌面的服务器系统上加 Linxira 栈，风险低得多；包含桌面替换，价值与风险都上一个量级。

在这两点确定之前，我们不会开始写实现。这篇文章的意图是先把边界谈清楚——一个会拒绝的接管工具，比一个到处都能用但会把人锁在门外的接管工具，要有用得多。