王杰岸1. 项目概述
1.1 核心需求解析
RH134是红帽系统管理进阶课程，紧接RH124的基础内容，主要围绕Linux服务器的日常运维管理展开。而“控制启动过程”这一章，说白了就是搞清楚一台Linux机器从按下电源键到进入登录界面之间到底发生了什么，以及系统管理员如何在这个过程中做文章——比如修改启动参数、切换系统状态、排查启动故障、重设root密码等。
这个章节在RHCSA（红帽认证系统管理员）考试中占比不算最高，但却是最容易被忽视的“基础中的基础”。很多新手背了一堆systemctl命令，却对系统启动的完整链路一知半解，真到出问题时无从下手。学习这一章的价值不在于应付考试，而在于建立对Linux系统生命周期的整体认知，搞清楚“系统是怎么样从无到有跑起来的”，后续学习网络配置、服务管理、日志分析时，才能把知识点串成线。
这篇笔记适合三类人看：一是正在备考RHCSA的学员，需要系统梳理启动流程相关的考试知识点；二是刚接手Linux服务器运维的工程师，需要快速建立故障排查的全局视角；三是对systemd机制感兴趣、想弄明白“开机启动那些事”的技术爱好者。内容会尽量讲透原理，再落到具体命令，确保照着可以做，看完了能举一反三。
1.2 学习目标拆解
这一章按我自己的理解，实际上是四个递进的层次：
- 第一层是“看懂启动链路”：从固件到引导器到内核再到systemd，每一步做什么、为什么这么做。
- 第二层是“会改启动行为”：通过修改GRUB2配置、调整systemd的target，让系统以预期的状态启动。
- 第三层是“能处理启动故障”：比如内核参数导致起不来、默认target被改坏、root密码遗忘，这些运维现场的高频问题。
- 第四层是“能解释系统状态”：明白runlevel和target的对应关系，能准确判断系统当前处于什么状态，以及如何在不同状态间切换。
四个层次层层递进，互相依赖。只背命令不搞懂链路，遇到非典型问题就没辙；只懂原理不动手操作，考试和实战都会卡壳。下面的内容就按这个思路逐步展开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 启动流程全链路拆解
2.1 从按下电源键到GRUB界面
Linux系统的启动过程，拆开看其实是一条清晰的链路：固件初始化 → 引导加载程序 → 内核加载 → init进程 → 服务启动。每一步都有明确的分工。
先说固件这一层。现在的服务器基本都使用UEFI（统一可扩展固件接口），替代了老一代的BIOS。UEFI和BIOS的本质区别在于：BIOS是16位模式的固件，通过读取硬盘第一个扇区（MBR主引导记录）来加载引导程序，整个过程比较原始，而且无法直接读取文件系统；UEFI是32位或64位的固件，支持直接从FAT格式的ESP分区（EFI System Partition）中的.efi文件加载引导程序，能力更强，也支持安全启动。
判断一台机器用的是UEFI还是BIOS，最直接的办法是看有没有/sys/firmware/efi这个目录。有，就是UEFI启动；没有，就是传统BIOS模式。这个判断在日常运维中很有用，比如规划分区时就需要注意：UEFI模式必须有一个ESP分区来放引导文件，传统BIOS模式则需要有一个BIOS boot分区（或直接装在MBR上）。很多新手在这上面踩坑——用UEFI模式装系统却忘了建ESP分区，结果引导装不进去。
固件完成自检（POST，上电自检）后，会根据启动顺序找到可启动设备，把控制权交给引导加载程序。在红帽系Linux中，这个引导加载程序就是GRUB2（Grand Unified Bootloader version 2）。GRUB2是一个极其重要的角色：它负责加载内核镜像vmlinuz和初始RAM磁盘initramfs，并把它们加载到内存中。
initramfs这个文件值得特别说一句。它是内核启动初期的一个“过渡环境”，里面包含了内核启动早期需要的驱动和工具，比如硬盘控制器驱动、文件系统驱动、LVM工具等。为什么需要它？因为内核本身并不内置所有硬件驱动——如果内核想读根文件系统上的内容，但根文件系统所在的硬盘需要驱动才能识别，这就成了“先有鸡还是先有蛋”的死循环。initramfs就是这个“蛋”，它先被加载到内存，让内核具备识别根文件系统所在存储设备的能力，然后卸载自己，把控制权交给真正的根文件系统上的init程序。整个过程大概就是这么个逻辑。
2.2 内核加载与systemd登场
GRUB2把内核和initramfs加载进内存后，内核开始初始化硬件、解压initramfs、挂载根文件系统。这里有一个非常关键的参数：rhgb quiet。
rhgb是Red Hat Graphical Boot的缩写，作用是显示图形化的启动画面；quiet则抑制启动过程中的详细日志输出。这两个参数在日常使用中很友好，但在排障时非常碍事——你根本看不到内核输出的错误信息。所以我个人的习惯是：如果机器出了问题，先在GRUB菜单按e进入编辑模式，把rhgb quiet删掉，让内核把所有启动信息打到屏幕上，往往能直接看到卡在哪一步。
根文件系统挂载完成后，内核会启动第一个用户空间进程，PID为1。在红帽7及以后的系统中，这个进程就是systemd。从这一刻起，系统从“内核态”进入“用户态”，接下来的所有服务管理、启动顺序控制，都由systemd负责。
systemd的设计思路和传统SysV init完全不同。SysV init用一串启动脚本来串行启动服务，依赖关系靠脚本书写顺序硬排，启动速度慢，管理起来也不够灵活。systemd用“单元”（unit）来描述每一项工作，单元之间有明确的依赖关系，可以并行启动互不依赖的服务，大幅提升启动速度。同时，systemd引入了“目标”（target）机制来定义系统要到达的最终状态，替代了传统SysV的“运行级别”（runlevel）。这些内容在后面章节里会展开细讲。
3. GRUB2配置与内核参数调优
3.1 GRUB2配置文件结构与操作
GRUB2的主配置文件在/boot/grub2/grub.cfg，但想改启动项、调内核参数，一般不动这个文件。grub.cfg是自动生成的文件，里面的内容是靠grub2-mkconfig命令扫描其他配置片段拼出来的。手动改它，下次重新生成配置时改动就没了，而且这个文件结构复杂，手动编辑极易出错。
正确的做法是修改/etc/default/grub文件，然后重新生成grub.cfg。这个文件里最常见的两个变量是GRUB_TIMEOUT和GRUB_CMDLINE_LINUX：
GRUB_TIMEOUT：GRUB菜单等待用户选择的时间，单位是秒。如果设为0，系统会直接启动默认项，不等待；如果设为-1，则会一直等待用户选择。GRUB_CMDLINE_LINUX：以引号包围的内核参数列表，这些参数会在每次启动时传给内核。
修改完/etc/default/grub后，需要重新生成配置。注意区分平台：在传统的BIOS系统上运行grub2-mkconfig -o /boot/grub2/grub.cfg；在UEFI系统上则通常是grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg。如果不确定该用哪个路径，可以先查一下ESP挂载在哪。现代红帽系统里grub.cfg在传统路径下其实是一个链接，指向UEFI路径下的实际文件，所以很多情况下直接执行第一条命令也一样生效。
排查GRUB配置错误还有一种“现场处理”的方式：启动时在GRUB菜单界面按e进入临时编辑模式，修改参数后按Ctrl+X启动。这个模式下做的修改不会保存到配置文件，只对本次启动生效。它最大的价值在于“试错”——先用临时参数确认系统能正常启动，再回头把配置固化。这样避免改坏配置后陷入困境。
3.2 常用内核参数实战
内核参数是控制启动行为的另一大维度。内核启动时，/proc/cmdline文件记录的就是本次内核启动实际使用的参数。想确认当前用了哪些参数，执行cat /proc/cmdline就能看到。
以下是运维中高频使用的几个内核参数：
| 参数 | 作用 | 典型使用场景 |
|---|---|---|
rhgb |
显示图形化启动画面 | 默认开启；排障时删除 |
quiet |
抑制启动日志 | 默认开启；排障时删除 |
systemd.unit= |
指定系统直接进入某个target | 开机直接进emergency修复系统 |
rd.break |
在initramfs阶段挂起，进入交互shell | 破解root密码 |
single 或 s |
单用户模式（等价于rescue.target） | 修复系统 |
selinux=0 |
临时关闭SELinux | 排查SELinux导致拒绝服务的问题 |
ip= |
配置网络参数 | 网络引导等场景 |
需要特别提醒的是，selinux=0这类参数在生产环境上慎用。它适合在本地排查问题时“临时绕过”SELinux限制，确认问题是否由SELinux引起，但绝对不能作为长期方案。如果你确实需要关闭SELinux，正确方式是修改/etc/selinux/config把SELINUX=enforcing改成SELINUX=permissive，然后重启。注意，permissive模式下SELinux不拦截行为但会记录日志，比直接禁用更适合排查问题。
内核参数还有一种“一次性的临时修改”方式，就是单次启动时在GRUB菜单里按e编辑。我处理启动失败问题时，惯用流程是这样的：进入GRUB编辑模式 → 删掉rhgb quiet → 加入systemd.unit=emergency.target或rd.break → 启动系统 → 完成修复 → 重启恢复正常模式。这套流程每一步做什么、为什么这么做，下面第5部分会给出完整的操作录。
4. systemd的target机制与原理解读
4.1 runlevel到target的演进逻辑
红帽7以前的Linux系统使用SysV init，用runlevel（运行级别）来定义系统状态。0代表关机，1代表单用户模式，3代表多用户命令行模式，5代表图形化多用户模式，6代表重启。这种设计的痛点在于：runlevel是一个“状态”，但服务的启停管理是另一套模型，两者之间靠一连串的软链接脚本艰难地关联。
systemd把runlevel的概念升级成了target（目标）。target本质上是“一组单元的集合”，systemd启动时会并行启动这个target依赖的所有单元。RHEL/CentOS 7及以后版本中，runlevel和target的对应关系如下：
| 运行级别 | target | 说明 |
|---|---|---|
| 0 | poweroff.target | 关机 |
| 1 | rescue.target | 单用户修复模式 |
| 2 | multi-user.target | 多用户命令行模式（与runlevel 3等价） |
| 3 | multi-user.target | 多用户命令行模式 |
| 4 | multi-user.target | 保留，未使用 |
| 5 | graphical.target | 图形化多用户模式 |
| 6 | reboot.target | 重启 |
需要理解的是，runlevel 2、3、4在红帽系系统中都对应同一个multi-user.target，这与Debian系Linux（比如Ubuntu）有明显区别——Debian中runlevel 2是默认图形界面，runlevel 3仍然是命令行。跨平台做运维的朋友容易在这里搞混，需要注意。
target之间也有依赖关系统。graphical.target依赖multi-user.target，也就是说，想进入图形界面，必须先“经过”多用户模式。理解了这层依赖，就能明白为什么执行systemctl isolate multi-user.target会把系统从图形界面切到命令行，反过来执行systemctl isolate graphical.target则能切回图形界面。
4.2 用systemctl管理target状态
日常工作中，管理target的核心命令就那么几个，我用一张表梳理清楚：
| 操作 | 命令 |
|---|---|
| 查看默认target | systemctl get-default |
| 设置默认target | systemctl set-default multi-user.target |
| 切换到某个target | systemctl isolate multi-user.target |
| 查看当前target | systemctl list-units --type=target |
| 查看target依赖关系 | systemctl list-dependencies multi-user.target |
get-default和set-default操作的是/etc/systemd/system/default.target这个软链接。改默认target本质上就是改这个链接的指向，systemctl set-default graphical.target等价于把default.target指向graphical.target。
isolate这个词值得解释一下：它不只是“切换”，而是“隔离”——先把当前target下非指定的所有单元停掉，再启动目标target所需的单元。所以systemctl isolate multi-user.target会关闭图形界面相关服务。这个命令有个前提：目标target必须允许被isolate，否则会报错。绝大多数系统自带的target都支持。
另一个容易混淆的概念是systemctl isolate和systemctl start的区别。start只是“额外启动”，不会停掉其他东西；isolate则是把整个系统“带”到指定状态。如果只是临时想在系统里多跑一个服务，用start；想切换系统状态，才用isolate。
生产环境里，systemctl set-default multi-user.target是一个高频操作。新装的带图形界面的服务器，往往不需要图形环境，把它改成默认进入命令行模式可以省下一大笔内存。反过来，如果你在图形界面下远程操作，不小心执行了systemctl isolate multi-user.target，图形界面会立刻关闭。但SSH连接一般不受影响，因为sshd服务在multi-user.target阶段就启动了。万一连图形界面都没法恢复了，还可以远程通过systemctl set-default graphical.target改回来。
4.3 emergency与rescue两个特殊target的定位
这两个target是排障时的“保命符”，但很多新手分不清它们的区别。我用一句话概括：rescue.target是“带网络功能的单用户模式”，emergency.target是“最小化的救援环境”。
具体看：
-
rescue.target：启动时会挂载根文件系统为可读写的，会启动基本的网络服务，也会启动sshd（如果配置为启用）。主要用于忘记root密码、需要在线修复文件系统但还需要网络连接的场景。进入方式可以是systemctl isolate rescue.target，开机时在GRUB中加入systemd.unit=rescue.target。 -
emergency.target：更极简，只挂载根文件系统为只读，不启动网络。适合根文件系统受损、必须手动检查和修复的场景。进入方式是systemctl isolate emergency.target或开机时加入systemd.unit=emergency.target。
这两个target都需要root密码才能进入。如果忘记root密码怎么办？那就需要用到下面要讲的rd.break或single。此外，rescue和emergency模式下，根文件系统默认只读，排障时通常需要手动重新挂载为可读写：mount -o remount,rw /。这条命令非常关键，很多人进入救援模式后想改配置文件却发现无法保存，就是因为没先执行这条。
5. 实操过程记录：启动故障现场处理全流程
5.1 忘记root密码的处理步骤
忘记root密码是每个运维人迟早会遇到的问题，也是RHCSA考试必考内容之一。处理思路是利用GRUB的“临时编辑”功能，在启动早期中断正常的启动过程，进入一个不需要密码就能操作的shell环境，然后用命令重置密码。
完整操作步骤如下：
- 重启系统，在GRUB菜单界面暂停下来。
- 找到要启动的内核条目，按下键盘上的
e键进入编辑模式。 - 找到以
linux开头的那一行（不同版本字段可能是linuxefi），这是内核启动参数行。在这一行的末尾添加rd.break参数。 - 按
Ctrl+X启动系统，系统会在initramfs阶段中断，进入一个交互式shell，提示符看起来像switch_root:/#。 - 此时根文件系统挂载在
/sysroot目录下，而且是只读的。执行mount -o remount,rw /sysroot把它重新挂载为可读写。 - 执行
chroot /sysroot切换根目录，进入真正的系统环境。 - 执行
passwd root重置root密码。 - 执行
touch /.autorelabel。这一步非常关键，如果系统启用了SELinux，不创建这个标记文件会导致重置密码后系统无法正常登录，因为新密码相关的文件上下文字段可能没被正确标记。这个文件的含义是：告诉SELinux在下次启动时重新标记所有文件的上下文。 - 退出chroot环境：输入
exit。 - 再次输入
exit，系统会继续启动。
整个过程操作完，系统应以新密码进入登录界面。这套方法的本质，是通过rd.break让内核在initramfs阶段“中途停车”，此时系统尚未加载真正的根文件系统，也不存在认证逻辑，自然就不需要密码。
5.2 配置了错误内核参数导致无法启动
这个故障场景也相当常见。假设你在一台服务器上往GRUB_CMDLINE_LINUX里加了某个不兼容的内核参数，或者把SELinux强行设成了enforcing但系统本身配置不符合要求，启动就会在半路卡死，屏幕上可能是一堆报错。
处理思路依然是“用GRUB临时编辑绕过错误参数”：
- 重启，进入GRUB菜单，按
e进入编辑模式。 - 找到
linux行，把导致问题的参数删掉。如果不确定是哪个参数引起的，一个保险的做法是先用systemd.unit=emergency.target或systemd.unit=rescue.target替代启动目标，让系统先进入救援模式。 - 启动进入系统后，检查
/etc/default/grub，修正错误参数。 - 重新生成GRUB配置：
grub2-mkconfig -o /boot/grub2/grub.cfg。 - 重启验证。
有一个很值得养成的习惯：修改/etc/default/grub之前，先备份这个文件，比如cp /etc/default/grub /etc/default/grub.bak。修改完重新生成配置后，先别急着重启，用grub2-editenv list查看一下当前的默认启动项，或者用grubby --info=ALL看看所有内核启动项的参数是否符合预期。多花这几秒钟，能省下后面一晚上的排障时间。
5.3 默认target被改坏的恢复方法
有同学问过：“我把默认target设置成了某个不存在的target，会不会砖机？”答案是：不会，但会卡在启动中。因为系统在启动时会尝试加载default.target，如果目标不存在，启动过程会明显异常或停留在某个奇怪的界面。
恢复的方法是利用GRUB的临时编辑：在linux行末尾加上systemd.unit=multi-user.target，强制本次启动直接进入多用户命令行模式。启动后用systemctl set-default multi-user.target把默认target改回来即可。
顺带说一句，查看和修改默认target本质上是一个软链接操作。/etc/systemd/system/default.target是指向/usr/lib/systemd/system/下某个target文件的链接。了解这一点，你就明白了systemctl set-default改的到底是什么。
6. 常见问题与排查技巧实录
6.1 启动问题排查速查表
根据我接触过的实际案例和RHCSA考试侧重点，整理了一份高频问题排查表：
| 现象 | 可能原因 | 排查/处理方法 |
|---|---|---|
| 启动后黑屏或卡在进度条 | 图形驱动问题 | 进入GRUB编辑，删掉rhgb quiet，观察实际卡在哪一步 |
启动时报Failed to mount / |
根文件系统损坏或fstab配置错误 | 用rescue.target进入，检查/etc/fstab和dmesg输出 |
启动时报Welcome to emergency mode |
某个挂载点失败（通常是fstab错误） | 输入root密码进入emergency模式，修复fstab或执行journalctl -xb查看错误 |
| 忘记root密码 | 密码遗忘 | 按5.1节方法处理 |
| 修改GRUB配置后无法进入系统 | 内核参数错误 | GRUB临时编辑，去掉可疑参数，修复后重新生成配置 |
| 服务启动失败导致无法到达default.target | 某个unit配置错误 | 在GRUB用systemd.unit=rescue.target进入，查看journalctl -xb定位出错服务 |
重中之重的一句话：进入救援或emergency模式后，先看日志，再动手修复。日志是journalctl -xb，其中-x是补充说明信息，-b是本次启动。这个命令能显示启动失败的具体单元以及原因，比猜靠谱一万倍。
6.2 journalctl日志分析与定位技巧
journalctl是systemd的日志查看工具，日志文件默认存放在/var/log/journal/目录下。它和传统的/var/log/messages的区别在于：journalctl收集的是结构化日志，包含更丰富的时间、进程、优先级等元数据。
几个高频用法：
journalctl -b：查看本次启动的所有日志。journalctl -b -1：查看上一次启动的日志。这个在排查启动故障时极其有用——系统起不来一次后，第二次进去了，你还可以看到上次失败时的报错。journalctl -p err：只查看错误及以上级别的日志。journalctl -u sshd：只看sshd服务相关的日志。journalctl -f：类似tail -f，实时滚动输出最新日志。
启动故障排查的标准流程可以总结为：先journalctl -p err -b直接看本次启动的错误，再结合systemctl list-units --failed列出启动失败的单元，两条命令基本能定位90%以上的启动问题。
还有一个很容易被忽略的视图：systemctl status显示某个服务状态时，下方会直接附上该服务最近的日志片段。很多情况下，你只要执行systemctl status 服务名，就能看到它为什么启动失败，不需要额外查日志。
6.3 实战经验：几个我踩过的坑
第一个坑是UEFI和BIOS模式下GRUB配置路径不同。我在一台UEFI机器上执行grub2-mkconfig -o /boot/grub2/grub.cfg后，重启发现改动根本没生效，后来才意识到这台机器的/boot/grub2/grub.cfg其实是一个符号链接，指向/boot/efi/EFI/redhat/grub.cfg。执行重定向写文件时，符号链接本身是能被正确跟随的——我那次的问题其实出在修改的变量名写错了。这里需要多说一句：很多UEFI系统中/boot/grub2/grub.cfg确实是一个symlink，所以直接覆盖写这个路径理论上也会写到实际文件。真正需要注意的，是确认你的ESP分区是否挂载、路径是否正常。
第二个坑是忘了touch /.autorelabel。有一次我在一个SELinux enforcing的机器上通过rd.break重置密码，重启后root登录直接报错，折腾了很久才发现是SELinux上下文的问题。启用SELinux的系统上，如果文件的上下文不匹配，服务可能起不来，登录也可能被拒。touch /.autorelabel这个动作确保SELinux重新标记文件上下文，避免这类问题。
第三个坑是systemctl set-default和systemctl isolate搞混。前者的意思是“下次开机默认进哪个target”，后者是“现在立刻切到哪个target”。有同事想把系统从图形界面切到命令行调试，执行了systemctl set-default multi-user.target，结果图形界面还在，因为set-default不会影响当前系统状态。反过来，有人想改默认启动方式却执行了systemctl isolate multi-user.target，结果图形界面当场被关掉，吓一跳。理解这两个命令的本质区别，能避免很多“看似操作成功实则没用”的尴尬。
第四个坑是关于grub2-mkconfig和grubby的关系。红帽8/9系统也开始用grubby来管理内核参数，grubby --update-kernel=ALL --args="xxx"可以直接给所有内核条目加参数，而不用修改default文件再重新生成。这个工具在处理多内核版本的机器上特别方便。初学者容易在两种工具间纠结，我的建议是：日常改启动参数用grubby更直接，如果要改的是整个GRUB的默认行为（比如超时时间），还是走/etc/default/grub + grub2-mkconfig的路径。
7. 知识拓展与备考建议
7.1 补充知识：systemd单元依赖与启动排序
target机制背后是systemd的单元依赖体系。每个unit文件里，通过Requires=、Wants=、After=、Before=等指令声明依赖和顺序。
这里用最通俗的方式解释：Requires=表示“我必须要这个单元”，如果它启动失败，自己也启动失败；Wants=”表示“我希望有它”，但它失败不影响自己；After=`表示“我在它之后启动”，它只决定顺序，不决定依赖。
理解这套模型，你才能真正看懂systemctl list-dependencies graphical.target输出的依赖树，也才能明白为什么改了一个服务的启动顺序会造成连锁影响。比如，你把一个网络服务改成After=network.target，它就会等网络就绪后再启动；如果你写反了，服务可能在网络没起来时就报错退出。
7.2 RHCSA考试中的启动过程考点
从备考角度，控制启动过程这一章在考试中主要考这几个操作点：
| 考点 | 建议掌握程度 |
|---|---|
| 修改默认target | 必须熟练 |
| 临时/永久修改内核参数 | 必须熟练 |
| 重置root密码 | 必须熟练 |
| 理解rescue和emergency模式的区别 | 必须熟练 |
| 查看启动日志 | 必须熟练 |
| systemctl常用命令 | 必须熟练 |
考试环境里，你会遇到类似这样的题目：把系统默认启动目标改为多用户命令行模式；或者，系统当前默认目标因配置错误无法启动，要求进入救援模式修复。这类题目往往是“过程分”很高——只要你进入救援模式、修改配置、重启，系统能正常起来，得分就没问题。关键还是平时多动手练，把操作变成肌肉记忆。
7.3 学习的路径建议
如果你正式开始学习RH134，我的建议是按这个顺序推进：先花半天时间弄懂systemd的基本单元概念，把systemctl常用命令练熟；然后再学习启动流程各阶段做了什么事；接着重点练习GRUB2的临时编辑，因为它是排障的“万能钥匙”；最后再做几个综合实验，比如制造一个启动故障然后自己修好。
实践环节可以拿虚拟机反复折腾。比如修改默认target为不存在的target观察报错，在GRUB里乱加参数看看启动会怎么样，在/etc/fstab里加一行错误的挂载配置体验emergency模式。一个虚拟机“坏了”就重新装一个，成本几乎为零，但换来的是对启动过程实实在在的理解。
我个人在实际操作中的体会是，这一章能学到什么程度，不取决于你记住了多少命令，而取决于你敢不敢把系统弄坏再修好。Linux系统管理说到底就是“大胆假设、小心验证、快速恢复”，启动过程就是最好的练兵场。希望这篇笔记能帮你少踩一些坑，把启动过程真正变成你的“可控区域”。