网上聊stm32的启动过程、聊项目管理里那个启动过程组能搜出一大堆但真正问 rhel9 的启动过程很多运维兄弟能说出“GRUB 加载、内核起来、systemd 接管”三步再往下就含糊了。我最早也是在服务器起不来的时候才下决心把这条链路彻底捋顺——从按下电源键到登录界面出现固件、引导器、内核、initramfs、systemd 五个环节各干各的活任何一个环节断了机器都进不了系统。这篇文章我就按启动的时间线把这五段拆开讲透顺便把每一段对应的排错手段也放在一起。看完你至少能对着故障现象判断出问题出在哪一步而不是一上来就瞎敲命令。1. 固件阶段服务器按电源键之后到底先跑什么1.1 UEFI 与传统 BIOSRHEL 9 里两种引导方式的差异RHEL 9 支持两种固件引导方式UEFI 和传统 BIOSLegacy mode。现在新买的物理机基本都是 UEFI但虚拟化平台、老掉牙的物理机上还是能见到 Legacy。这个阶段很多人不重视觉得“反正按了开关就开机了”其实固件决定了一件事它去哪块盘、哪个分区、找哪个文件来启动系统。UEFI 模式下固件读取主板 NVRAM 里的启动变量按照 BootOrder 的顺序找到启动项然后去 ESP 分区也就是挂载在/boot/efi的那个 FAT32 分区加载引导程序。RHEL 9 装完后你在 ESP 里能看到EFI/redhat/shimx64.efi和EFI/redhat/grubx64.efi。传统 BIOS 模式下则是另一条路固件直接读磁盘 MBR 或 VBR 里的引导代码再把 GRUB 的 core.img 加载起来。RHEL 9 在 Legacy 模式安装 GRUB 时会在磁盘上留一个 1MB 的 BIOS boot 分区没有文件系统专门给 GRUB 用。很多人装机时看到这个分区以为装坏了实际上这是正常的。判断手里这台机器当前是哪种引导模式非常简单# 有这个目录说明跑在 UEFI 模式 ls /sys/firmware/efi # 或者看 efibootmgr 有没有输出 efibootmgr -v如果efibootmgr报“EFI variables are not supported”大概率就是 Legacy 引导。这个判断在做启动修复时特别重要因为 UEFI 和 Legacy 的修复命令完全不同后面第 5 章我会细说。1.2 Secure Boot 链路shim、MOK 和那个签名信任链RHEL 9 在 UEFI Secure Boot 环境下默认不走“固件直接加载 grubx64.efi”这条路而是先加载shimx64.efi。原因是 Secure Boot 要求固件只加载被它信任签名的程序Red Hat 的密钥当然不被主板信任但 shim 是被微软签名的固件认它。于是信任链变成固件 - shim - grubx64.efi - 内核。shim 会检查 grubx64.efi 是否被 Red Hat 的密钥签名或者被用户自己导入的 MOKMachine Owner Key签名。这个机制在实际运维中最大的坑就是第三方内核模块。比如你在 RHEL 9 上装了 Nvidia 闭源驱动、某些自带 DKMS 的网卡驱动它们编译出来没有合法签名Secure Boot 开启时内核直接拒绝加载。最典型的表现是开机报Verification failed: (0x1A) Security Violation或者模块加载时 dmesg 里刷一堆module verification failed。我自己遇到过一台装 IB 网卡驱动的机器就是卡在这里。处理办法无非两条要么在固件里关掉 Secure Boot要么用mokutil导入自己的密钥。生产环境不建议乱关 Secure Boot更规范的方式是走 MOK 流程# 生成密钥并签名这一步在开发机上做 mokutil --import key.der # 重启后 shim 会进入 MOK 管理界面确认导入1.3 固件阶段的故障长什么样固件阶段出问题操作系统层面的工具基本都看不到因为内核还没起来。最常见的现象有三种黑屏连 RHEL 的 logo 都没有开机直接进固件设置界面卡在Reboot and Select proper Boot device。前两种基本指向启动项丢失或固件变量混乱第三种多半是引导程序和硬盘失联。UEFI 启动项被误删或者 ESP 分区被格式化是运维里比较常见的低级事故。比如有人在 Windows 和 RHEL 双系统环境里手贱删了 ESP 分区然后把 RHEL 也带崩了。修复思路不是去恢复分区而是用一个 RHEL 9 安装介质或 Live 环境启动chroot 进系统后重装 GRUB 并重建启动项这个我在第 5 章再展开。2. GRUB2 吃什么配置从引导菜单到内核参数的下发2.1 grub.cfg 不是拿来手工编辑的RHEL 9 里 GRUB2 的实际配置文件是/boot/grub2/grub.cfg。UEFI 模式下 ESP 分区里的/boot/efi/EFI/redhat/grub.cfg只是一个小转发文件内容基本就是一行configfile /grub2/grub.cfg。很多新人对这个“两层配置”很懵其实原理很简单GRUB 本体程序在 ESP 里配置文件在/boot上两边各管各的。关键一点grub.cfg 是生成出来的不是手工编辑的。生成命令是grub2-mkconfig -o /boot/grub2/grub.cfg它读取/etc/default/grub和/etc/grub.d/下的脚本再结合当前系统里装的内核生成完整菜单。为什么不能手工改因为当你安装新内核、修改默认参数、升级 grub 相关包时系统会自动重新生成配置文件你手改的部分会被无声覆盖。我在生产环境见过有人直接在 grub.cfg 里加nomodeset修显卡问题结果下次内核更新后故障复发还一脸懵——这就是把配置写错地方了。正确的持久化修改方式是编辑/etc/default/grubGRUB_TIMEOUT5 GRUB_CMDLINE_LINUXconsolettyS0,115200n8 nomodeset改完执行grub2-mkconfig -o /boot/grub2/grub.cfg重新生成。另外grub2-editenv list可以查看 GRUB 环境块里面记录了默认启动条目等信息这玩意在排障时也经常用到。2.2 BLSRHEL 9 的引导菜单是“目录驱动”的RHEL 9 的引导菜单结构和老版本 CentOS 6、RHEL 6 完全不同。老版本里每个内核都有一段冗长的 menuentry 写在 grub.conf 里改配置要小心地数花括号。RHEL 9 用的是 BLSBoot Loader Specification菜单条目变成了/boot/loader/entries/下一个个独立的小文件。grub.cfg 里通过blscfg模块自动扫描这个目录把所有.conf文件变成菜单项。打开一个 RHEL 9 的条目文件长这样$ cat /boot/loader/entries/5.14.0-427.13.1.el9_4.x86_64.conf title Red Hat Enterprise Linux (5.14.0-427.13.1.el9_4.x86_64) 9.4 (Plow) version 5.14.0-427.13.1.el9_4.x86_64 linux /vmlinuz-5.14.0-427.13.1.el9_4.x86_64 initrd /initramfs-5.14.0-427.13.1.el9_4.x86_64.img options root/dev/mapper/rhel-root ro crashkernel1G-4G:192M,4G-64G:256M,64G-:512M resume/dev/mapper/rhel-swap rd.lvm.lvrhel/root rd.lvm.lvrhel/swap rhgb quiet每个字段含义都很直白title 是菜单显示的名字linux 行是内核文件路径initrd 行是 initramfs 镜像路径options 行就是传给内核和 initramfs 的参数。BLS 带来的最大好处是加一个内核就是一两个文件的事不用去改那个巨大的 grub.cfg。但代价是有时候菜单文件里写了内核路径实际/boot下文件却不在了开机就会报错第 5 章我会讲这个案例。日常操作里查询和管理这些菜单条目不要手动去编辑.conf用 grubby 更稳# 查看所有内核菜单的完整信息 grubby --infoALL # 把默认启动项改成第 0 个内核 grub2-set-default 0 # 查看当前默认 grub2-editenv list2.3 内核参数怎么区分“给内核的”和“给 initramfs 的”RHEL 9 启动时传给命令行的参数其实分两类这个区分对排错至关重要。一类是内核自己用的比如quiet、rhgb、consolettyS0,115200n8、nomodeset内核初始化时会消费它们。另一类是给 initramfs 里 dracut 逻辑用的通常带rd.前缀比如rd.lvm.lvrhel/root告诉 initramfs 根卷在哪个 LVM 逻辑卷上、rd.luks.uuid告诉 initramfs 要解密的 LUKS 分区。rhgb quiet是 RHEL 9 默认开启的它把启动过程藏在一个图形化或滚动条的界面后面方便普通用户但排障时必须删掉才能看到实时日志。开机时在 GRUB 菜单界面按e把光标移到 linux 开头的那行删掉rhgb quiet再按Ctrlx启动就能看到完整的内核输出。这个临时修改只在本次启动生效不落盘是排查启动问题最常用的手段之一。rd.break是另一个神级参数加了它之后 initramfs 会在挂载真实根文件系统之前停下来给你一个 shell。重置 root 密码、修复根文件系统都靠它后面单独讲。3. 内核引导与 initramfs从压缩镜像到根文件系统的接力3.1 vmlinuz 被加载之后发生了什么GRUB 把vmlinuz-xxx和initramfs-xxx.img加载到内存后就交棒给 Linux 内核了。这里有个很多人误解的点GRUB 不只是“把文件读进内存”它还会读取内核镜像头部的一个固定结构——boot protocol告诉内核“内存里哪里有你的镜像、哪里有 initramfs、命令行参数是什么”然后跳转到内核入口地址。内核进入后先执行实模式下的启动代码做一些基础硬件探测和内存状态检查然后把自己解压到内存中合适的位置切换 CPU 到保护模式甚至长模式x86_64 下的 64 位模式最后进入 C 语言世界的大本营start_kernel。start_kernel里做的事一连串初始化调度器、内存管理、中断、时间子系统、创建 PID 1 进程等等。这个过程对运维来说就是个黑盒但有一点可以确认如果你在 GRUB 菜单删掉rhgb quiet屏幕上刷出来的那些[ 0.000000]开头的行就是这段旅程的实时日记。事后想看dmesg或journalctl -k -b都能查到。3.2 initramfs 为什么必不可少很多人好奇为什么内核不能直接挂载根文件系统启动非要搞一个 initramfs 出来道理很简单RHEL 9 的根文件系统经常放在 LVM 卷、软 RAID、LUKS 加密盘甚至 iSCSI 多路径设备上而内核自身没有能力加载这些设备对应的驱动也没有 LVM、加密相关的工具。所以需要一个“临时根文件系统”作为跳板它包含存储驱动、lvm2 工具、cryptsetup 工具、udev 规则以及 dracut 的脚本先把真实根设备找出来、准备好再切换过去。RHEL 9 里 initramfs 镜像由 dracut 生成对应文件是/boot/initramfs-$(uname -r).img。想确认里面到底装了啥可以用 lsinitrd# 只查看模块和脚本清单 lsinitrd /boot/initramfs-$(uname -r).img # 直接解包到目录比 lsinitrd 更直观 mkdir /tmp/initramfs-test cd /tmp/initramfs-test lsinitrd --unpack /boot/initramfs-$(uname -r).img我强烈建议新人在测试环境里解包看一次你会有种“原来系统启动时藏了一个迷你 Linux”的真实感。里面跑着一个精简版的 systemddracut 的各个模块被包装成 systemd 单元按dracut.target下的依赖顺序执行udev 加载驱动、lvm 激活卷组、cryptsetup 解密、挂载真实根到/sysroot最终调用systemctl switch-root /sysroot完成切换。switch-root 之后initramfs 里的东西会被清理把内存归还给系统。3.3 SELinux 标签带来的“隐形”阶段RHEL 9 默认 SELinux 是 Enforcing这个对启动过程的影响很多人没注意到。如果系统检测到/etc/selinux/config指定了全新策略、或者根文件系统存在/.autorelabel标志文件开机时会触发全盘文件安全上下文重打标签也就是 auto relabel。表现就是启动异常慢屏幕可能长时间停在某个百分比不动看起来像死机其实它正在逐个文件打标签。我在测试环境里把整个系统恢复到旧快照时踩过一次启动卡在 relabel 阶段特别久当时还以为内核崩了后来才发现是 SELinux 在后台工作。如果真的需要跳过仅限测试环境应急可以在内核参数里临时加selinux0但生产环境千万不要这么干RHEL 9 关 SELinux 会直接改变系统的安全姿态等于是绕过了默认安全机制。更正确的做法是等 relabel 跑完或者手动touch /.autorelabel后重启让它重来。4. systemd 接管从 switch-root 到登录界面的目标链4.1 PID 1 的交接内核把第一棒交给谁内核初始化结束后会启动 PID 为 1 的第一个用户空间进程。RHEL 9 里无论 initramfs 阶段还是真实系统阶段这个进程都是/usr/lib/systemd/systemd。initramfs 里的 systemd 在 switch-root 后就让位给真实根文件系统里的 systemd 继续跑。注意这里不是简单重启整个 systemd 进程通过重新执行自身的方式完成交接所以 PID 还是 1。真实系统里的 systemd 启动后第一件事是读取/etc/systemd/system/default.target决定进入哪个目标状态。RHEL 9 装了图形界面的话默认通常是graphical.target最小化安装就是multi-user.target。两者是依赖关系graphical 依赖 multi-usermulti-user 又依赖 basic.targetbasic 依赖 sysinit.target一环套一环。# 查看当前默认目标 systemctl get-default老运维比较熟悉/etc/inittab那套 runlevel 体系在 RHEL 9 里已经彻底消失了只留下 runlevel 与 target 的映射兼容关系。比如 runlevel 3 对应 multi-user.targetrunlevel 5 对应 graphical.target。systemd 的厉害之处在于它先把所有单元文件读进来分析依赖关系再按照拓扑顺序并行启动没有依赖冲突的服务。这就是为什么 RHEL 9 启动速度比老系统快一大截。4.2 网络、SSH 这些关键服务到底什么时候起对服务器运维来说最关心的就是 SSH 什么时候能连上、网络什么时候通。RHEL 9 里网络管理统一由 NetworkManager 负责它在 sysinit 阶段早期就会启动真正拿到 IP 却要等设备就绪、连接激活。这里有个经典的坑如果你自己写了一个 systemd 单元里面写了Afternetwork.target以为网络一定可用了其实network.target只是个“松散聚合点”它不代表 IP 就绪。要确保网络真正可用应该写AfterNetworkManager-wait-online.service WantsNetworkManager-wait-online.service这是我见过最多人掉进去的启动顺序陷阱。sshd 服务属于 multi-user.target 的依赖项它会比较晚启动但它启动时不依赖网络完全就绪因为 SSH 服务可以监听在 0.0.0.0 上等网络通了自然就能连。firewalld 也是这个阶段启动它与 NetworkManager、sshd 之间有一套完整的依赖关系正常情况下你不需要干预。4.3 用 systemd-analyze 看时间都花在哪RHEL 9 排查启动慢第一工具是 systemd-analyze。三个命令我几乎每次都用# 总耗时和各阶段耗时 systemd-analyze time # 每个单元从启动到完成的时间排行 systemd-analyze blame # 关键依赖链 systemd-analyze critical-chaintime会告诉你 firmware 多长时间、loader 多长时间、kernel 多久、initrd 多久、用户空间多久——这一下就能把“慢”定位到大阶段。blame按耗时排序但要注意它统计的是“单元从开始到完成”的时间包括它在等依赖的时间未必代表你优化这个单元就能提速。critical-chain会告诉你哪条依赖链最长这条链上的每一环都是可以深挖的。想要可视化可以systemd-analyze plot /tmp/boot.svg扔进浏览器看甘特图大段时间一目了然。RHEL 9 默认情况下 journald 的日志持久化是 auto 模式也就是说如果/var/log/journal存在就会写盘。为了后续排障不丢启动日志我建议手动开启持久化mkdir -p /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal systemctl restart systemd-journald之后每次开机的完整日志都留在/var/log/journal里排查“昨天重启到底发生了什么”这类问题会从容很多。5. 排错实战怎么把一个起不来的 RHEL 9 拉回来5.1 先定位故障属于哪一段我排查启动故障第一件事永远不是敲命令而是问三个问题开机能看到什么黑屏还是 GRUB 菜单内核日志刷不刷能不能进 emergency根据现象先分段再决定工具。下面这张表是我自己的快速定位表给你参考故障现象大概率阶段第一排查手段全黑、直接进固件、Security Violation固件UEFI 设置、efibootmgr、Secure Boot 策略停在 GRUB 菜单、grub 提示符、报 file not found引导器检查 loader/entries、grub.cfg、重新安装 GRUB内核 panic、堆栈刷屏内核删除 rhgb quiet 看输出、换旧内核、查启动参数卡在内核日志后没动静、出现 dracut 求救界面initramfs 阶段rd.break 进入 shell、lsinitrd 检查镜像、dracut 重建服务启动失败、启动极慢、卡在 emergencysystemdjournalctl -b、systemctl list-units --failed5.2 从 GRUB 命令行走一条排错链路进 GRUB 菜单后按e这算是解锁排错之门的钥匙。你能临时修改内核参数注意是临时生效不会写盘失败了重启就复原非常适合试错。最常用的几组改法# 删掉这两项让所有启动日志打到屏幕上 # 把: rhgb quiet 删掉 # 在行尾追加让 initramfs 挂载真根前停住 rd.break # 在行尾追加直接进入 emergency 模式 systemd.unitemergency.targetrd.break停住后你会得到一个 root shell但这时根文件系统还没挂载或挂在/sysroot。接下来是一套固定的操作重置 root 密码就靠它# 确保真实根已挂载如果没挂载先挂上 mount -o remount,rw /sysroot # 进入真实根 chroot /sysroot # 改密码 passwd root # 关键一步因为 chroot 里跑过修改操作安全上下文可能变了 # 创建这个文件让重启后自动 relabel避免 SELinux 报错 touch /.autorelabel exit exit这里的touch /.autorelabel是很多教程不会提、但极其关键的一步。不加它改完密码直接重启很可能出现系统起不来或者 SID 相关错误我见过有人因为这个在 emergency 模式里反复折腾。5.3 我遇到的一个典型故障/boot 快照回滚导致的内核文件“幽灵”最后分享一个真实案例。某台跑 RHEL 9.4 的虚拟机头一天还正常第二天开机卡在 dracut 的求救界面提示找不到根设备。先砍掉rhgb quiet重启看到内核日志里明确说Failed to mount /sysroot然后用rd.break进 shell发现/dev/mapper/rhel-root根本不存在。再一查是虚拟化平台做了快照回滚把卷组的元数据回滚到了旧状态但/boot/loader/entries里的内核和 initramfs 文件却来自较新的状态两边对不上。处理方式不复杂但很能说明问题在 GRUB 菜单按e检查 linux 行把内核路径改成确实存在的旧版本vmlinuz-xxx和initramfs-xxx.img先进系统然后重新生成 initramfs、更新引导配置。整个过程就像是在启动链路的两个节点之间手动搭了一座临时桥。这个案例给了我很深一个印象RHEL 9 的启动过程是一条链固件找 GRUBGRUB 找内核文件内核找 initramfsinitramfs 找真实根systemd 拉起用户空间。每一个引用关系都建立在文件和时间戳的匹配上。排障时脑子里装着这条链就不会像无头苍蝇一样到处试命令。我自己现在排查任何一台 RHEL 9 起不来的机器流程已经固化成肌肉记忆了先问能看到什么、是否能进 emergency、内核日志在不在然后顺着链从前往后推在可疑节点用rd.break或 journald 日志做验证。这套“分段定位”的思路说穿了不值钱但比任何单一工具都管用。你要是第一次接触 RHEL 9 启动过程建议拿一台测试机反复执行systemd-analyze和dracut -f重建 initramfs再故意把/boot/loader/entries里的路径改错一次亲眼看看故障长什么样下次真遇到时就不会慌。