Arch Linux 初体验！

本文最后更新于 2026年8月31日 晚上

前言

安装 Arch Linux 并配置之，第一次尝试，收获了很多有趣的经验！

安装

下文的写作方式是：把我在安装系统时，手机和 GPT 的聊天记录（里面有很多图片）的会话在 Codex 里面转为 Work 对话，让其读取内容并总结之后写文章，写完之后我再进行修缮。

一块二手 SSD

简单来说，想电脑上装双系统了。简单查了一下电脑本机的配置之后，去闲鱼上淘了一块二手的 AirDisk 512GB SSD，正好电脑里还有一个空闲的 M.2 插槽。

电脑原本的 Kingston 1TB 里是我日常使用的 Windows 11；这块 AirDisk 前任主人留下了一套完整的 Windows，EFI、系统、数据和恢复分区一应俱全。反正里面没有需要保留的数据，所以可以全部扬了。

简单来说我的需求是尽可能的隔离两个系统。更具体地说，我想要的是：

  • Kingston 保留自己的 EFI 和 Windows Boot Manager，仍然作为默认启动盘；
  • AirDisk 新建自己的 EFI，只放 Arch 和它的引导；
  • 平时什么都不按就进 Windows，想进 Arch 时才手动选 AirDisk；
  • 拔掉任意一块盘，另一块最好仍然可以自己启动。

本来我开始以为可以实现「两块盘互相看不见」，后来发现这在两块 NVMe 都插着时其实做不到。Linux 的 lsblk 仍然会看见 Kingston，Windows 的磁盘管理也会看见 Linux 磁盘。真正能做到的隔离，是不共享 EFI、不自动挂载对方的分区，不让一边的启动依赖另一块盘。

[!note] EFI System Partition 一般简称 ESP，通常是一小块 FAT32 分区，里面放的是供主板 UEFI 执行的 .efi 启动程序。操作系统本体并不在这里。两块 SSD 各有一块 ESP，也就可以各自保留一套启动链。

进入 Live 环境

我已经用 Rufus 的 DD 模式做好了 Arch 安装 U 盘。关机、插盘，疯狂按 F7 进入这个界面：

拍得有点太糊了，不过后面这样的图还很多。

选择第一个：Arch Linux Install Medium (x86_64, UEFI) 从 U 盘启动之后，看到 root@archiso，才算正式进入 Arch 的 Live 环境。

进入 Arch Live 环境后的 root@archiso

[!note] Live 环境可以理解成「从 U 盘临时运行的一套 Arch」。此时真正安装好的系统还不在运行；分区、格式化、挂载，乃至后面修复 GRUB，都是借这套临时系统完成的。只要不再执行格式化，安装 U 盘也完全可以当救援盘使用。

先确认自己到底要操作哪块盘。当时我先看的是：

lsblk -d -o NAME,SIZE,MODEL,SERIAL

第一次进入 Live 环境时，结果大致是：

nvme0n1  476.9G  AirDisk 512GB SSD
nvme1n1  953.9G  KINGSTON OM8PGP41024N-A0

于是这一轮里，准备被清空的是 /dev/nvme0n1。进 cfdisk 后把 AirDisk 原来的五个分区全部删掉，只重新建了两块：1 GiB 的 EFI System Partition，以及占满剩余空间的 Linux filesystem。

AirDisk 在 cfdisk 中原有的五个 Windows 分区
重新分区后用 lsblk 核对两块 SSD

[!tip] 绝对不要凭「Windows 里它是磁盘 0」或者「上次它叫 nvme0n1」来认盘。真正可靠的是型号、容量和序列号。尤其在 cfdisk、mkfs 这类命令前，多看一遍不嫌烦。

推倒换成 Btrfs

分区完成后，我一开始很自然地把大分区格式化成了 ext4，并把根分区和 AirDisk 自己的 EFI 分别挂到了 /mnt 与 /mnt/boot。这套方案其实没有任何问题。

第一次完成 ext4 格式化与挂载

然后我回头一看，准备跟的教程全程使用 Btrfs，还创建了子卷。既然才刚开始，我也懒得在后面不断把教程里的路径翻译成 ext4 的写法，于是干脆卸载分区，把刚格式化好的 ext4 通过 cfdisk 再删一次，重新来。

