Linux启动分五阶段：BIOS/UEFI硬件自检与启动设备选择→GRUB加载内核及initramfs→内核初始化并挂载根文件系统→systemd启动用户空间服务→登录界面就绪。
Linux系统启动不是一气呵成的操作，而是分阶段接力完成的。整个过程从硬件通电开始，依次经过固件层、引导层、内核层和用户空间层，每一层都为下一层准备运行条件。关键不在于“快”，而在于“稳”——每个环节必须正确识别、加载并移交控制权。
BIOS/UEFI：硬件自检与启动设备选择
按下电源键后，CPU首先执行固化在主板上的固件代码（BIOS 或更现代的 UEFI）。它立刻进行加电自检（POST），检查 CPU、内存、显卡、磁盘控制器等核心部件是否响应正常。一旦发现故障，会通过蜂鸣声或屏幕错误码提示，比如内存未插牢或硬盘无法识别。
自检通过后，固件按预设顺序（如 NVMe > SATA > USB）扫描可启动设备。在 UEFI 模式下，它会查找 EFI 系统分区（ESP）中的 /EFI/ubuntu/grubx64.efi（或其他发行版对应路径）；在传统 BIOS+MBR 模式下，则读取硬盘首扇区的 446 字节引导代码，跳转到 GRUB 第一阶段。
- UEFI 支持 GPT 分区、安全启动（Secure Boot）和更大的磁盘容量（＞2TB），已成主流
- BIOS 依赖 MBR，仅支持最多 4 个主分区，且无法引导超过 2TB 的磁盘
- 可通过开机时按 F2/F10/DEL 进入固件设置界面，调整启动顺序或禁用 Secure Boot
GRUB：加载内核与 initramfs 的桥梁
GRUB（通常是 GRUB2）接管后，会读取 /boot/grub2/grub.cfg（由 /etc/default/grub 生成）来构建启动菜单。这个配置文件明确指定了内核镜像（如 vmlinuz-6.8.0-45-generic）和对应的 initramfs 镜像（如 initrd.img-6.8.0-45-generic）的位置，以及内核命令行参数（如 root=UUID=... quiet splash）。
用户可在 GRUB 菜单界面按 e 键临时编辑启动项：比如添加 rd.break 进入 initramfs shell，或替换 ro 为 rw init=/sysroot/bin/bash 实现紧急修复。按 c 则进入 GRUB 命令行，可手动执行 ls (hd0,gpt2)/boot 查看分区内容，再用 linux 和 initrd 命令指定镜像启动。
- GRUB2 支持模块化加载（如 lvm、cryptodisk、xfs），能直接读取 LVM、LUKS 加密卷或 XFS 格式的 /boot 分区
- 若 /boot 分区损坏或 grub.cfg 丢失，可用 Live USB 运行 sudo grub2-install /dev/sda && sudo grub2-mkconfig -o /boot/grub2/grub.cfg 重建
- 密码保护需在 /etc/grub.d/40_custom 中定义用户并哈希加密，防止未授权修改启动参数
内核初始化：解压、驱动加载与根文件系统挂载
内核被 GRUB 加载进内存后开始自解压，并初始化中断、调度器、内存管理等核心子系统。此时它还不能访问硬盘上的真实根文件系统（/），因为缺少对应存储控制器（如 NVMe、RAID 卡）或文件系统（如 Btrfs、ZFS）的驱动。
于是内核将 initramfs（一个压缩的 cpio 归档）解压为内存中的临时根文件系统。initramfs 包含必需的内核模块（.ko 文件）、工具（udev、lvm、cryptsetup）和一个初始化脚本（通常为 /init）。该脚本负责探测硬件、加载驱动、解锁加密卷、激活 LVM 卷组，最终调用 switch_root 切换到真实的根文件系统。
- 常见失败点：initramfs 未包含某块 NVMe 驱动，导致 “VFS: Unable to mount root fs” 错误
- 可通过 lsinitrd /boot/initrd.img-$(uname -r) | grep nvme 检查驱动是否存在
- 更新内核后务必运行 sudo update-initramfs -u（Debian/Ubuntu）或 sudo dracut -f（RHEL/Fedora）重建 initramfs
systemd：用户空间的第一个进程与服务编排中心
内核成功挂载真实根文件系统后，执行第一个用户空间进程：/sbin/init，在现代 Linux 中这实际是 systemd（PID=1）。它读取 /etc/systemd/system/default.target（通常是 graphical.target 或 multi-user.target），然后并行启动所有依赖该 target 的单元（.service、.socket、.mount 等）。
systemd 不再依赖传统的 /etc/inittab 或串行执行的 rc scripts，而是通过声明式单元文件定义服务依赖、启动顺序和失败策略。例如，sshd.service 声明 After=network.target 且 Wants=network.target，确保网络就绪后再启动 SSH。
- 查看启动过程：启动时按住 Shift（GRUB）或运行 systemd-analyze time、systemd-analyze blame
- 排查服务失败：用 systemctl status sshd 查看日志，配合 journalctl -u sshd -b 定位错误
- 临时切换目标：启动时在 GRUB 编辑界面末尾添加 systemd.unit=rescue.target 进入救援模式
