安装本质探索
图形安装器显示的是一条进度条，命令行安装展示的是一串命令，但两者都在完成同一组职责：准备目标存储，把一个可运行的用户空间放进去，生成机器相关配置，再让固件能够启动它。
它们并不一定执行完全相同的脚本，也不一定使用“解压镜像”这一种部署方式。理解阶段之间交付了什么，比背下某个发行版的安装命令更重要。
- 适合谁：已经理解分区、文件系统与挂载，准备使用图形安装器或阅读手动安装指南的读者。
- 学完能做什么：按顺序解释安装职责，区分 mount 与 chroot、镜像部署与包部署，并判断故障停在哪一层。
- 环境：流程模型适用于主流 Linux 安装；示例按截至 2026-07 的 Debian 13、Arch 安装指南、Calamares 文档与 Linux 手册核验。安装器界面、快捷键和默认引导器会随发行版版本变化。
- 前置条件：阅读和只读探测无需改盘；真正安装必须先备份现有系统，并使用虚拟机、一次性虚拟磁盘或已确认的目标盘。
- 时间与成功证据：阅读约 25 分钟，练习约 15 分钟；你应提交一张安装阶段图、一份当前启动环境记录和一个已清理的微型 rootfs 解包实验。
1. 安装是一条有交付物的流水线
安装器更像项目经理：它探测硬件，调用分区、文件系统、包管理、镜像复制、用户管理、initramfs 与引导工具，并在步骤之间传递状态。图形界面不只是“Shell 脚本套皮”；成熟安装器还承担存储建模、依赖排序、错误处理、本地化与发行版策略。
可以把典型流程拆成八个职责。具体安装器可能合并或调整步骤，但依赖关系不会随意颠倒。尤其要注意：只有先挂载目标并部署 rootfs，目标树里才有可用于 chroot 的程序与库；把 mount /dev/... /mnt 称作“Chrooting”会混淆两个完全不同的系统调用。
2. 先只读观察你当前所在的环境
以下命令不会修改磁盘：
cat /etc/os-release
cat /proc/cmdline
findmnt -no SOURCE,FSTYPE,OPTIONS /
lsblk -o NAME,PATH,TYPE,SIZE,FSTYPE,FSVER,MOUNTPOINTS
test -d /sys/firmware/efi && echo "current boot: UEFI" || echo "current boot: legacy/other"
findmnt /sys/firmware/efi/efivars/sys/firmware/efi 存在只能证明这一次内核是经 UEFI 路径启动的，不能证明机器不支持另一种模式。安装介质以哪种模式启动，通常决定安装器准备哪种引导路径。
在 Live 环境中，根目录 / 属于安装介质或内存文件系统；目标系统可能挂在 /target、/mnt 或安装器私有路径。用 findmnt 确认，不要从教程猜目录。
3. mount 与 chroot 各做什么
3.1 mount：把目标文件系统接到目录树
假设安装器把未来根文件系统挂载到 /target。此时 /target/etc 是目标系统未来的 /etc，但当前 Shell 的 /etc 仍属于安装环境。
挂载顺序通常是“父挂载点先、子挂载点后”：先挂载目标 /，再创建并挂载 /home、/boot、/boot/efi。如果先在临时目录写入文件，再把另一个文件系统挂到同一目录，原内容不会被删除，却会在挂载期间被遮蔽。
3.2 chroot：改变绝对路径解析的根
chroot <target-root> <command> 让该进程及子进程把 <target-root> 当作 /。它改变的是路径解析的一部分，不会自动：
- 挂载磁盘或创建文件系统；
- 提供
/proc、/sys、/dev、DNS 和网络； - 切换内核；
- 建立容器级命名空间或安全沙箱。
因此“瞬移进新系统”只是便于理解路径的比喻。chroot 仍使用当前运行内核，也不是把不可信程序隔离起来的安全边界。
绑定 /dev、挂载伪文件系统和安装引导器会改变真实状态。恢复场景必须先确认目标根、挂载层级、固件模式和发行版文档；本文只解释职责，不提供一套假装通用的 chroot 安装配方。
4. rootfs 不总是通过 Unsquash 部署
rootfs（root filesystem）是目标系统的根目录内容，不等于某一种压缩格式。无论使用哪条路线，阶段 4 的验收都不是“进度条到 30%”，而是目标树已经出现可用的 /etc、/usr、包数据库及发行版标识，并与所选架构匹配。
镜像部署型
安装器复制或解开预构建的 SquashFS、tar 或文件系统镜像，再清理 Live 专用组件并写入机器配置。许多使用 Calamares 的 Live 发行版采用类似路线，实际模块由发行版配置决定。
优点是部署快且结果接近测试过的镜像；代价是镜像定制和安装后清理更重要。
包管理部署型
安装器从仓库或介质解析包并构建目标系统。例如 Debian Installer 使用 debootstrap 安装基础系统；Arch 官方流程使用 pacstrap 安装基础包。
优点是包选择灵活；代价是更依赖仓库、网络和包状态。
混合型
先展开基础镜像，再通过包管理器补装内核、驱动、语言包或桌面组件。图形与命令行只表示交互方式，不决定底层一定是哪条路线。
5. 引导写入要分 UEFI 与 BIOS 路径
安装器最终要建立“固件 → 可启动对象 → 内核/initramfs → 根文件系统”的链条，但不同固件路径交付物不同。
| 当前启动模式 | 常见必需条件 | 安装器通常生成什么 |
|---|---|---|
| UEFI | 正确类型且可被固件读取的 EFI System Partition（通常为 FAT）；安装时正确挂载 | ESP 中的 EFI 可执行文件，以及可能写入 NVRAM 的启动项；部分场景还使用规范回退路径 |
| Legacy BIOS | 固件从传统磁盘启动路径加载引导代码；GPT 布局可能需要专用 BIOS Boot Partition，取决于引导器 | MBR/磁盘嵌入区或分区中的引导器组件与配置 |
“把 GRUB 写入 EFI 分区或 MBR”仍然过窄：系统也可能使用 systemd-boot、直接 UEFI 启动内核或其他架构专用引导方式。引导器选择、Secure Boot 和 ESP 挂载路径应以发行版当前指南为准。
/boot、ESP 与根文件系统也不是同一件事：ESP 供 UEFI 固件读取，/boot 保存内核、initramfs 或引导器数据，根文件系统承载完整用户空间。它们可以位于不同文件系统。
6. 安装过程中怎样观察而不干扰
不同安装器是否提供第二个 TTY、日志查看器以及快捷键并不统一。不要假定 Ctrl+Alt+F2 在所有 Live 环境都可用。更安全的观察方式是：
- 先查该发行版安装指南中的“日志/调试”入口。
- 若安装器提供“查看日志”按钮，只读查看并保存失败时间点。
- 若官方说明可切换 TTY，再使用所列快捷键；不要在后台终端运行分区或挂载命令干扰安装器。
- 在失败后、重试或重启前保存安装器日志、
lsblk、findmnt和dmesg中相关片段。
观察时可以问四个问题：目标设备是谁？目标树挂在哪里？当前在部署包/镜像还是配置目标？引导阶段是否与当前固件模式一致？
7. 一个不会碰磁盘的 rootfs 微型实验
下面只在 /tmp 创建普通目录和 tar 文件，演示“打包内容 → 挂载目标的类比目录 → 解包”与 chroot 的区别。它不是可启动 Linux，也不需要 root 权限。
探测与停止条件：需要 tar、mktemp；若变量没有以 /tmp/ 开头就不要继续清理。
command -v tar
lab="$(mktemp -d /tmp/rootfs-lab.XXXXXX)"
mkdir -p "$lab/source/etc" "$lab/source/usr/share" "$lab/target"
printf 'NAME=MiniRoot\n' > "$lab/source/etc/os-release"
printf 'installation payload\n' > "$lab/source/usr/share/payload.txt"
tar -C "$lab/source" -czf "$lab/rootfs.tar.gz" .
tar -C "$lab/target" -xzf "$lab/rootfs.tar.gz"
find "$lab/target" -type f -printf '%P\n' | sort预期能看到 etc/os-release 和 usr/share/payload.txt。此时数据已经部署到 target，但当前 Shell 的 /etc/os-release 没有改变，也没有执行 chroot。
验证两个树互不混淆：
cat "$lab/target/etc/os-release"
cat /etc/os-release清理前确认路径，再删除一次性目录：
case "$lab" in
/tmp/rootfs-lab.*) rm -r -- "$lab" ;;
*) printf 'refusing to remove unexpected path: %s\n' "$lab" >&2 ;;
esac
test ! -e "$lab" && echo "lab cleaned"最终应输出 lab cleaned。如果解包失败，保留 $lab/rootfs.tar.gz，先用 tar -tzf "$lab/rootfs.tar.gz" 只读检查归档；不要使用 sudo 掩盖路径或权限错误。
8. 常见失败：症状对应哪一层
| 现象 | 常见原因 | 安全诊断 | 下一步决策 |
|---|---|---|---|
| 安装器看不到磁盘 | 控制器驱动/固件缺失，Intel RST/VMD/RAID 模式，或设备故障 | lsblk；lspci -nnk；dmesg 中存储控制器信息 | 查机器与发行版官方兼容说明；不要直接初始化未知设备 |
| 切换 RST/RAID 到 AHCI 后另一系统无法启动 | 原系统驱动与启动配置仍按旧控制器模式准备 | 改动前记录固件设置、检查 Windows BitLocker/恢复密钥与厂商迁移流程 | 双启动机器先完成另一系统的官方迁移准备；不确定就恢复原设置 |
| 分区成功但部署时报空间不足 | 挂载错目标、rootfs 估算不足或镜像/包缓存占用 | lsblk -f；findmnt -R <target-root>；df -hT <target-root> | 保留日志，确认真实目标树后重新规划；不要盲目删除现有分区 |
| 解包/安装包失败 | 安装介质损坏、内存/设备 I/O 错误、网络或仓库失败 | 校验官方镜像摘要；查看安装器日志与 dmesg | 区分介质、硬件与网络后再重试；有 I/O error 时停止写盘 |
| chroot 内命令不存在或报架构错误 | rootfs 未部署完整、PATH 错或目标架构不匹配 | file <target-root>/bin/sh；检查目标 /etc/os-release 和包数据库 | 不安装引导器；先修复或重新部署基础系统 |
chroot 内 /proc、DNS 或设备不可用 | 运行时伪文件系统/解析配置未准备 | findmnt -R <target-root>；检查目标 /etc/resolv.conf | 按发行版安装/救援指南准备运行时接口，不复制猜测命令 |
| UEFI 引导安装失败 | 安装介质实际以 Legacy 模式启动、ESP 未挂载/类型错误、NVRAM 不可写 | test -d /sys/firmware/efi；findmnt <esp-mountpoint>；lsblk -f | 先统一启动模式与布局，再按引导器文档修复；不要格式化已有共享 ESP |
| 首次启动找不到根设备 | fstab、内核参数、LUKS/LVM 或 initramfs 不一致 | 从 Live 环境读取 fstab、引导参数、lsblk -f 与启动日志 | 保留证据并进入发行版救援流程；不要重装覆盖数据 |
| 首次启动黑屏但系统可能已启动 | 显示驱动、显示管理器或内核图形参数问题 | 尝试发行版支持的文本/救援入口并查看 journal | 把“引导成功”和“图形会话失败”分开；nomodeset 只作为临时诊断且有功能代价 |
如果目标盘出现 I/O error、分区表与预期不符，或你无法确认哪块盘存放唯一数据，立即停止写入。先保存只读证据和镜像，再寻求数据恢复帮助。
9. 可观察练习
10. 小结与下一站
现在你应能按依赖关系解释：先准备并挂载目标，接着通过镜像或包部署 rootfs，再生成配置；chroot 只改变进程的路径根；内核/initramfs 和引导配置最终把固件连接到真实根设备。遇到失败时，你可以先定位阶段并保存证据，而不是把所有问题都归因于“GRUB 坏了”。
下一篇阅读 进程通信基础（IPC）：系统启动后，大量安装器、桌面程序和后台服务都需要跨进程协作，它会解释这些通信机制的角色分工。
核验资料（截至 2026-07）
- Debian 13 官方安装指南：安装过程概览
- Arch Linux 官方 Installation guide
- Calamares 官方文档：Install
- Linux man-pages：chroot(2)
- util-linux mount(8)