最终 AirDisk 的主体仍然只有一个 Btrfs 分区，但里面分出了两个子卷：

@      → /
@home  → /home

EFI 则单独挂在 /efi。这里的子卷看起来像分区，实际上仍然属于同一个 Btrfs 文件系统；好处是以后做快照、回滚或者分别管理根目录与家目录时会更灵活。

救援时重新确认 Btrfs 的 @ 与 @home 子卷

[!note] 「挂载」不是把文件复制到某个文件夹，而是把一个文件系统接到 Linux 的目录树上。比如把 @ 挂到 /mnt，意思是从 /mnt 往下看到的内容来自这个子卷；把 ESP 挂到 /mnt/efi，后续写入 /efi 的引导文件才会真正落到 AirDisk 的 EFI 分区里。

内核根据选的是 linux-zen，但是也安装了一个 LTS 版本，在 grub 的时候可以选择从哪一个启动。

之后的部分没有太多值得复述的，ArchWiki 之述备矣：跟着教程完成基础包、网络、用户、桌面和 GRUB 的配置，真正折腾最久的部分出现在第一次重启以后。

重启以后，BIOS 里只有 Windows

教程走完，输入 reboot。我原本以为接下来会看到 GRUB，于是开机时疯狂按 F7，结果什么也没有发生，机器直接进了 Windows。

无奈之下再按 F2 进入 BIOS，Boot Option 里面依然只有 Kingston 上的 Windows Boot Manager。

BIOS 的 Boot Option 页面
硬盘启动项里只有 Kingston 的 Windows Boot Manager

当时第一反应当然是：是不是 GRUB 根本没装上？

好在这里不需要重装。把安装 U 盘插回去，再次进入 Arch Live，它就从安装介质变成了救援环境。接下来要做的只是把已经安装在 AirDisk 上的系统重新挂载到 /mnt，再进去检查引导。

重新进入 Live 后先确认 UEFI 与文件系统

NVMe 编号问题

结果真正危险的事情反而先发生了：第一次安装时 AirDisk 明明是 /dev/nvme0n1，这次重新启动以后，两块 NVMe 的编号居然对调了：

/dev/nvme0n1  → Kingston 953.9G
/dev/nvme1n1  → AirDisk 476.9G
救援阶段再次核对型号、序列号与分区

还好在继续操作前又核对了一次型号，否则照着旧记录去挂载乃至格式化 /dev/nvme0n1 就完蛋了。

这次 AirDisk 的实际布局是：

/dev/nvme1n1p1  FAT32  → /mnt/efi
/dev/nvme1n1p2  Btrfs
  ├─ @                 → /mnt
  └─ @home             → /mnt/home

所以重新挂载的核心过程大致是：

mount -o subvol=@ /dev/nvme1n1p2 /mnt
mkdir -p /mnt/home /mnt/efi
mount -o subvol=@home /dev/nvme1n1p2 /mnt/home
mount /dev/nvme1n1p1 /mnt/efi
原系统 fstab 中的根目录、home 与 EFI 挂载关系

确认 /mnt、/mnt/home 和 /mnt/efi 都指向 AirDisk 后，再用 arch-chroot /mnt 进入硬盘里那套已经安装好的 Arch。

有点像从 Live 环境「穿梭」进原系统：当前的显示不变，但根目录、软件和配置已经换成 AirDisk 上的那一套。

原来 eris 一直都在

重新挂载后检查 /efi/EFI，里面其实已经有：

/efi/EFI/eris/grubx64.efi

而 efibootmgr -v 也能看到名为 eris 的 UEFI 启动项，指向的正是 AirDisk 的 EFI 分区。eris 是我安装 GRUB 时给 bootloader 取的名字，其实是教程这么取我就跟着做了。

eris 的 grubx64.efi、efibootmgr 记录与 linux-zen 内核文件

也就是说，Arch 没有装坏，GRUB 的 .efi 文件也存在，连主板 NVRAM 里的启动记录都注册成功了。问题只是这块主板的 BIOS 设置页面没有把它正常展示出来。

再补一条 UEFI fallback

