linux系统启动挂载顺序由fstab的fs_passno（仅控fsck检查）、systemd的.mount单元依赖及内核/initramfs硬性约束共同决定，非随意执行。
Linux 系统启动时，挂载点的加载不是随意进行的，而是严格遵循依赖关系与配置优先级。核心控制机制是 /etc/fstab 中的 fs_passno 字段（第六列），它直接决定 fsck 检查顺序，间接影响挂载时机；而真正决定挂载先后顺序的，是 systemd 的单元依赖体系和内核初始化流程。
挂载顺序由三类因素共同决定
-
/etc/fstab 中的 fs_passno 值
该字段仅用于fsck检查阶段：-
0：不检查（如 swap、proc、tmpfs） -
1：仅根文件系统（/）允许设为 1，且必须唯一 -
2+：其他需检查的文件系统，数字越小越早检查（但检查完成 ≠ 立即挂载）
注意：
fs_passno不控制 mount 行为本身，只是 fsck 阶段的执行次序。很多资料误认为它控制“挂载顺序”，实际挂载动作由 systemd 管理。 -
-
systemd 的自动挂载单元（.mount 单元）
系统启动时，systemd-fstab-generator会将/etc/fstab每行转换为一个.mount单元（如/mnt/data.mount）。这些单元默认依赖local-fs.target，而local-fs.target又依赖system.slice和sysinit.target。
关键点在于：- 若某挂载点依赖另一个挂载点（例如
/mnt/data下有子目录/mnt/data/logs需挂载到/var/log），可通过RequiresMountsFor=或After=显式声明依赖 - 使用
x-systemd.requires=或x-systemd.after=挂载选项可在 fstab 中注入 systemd 依赖指令
- 若某挂载点依赖另一个挂载点（例如
-
内核与 initramfs 阶段的硬性约束
- 根文件系统（
/）必须在 initramfs 解压后由内核直接挂载，否则系统无法继续启动 -
/usr若单独分区，需在 initramfs 中预加载其驱动和文件系统模块（如xfs.ko），否则 systemd 启动失败 -
/boot通常需早于根文件系统挂载（尤其使用 LUKS 加密或 UEFI 引导时），因此常被设为fs_passno=1并由 initramfs 处理
- 根文件系统（
典型挂载时序示例（以标准 ext4 分区为例）
- 第一阶段（initramfs 内）：挂载
/（根）、/boot（若独立）、解密 LUKS 卷 - 第二阶段（systemd 启动）：
-
sysinit.target→ 触发local-fs.target -
local-fs.target并行启动所有.mount单元（无显式依赖时） - 但
/proc、/sys、/dev等伪文件系统由内核或 udev 自动挂载，不走 fstab -
/home、/var、/mnt/data等按.mount单元就绪状态陆续挂载，实际顺序受设备识别延迟、udev 事件触发时间影响
-
避免挂载顺序问题的实用建议
- 对关键业务路径（如
/opt/app/storage），不要依赖“先挂后用”，应在应用服务单元中添加：[Unit] RequiresMountsFor=/opt/app/storage After=opt-app-storage.mount
- 新增挂载项时，优先使用 UUID 而非
/dev/sdX，防止设备名变动导致挂载失败或错挂 - 测试 fstab 修改后，务必运行
sudo systemctl daemon-reload && sudo mount -a，再检查systemctl list-units --type=mount确认单元状态 - 若某挂载长期失败（如 NFS 服务器未就绪），可加
x-systemd.automount选项启用按需挂载，避免阻塞启动
挂载顺序管理本质是协调内核能力、fstab 配置与 systemd 生命周期，重点不在“谁先谁后”的绝对排序，而在明确依赖与容错边界。