后来回忆起来教程里有提到，有些主板对 EFI/eris/grubx64.efi 这种自定义路径兼容得不太好，却会主动寻找 UEFI 约定的标准 fallback 路径：

EFI/BOOT/BOOTX64.EFI

于是我没有重装系统，只是在 chroot 里给现有 GRUB 额外补了一次 --removable 安装：

grub-install \
  --target=x86_64-efi \
  --efi-directory=/efi \
  --boot-directory=/boot \
  --removable \
  --no-nvram \
  --recheck

完成后，AirDisk 的 ESP 里同时有了两条入口：

EFI/eris/grubx64.efi
EFI/BOOT/BOOTX64.EFI

[!note] --removable 这个名字有点容易让人误会，它不要求硬盘真的是移动设备。这里最重要的效果，是把引导程序写到标准的 EFI/BOOT/BOOTX64.EFI。即使主板丢了名为 eris 的 NVRAM 记录，只要它愿意扫描 fallback 路径，AirDisk 仍然有机会自己启动。

按错键了

补完 fallback、检查文件、重新生成 grub.cfg，然后关机拔掉 U 盘。之前一直在疯狂按 F7，却怎么都叫不出一次性启动菜单。查了一圈之后才发现，机械革命翼龙 15 Pro 的 Boot Menu 实际上是 F10。

于是重新开机，疯狂按 F10，一次成功。

F10 一次性启动菜单里的 Windows、eris 与 UEFI OS

菜单里终于同时出现了：

Windows Boot Manager (KINGSTON...)
eris (AirDisk 512GB SSD)
UEFI OS (AirDisk 512GB SSD)
Enter Setup

其中 eris 和 UEFI OS 最终都会进入 AirDisk 上的 GRUB，但入口并不一样：

  • eris 来自主板 NVRAM 里那条自定义启动记录，指向 EFI/eris/grubx64.efi；
  • UEFI OS 是主板扫描到标准 fallback 文件后给出的名字，指向 EFI/BOOT/BOOTX64.EFI；
  • Enter Setup 就是回到 BIOS 设置界面。

所以现在的使用方式终于和最初设想的一样了：平时什么都不按，默认从 Kingston 进入 Windows；想用 Arch 时，开机按 F10，再选 eris。UEFI OS 则像是一条备用入口。

GRUB 里面的 Windows

顺利进入 GRUB 后，除了 Arch Linux，还多了一项 Windows Boot Manager (on /dev/nvme0n1p1)。

os-prober 让 GRUB 菜单里出现了 Windows Boot Manager

这是因为安装时启用了 os-prober。它会扫描其他磁盘上的操作系统，然后在执行 grub-mkconfig 时把结果写进 /boot/grub/grub.cfg。因此从 AirDisk 的 GRUB 也可以 chainload 到 Kingston 上的 Windows Boot Manager。

这不代表它修改了 Windows 的 EFI，只是让 GRUB 知道「旁边还有一个 Windows」，并在自己的菜单里加了入口。

就启动独立性而言，Windows 仍然可以绕过 AirDisk 直接启动，Arch 也有自己的 ESP；os-prober 只是菜单层面的交叉引用，并没有破坏这套结构。

至此，这次安装里真正麻烦的部分才算结束。回头看，Arch 本身倒没有传说中那么玄学，最惊险的反而是多 SSD 场景下那些很容易被教程一笔带过的细节：设备名会变、挂载点决定文件实际写到哪块盘、EFI 文件存在不等于 BIOS 愿意展示、而主板启动菜单的按键甚至都可能先查错。

fastfetch

安装部分的捷径

其实手动安装只是想折磨折腾一下自己。如果想要简单安装 Arch Linux，有这么两种方式：

  1. 进入 live 环境之后输入 archinstall 命令，可以通过保姆级别的 TUI 引导完成整个安装工作

  2. 进入 live 环境之后先联网，连上网之后直接安装一个 opencode（通过 shell 脚本方式），让其安装即可。

    我开始还以为什么也没装的 Arch Linux 纯毛坯啥也装不了，没想到其实是可以运行 Coding Agent 的...

    唯一需要注意的就是磁盘的问题，务必不要格式化错了硬盘，这一块务必确认再确认，别的操作我觉得没什么问题，装错了就重来一遍 live 环境。