简介《Linux系统启动过程与故障排除》PDF面向Linux系统管理员与运维学习者系统梳理了从BIOS自检、MBR引导、GRUB配置到内核加载与系统服务初始化的完整启动链路旨在解决开机失败、内核崩溃、密码遗忘等常见故障。资源包为1个PDF文件大小225KB内容精炼便于离线阅读与快速查阅。目前已有115人学习适合需要掌握启动引导细节或排查开机异常的技术人员。资料详细讲述了GRUB配置文件的生成与修改方式以及通过编辑模式临时添加single、emergency等启动参数进入救援模式的操作针对忘记root密码、/boot目录文件丢失、fstab中UUID错误等情况给出了troubleshooting模式下的具体恢复步骤包括重装GRUB与内核、复制备份恢复passwd等。此外还涉及GRUB加密设置、/etc/rc.local自启动命令检查等进阶维护技巧每一环节均配有命令示例与排查思路能帮助管理员快速定位故障根因并实施修复。1. Linux系统启动与故障排除这份实战资料到底能解决什么凌晨两点的机房电话那头是值班同事发烫的声音服务器起不来了卡在grub提示符一动不动。这种场景下你需要的不是重装系统而是一套能按顺序往下走的排查手段。《Linux系统启动过程与故障排除》这份资料整理自 linux 公社的实战故障案例把从 BIOS 到 MBR、GRUB、内核加载的完整启动链条讲清楚了也把单用户模式、emergency 模式、troubleshooting 模式三种修复入口的操作细节都列了出来。它不是一本系统管理手册而是一份能照着敲命令的故障修复笔记适合被启动问题困住的运维、系统管理员以及准备 Linux 运维面试的人。拿到它之后你至少能在系统起不来时判断出该进哪个模式、该动哪个文件。2. 启动全链路拆解从BIOS到内核加载的六个环节与参数落点系统起不来的时候第一步不是急着敲命令而是先判断它停在哪一步。启动是一条单向链路BIOS 自检、BIOS 激活 MBR、grub 引导程序加载到内存并生成微系统、grub 读取分区表找到引导分区、grub 读取配置文件找到内核文件、加载内核。任何一个环节出错症状都不一样——卡在 grub 提示符、黑屏无输出、还是反复重启背后对应的是完全不同的修复路径。这一章先把链条拆开后面所有排障都围绕这条链展开。2.1 MBR与GRUB的职责边界446字节引导程序与64字节分区表先说 MBR 这个常被当成黑匣子的东西。MBR 位于磁盘第一个扇区总共 512 字节其中 446 字节放主引导程序64 字节放分区表最后 2 字节是结束标志。BIOS 完成自检后按启动顺序读取第一个启动设备的第一个扇区把引导程序装进内存执行权就交到了 grub 手上。grub 进入内存后不会马上去找内核而是先给自己搭建一个微型运行环境。这个环境小到只有文件系统驱动和基础命令作用就是让 grub 有能力读分区表、识别 xfs、ext4 这类文件系统然后顺着分区表定位到 /boot 所在分区再读取 grub.cfg最终找到并加载 vmlinuz 内核文件。理解这个微系统概念很重要后面你在救援环境里执行grub2-install、grub2-mkconfig本质上都是在重建这条链路的某一段而不是去动系统本身的数据。提示MBR 只有 512 字节所以 grub 程序本体通常拆成两个部分——写进 MBR 的那一小段只是引导入口真正的完整代码放在/boot/grub2/ 或 /boot/grub/ 目录里。这也是为什么 /boot 目录损坏后光重写 MBR 还不够必须连 grub 文件一起恢复。2.2 配置文件改动原则改/etc/default/grub而不是grub.cfg启动配置的修改原则只有一条别直接动/boot/grub2/grub.cfg。这个文件是由/etc/grub.d/下的脚本和/etc/default/grub共同生成的产物每次内核更新时都会自动重新生成。你手动改了它下一次 yum update 跑完新内核改动就全部被覆盖了。资料里强调的修正路径是改/etc/default/grub然后执行grub2-mkconfig让它生效。# 查看当前默认的启动配置 cat /etc/default/grub # 修改 /etc/default/grub 之后重新生成真正的 grub.cfg grub2-mkconfig -o /boot/grub2/grub.cfg逻辑说明第一行先确认当前配置长什么样避免盲目追加参数导致重复项。第二行是整个配置生效的关键-o明确指定输出路径生成的 grub.cfg 会读取/etc/default/grub和/etc/grub.d/下的脚本内容把它们合并成最终启动菜单。跑完这一步新配置才真正进入 grub 的读取范围。参数说明-o是 --output 的简写路径必须指向/boot/grub2/grub.cfg写错路径会把配置生成到别处重启后完全不生效。/etc/default/grub里几个最常用的参数我在下表里列出来日常改配置基本绕不开这些。参数作用示例GRUB_TIMEOUT启动菜单等待秒数0 表示直接进默认项GRUB_TIMEOUT5GRUB_DEFAULT默认启动项可用菜单序号或标题GRUB_DEFAULT0GRUB_CMDLINE_LINUX追加内核启动参数引号内空格分隔GRUB_CMDLINE_LINUXrhgb quietGRUB_DISABLE_RECOVERY是否生成救援菜单true 为不生成GRUB_DISABLE_RECOVERYtrue2.3 grub2-set-default与cmdline参数切换默认系统与内核参数多内核或者双系统环境下设置默认启动项是高频操作。grub2-set-default命令配合grub2-editenv能直接修改 grub 环境变量里记录的默认项而不需要每次都重跑 mkconfig。# 设置默认启动项为菜单第 0 项 grub2-set-default 0 # 查看当前 saved_entry 变量的值 grub2-editenv list逻辑说明grub2-set-default把菜单序号写进 grub 的 saved_entry 环境变量新版 grub2 启动时优先读这个变量决定进哪个菜单项。grub2-editenv list用来确认写入结果。这里有个容易误判的点如果你同时在/etc/default/grub里改了 GRUB_DEFAULT 但没有执行grub2-set-default重启后可能发现还是进了原来的系统。原因是 grub 环境变量里留存的旧值优先配置文件里的新值没被同步进去。内核启动参数的落点也在这一环。需要给内核追加参数时编辑/etc/default/grub的 GRUB_CMDLINE_LINUX 行在引号内追加参数比如加上consolettyS0,115200n8用于串口调试输出然后重新生成 grub.cfg。改 cmdline 参数前有个习惯值得养成先cat /proc/cmdline看一下当前实际生效的参数避免把新参数重复追加造成启动参数里出现两段一样的配置。这是个不起眼但很典型的坑重复的 console 参数有时会让内核输出混乱排查起来非常浪费时间。3. GRUB编辑模式实操single、emergency与init/bin/sh三种入口怎么选说到启动故障修复最常用也最需要小心的入口是开机时进入 GRUB 编辑模式。开机菜单里按e键临时改动启动参数不影响磁盘上已有的配置文件重启后自动还原——这是它适合做一次性修复的核心原因。资料里的几个典型故障案例几乎都从这一步开始。下面按照入口从简单到底层的顺序把三种方式讲清楚。3.1 开机按e进编辑模式定位linux16行和参数追加位置进入编辑模式的操作并不复杂但第一次做的人很容易按错键。开机出现 GRUB 菜单时按e进入一个文本编辑界面里面列出了 grub 的启动指令。你需要找到以linux16或linux开头的那一行这是内核加载指令所在的位置。把光标移到这一行末尾追加你要传入内核的参数多个参数之间用空格分隔然后按Ctrlx启动。# GRUB 编辑界面中找到类似下面这一行 linux16 /vmlinuz-3.10.0-1160.el7.x86_64 root/dev/mapper/cl-root ro rhgb quiet # 在行尾追加 single、emergency 或 init/bin/sh然后按 Ctrlx逻辑说明linux16这行本身就是内核文件的加载命令后面跟的root指定根分区设备路径rhgb quiet是图形化启动进度和静默日志。我们在行尾追加的 single、emergency、init/bin/sh本质上是告诉内核在拉起用户空间时启动到不同的 systemd target或者直接绕过 systemd 给一个 shell。参数说明追加参数时不要删掉原有的root和roro表示启动初期以只读方式挂载根分区这是让 fsck 能在干净状态下检查文件系统的基本前提。如果你把ro也删了文件系统可能带着写状态挂载后续修复动作的可靠性会大打折扣。按Ctrlx启动后修改只在本次启动生效不会写进 grub.cfg这点务必记住——它不是持久化配置只是应急入口。3.2 救援模式与emergency模式的取舍服务数量、root密码与修复场景资料里描述的救援模式其实就是常见文档中的单用户模式在 linux16 行末尾加single或s进入。这个模式只启动系统必需的少量服务原资料里提到只需 8 个服务此时系统可以正常启动到 shell但需要 root 密码。emergency 模式更精简需要的服务比救援模式还少同样需要 root 密码。两者的核心区别在于服务集合的大小这决定了你能在里头执行哪些修复操作。模式启动参数服务量是否需要root密码适合场景救援模式单用户single 或 s约 8 个基础服务是挂载文件系统、修复软件包、改配置emergency 模式emergency更少近乎裸环境是查看启动日志、修复 fstab、定位挂载失败选择逻辑通常是能进救援模式就不进 emergency因为救援模式里网络相关服务和基础工具链是完整的修起来顺手emergency 模式下根分区处于极度精简状态很多命令用不了适合做诊断而不是操作。进入这两个模式时如果发现卡在输入密码这一步先不要怀疑密码错了很可能是 root 账户被锁定或者阴影文件有问题具体排查放到第 5 章展开。3.3 忘记root密码的完整重置流程init/bin/sh、autorelabel与exec /sbin/init忘记 root 密码是面试和技术群里出镜率最高的问题也是资料里给得最详尽的一个案例。完整流程分五步编辑启动文件加init/bin/sh把rhgb quiet删掉启动后用读写方式重新挂载根分区用passwd改密码在根目录创建.autorelabel隐藏文件最后执行exec /sbin/init继续启动。整体代码如下# 启动后第一个动作以读写方式重新挂载根分区 mount -o remount,rw / # 重置 root 密码 passwd root # 创建 SELinux 重新标记标记文件避免重启后卡在登录界面 touch /.autorelabel # 把控制权交回 init 进程继续后续启动流程 exec /sbin/init逻辑说明init/bin/sh让内核在完成基本初始化后直接启动一个 root shell绕过了正常的登录验证流程所以不需要密码就能进入。但代价是此时文件系统是只读挂载的直接改密码会报只读文件系统错误所以第一件事必须是mount -o remount,rw /。touch /.autorelabel这一步很多人会漏掉它的作用是触发 SELinux 对根文件系统的重新标记。用 init/bin/sh 方式启动时绕过了 SELinux 策略加载改过的 shadow、passwd 文件安全性上下文不对不重新标记的话重启后 login、sshd 等服务会拒绝读取这些文件表现为系统起来但无法登录。参数说明-o remount,rw表示用 rw 选项重新挂载根分区exec /sbin/init是让当前 shell 进程被 init 进程替换继续走正常初始化。需要留意的是新版系统里exec /usr/lib/systemd/systemd更贴近实际路径但 CentOS 7 及之前的系统上/sbin/init兼容性最好这也是资料采用这个写法的主要原因。4. troubleshooting模式修复实录重装GRUB、修fstab、恢复passwd与shadow单用户模式能解决一部分问题但如果 /boot 目录整个坏了、grub 引导程序丢了、关键文件系统挂载失败还是要进 troubleshooting 模式也就是安装介质自带的救援环境。这个模式不会直接启动你的原系统而是把原系统的根分区挂到一个临时目录让你从外部去修复它。这一章把三个典型修复场景完整走一遍。4.1 chroot /mnt/sysimage从救援环境进入真实roottroubleshooting 模式启动后系统会把检测到的原根分区挂载到/mnt/sysimage而不是直接当作/使用。要操作原系统必须先chroot /mnt/sysimage切进去。这一步的意义在于当前 shell 的/会变成原系统的根目录你执行的命令、读取的文件全都来自原系统不用再写/mnt/sysimage/boot、/mnt/sysimage/etc这种长前缀。# 先确认原系统根分区挂在了哪里 df -h /mnt/sysimage # 进入原系统的真实 root 环境 chroot /mnt/sysimage逻辑说明df -h /mnt/sysimage用来确认救援环境是否正确识别并挂载了你的原分区。如果这一行是空的说明分区没被自动挂载需要手动mount /dev/sda2 /mnt/sysimage之类的操作先把根分区挂上再做 chroot。chroot之后当前 shell 的/变成原系统的根目录原系统的/etc/passwd、/boot/grub2、/lib/modules全部直接可见可写。参数说明chroot 不需要额外参数但进入后要留意/proc、/dev这类虚拟文件系统是否可用必要时执行mount --bind /dev /mnt/sysimage/dev去补齐否则你在 chroot 环境里跑某些命令会报设备不存在。4.2 重装内核与重建grub.cfgboot目录损坏的完整恢复路径/boot 目录文件被误删或者损坏系统会在 grub 读取内核文件那一步卡死——grub 能找到分区但找不到 vmlinuz。修复路径是进入 troubleshooting 模式chroot 到原系统挂载安装光盘或 ISO用 rpm 装回内核包再重建 grub.cfg 并重写 MBR。# 进入 troubleshooting 模式后先切到原系统的 root 环境 chroot /mnt/sysimage # 挂载安装光盘或 ISO 镜像到 /mnt mount /dev/cdrom /mnt # 用 rpm 安装光盘 Packages 目录里的内核包版本以实际文件名为准 rpm -ivh /mnt/Packages/kernel-3.10.0-1160.el7.x86_64.rpm # 创建 grub2 目录重新生成真正的 grub.cfg mkdir -p /boot/grub2 grub2-mkconfig -o /boot/grub2/grub.cfg # 重装 grub 引导程序到第一块硬盘的 MBR grub2-install /dev/sda逻辑说明rpm -ivh安装内核包时会把 vmlinuz、initramfs 放回 /boot同时把内核模块装到/lib/modules对应版本目录下。随后grub2-mkconfig会自动扫描 /boot 里已有的内核文件并生成启动菜单项不需要手动指定版本。最后grub2-install /dev/sda把 446 字节的引导程序写进第一块硬盘的 MBR让 BIOS 能找到 grub 的完整代码。参数说明-ivh里的i是 install 安装v是 verbose 显示详细信息h是 hash 显示安装进度条。grub2-mkconfig的-o必须指向/boot/grub2/grub.cfg如果漏写-o grub.cfg生成的配置会直接打印到屏幕上而不是写进文件这是新手最容易翻车的地方。grub2-install后面跟的是设备节点不是分区路径一定写/dev/sda而不是/dev/sda1。注意grub2-install只重写引导程序本身不会恢复 /boot 里的文件所以必须先完成 rpm 装内核这一步再执行它。顺序反过来你得到的仍然是一个找不到内核的 grub。4.3 fstab UUID不一致与passwd、shadow丢失两个典型数据修复案例案例一是分区 UUID 与 fstab 不一致。如果挂载文件时用的是分区 UUID并且已经写进 /etc/fstab后续用mkfs或者其他工具改动过分区导致 UUID 变了但 fstab 里的记录没同步更新启动时 systemd 按旧 UUID 找不到设备会直接进 emergency shell。# 查看当前分区的真实 UUID blkid /dev/sda2 # 查看 fstab 里记录的 UUID grep UUID /etc/fstab # 用新 UUID 替换旧值替换前确认旧值只在 fstab 里出现一次 sed -i s/旧UUID/新UUID/ /etc/fstab逻辑说明blkid读出来的是分区表里的实时 UUIDgrep UUID /etc/fstab看的是静态配置里的记录值两者对不上就挂载失败。sed替换前先 grep 确认旧值在 fstab 里的出现次数防止误替换到别的分区记录——同一个 UUID 出现在多行时逐个确认再动手。案例二更惊险/etc/passwd 和 /etc/shadow 丢失。资料里描述的症状是屏幕黑屏、没有任何显示因为 login 进程需要读取这两个文件才能工作文件不在时它直接起不来启动流程走到最后却没有任何可登录的界面。恢复方式是利用系统自带的备份副本# 用系统自带的备份文件还原 cp -a /etc/passwd- /etc/passwd cp -a /etc/shadow- /etc/shadow逻辑说明RHEL/CentOS 系列系统在例行维护时会生成 passwd-、shadow- 这类备份文件内容通常是几天前的快照。-a参数保留属主、权限和时间戳恢复后用户数据库直接回到可用状态。但备份是旧的恢复后建议立刻passwd root重设一遍密码因为快照里记录的密码可能不是当前需要的。这个场景下还要顺带看一眼/etc/rc.local。它是系统启动时执行自定义命令的兜底脚本如果某个自启动服务靠它拉起这个文件丢失会让服务恢复不完整——系统看起来正常实际业务服务少了几个。5. 启动修复避坑手册五个常见翻车点与排查方法下面的坑每一个都是真机上踩出来的。现象各有不同根因却都藏在启动链路的细节里。按现象→原因→解决的方式整理方便你遇到同样问题时直接对照。5.1 现象改了grub.cfg后内核一更新配置全部丢失现象手动编辑 /boot/grub2/grub.cfg加了自定义启动参数过几天跑了一次内核更新重启后发现改动全没了。原因grub.cfg 是生成的产物文件不是配置文件。内核更新时 yum/dnf 会自动执行 grub2-mkconfig 重新生成它之前的手动改动被整体覆盖。解决所有参数改动一律写在 /etc/default/grub 里改完执行grub2-mkconfig -o /boot/grub2/grub.cfg。这个后悔药是成本最低的预防手段。以后每次更新内核后grep 一下新生成的 grub.cfg确认自定义参数带进去了再重启。5.2 现象加了single仍要求root密码输对了也进不去现象开机按 e 在 linux16 行尾加 single 或 s回车启动后卡在 Password 提示输入 root 密码却被拒绝反复几次都进不去。原因这不是配置错误是系统设计。救援模式走的是 rescue.target内部通过 sulogin 请求 root 密码。如果 root 账户被usermod -L锁定过或者 /etc/shadow 里 root 记录以!开头密码正确也会被拒。解决换init/bin/sh入口直接绕过 sulogin或者在 emergency shell 里检查 shadow 文件中 root 行确认是否存在!锁定标记有就先解锁再退出去重启重试。这种情况在自动化初始化的服务器上并不少见很多人误以为是密码错了白白花时间重置。5.3 现象用init/bin/sh改完密码重启系统卡死或登录后闪退现象按资料里的完整流程重置完 root 密码exec /sbin/init后重启进度条走到一半卡住或者好不容易起来进登录界面输入密码又被弹回。原因改密码时没有创建 /.autorelabel 文件。init/bin/sh 方式绕过了 systemd也跳过了 SELinux 策略加载改过的 shadow、passwd 文件安全上下文处于错误状态重启后相关服务拒绝读取它们。解决重置密码后务必执行touch /.autorelabel再 exec /sbin/init。如果已经重启失败只能再从 init/bin/sh 进一次补上 autorelabel 文件走完整启动流程。这个文件只在第一次启动时生效完成重新标记后系统会自动删除它不需要手动清理。5.4 现象改过分区UUID后开机直接进emergency shell现象对磁盘执行了分区格式或复制操作重启后没有正常进系统而是直接掉进 emergency shell提示 fstab 挂载失败。原因/etc/fstab 里记录的还是旧 UUID分区里的实际 UUID 已经变了。systemd 启动时按 fstab 里的 UUID 找设备找不到就进入 emergency 模式等待人工处理。这个问题看着有点玄学其实就是静态配置和实时状态没对齐。解决在 emergency shell 里执行blkid拿到所有分区的真实 UUID对照 fstab 逐行替换。别只盯根分区/boot、swap、home 都要对着 blkid 核对一遍漏一个就是连环挂载失败。改完reboot前先mount -a验证一下 fstab 里的所有条目能正常挂载这一步能提前暴露问题不用等重启后再猜。5.5 现象passwd和shadow丢失屏幕黑屏没有任何提示现象服务器重启后屏幕一直黑着没有任何启动日志和登录提示像是系统根本没起来但电源和风扇状态正常。原因login 进程需要读取 /etc/passwd 和 /etc/shadow 才能完成登录流程文件丢失时它直接异常退出。系统启动流程走到最后一步却没有任何会话可用表现就是黑屏无提示。这种故障的迷惑性很强初看像内核崩溃实际是用户数据库文件缺失。解决进 troubleshooting 模式chroot /mnt/sysimage 后执行cp -a /etc/passwd- /etc/passwd和cp -a /etc/shadow- /etc/shadow还原备份。恢复后立即重置 root 密码。如果连-备份都没有就只能从同版本系统的模板重建用户数据库再把 /root、/home 目录下各用户的属主对照回去工作量要大得多——所以平时备份用户数据库这个习惯关键时刻能救命。6. GRUB加密与应急习惯开机入口的最后一道防线6.1 grub2-mkpasswd生成加密口令并注入00_header我们说过开机按 e 就能改启动参数等于把系统最高权限暴露给了能碰到键盘的人。给它加一道口令锁是生产环境里值得做的一步。grub 的口令机制不需要系统启动就能生效它作用于 BIOS 加载引导程序之后的那个环节。# 生成 PBKDF2 加密哈希交互式输入两次密码 grub2-mkpasswd-pbkdf2 # 把下面生成的密文追加到 /etc/grub.d/00_header 末尾 cat EOF /etc/grub.d/00_header set superusersroot password_pbkdf2 root grub.pbkdf2.sha512.10000.xxxxxx EOF # 重新生成 grub.cfg 让加密配置生效 grub2-mkconfig -o /boot/grub2/grub.cfg逻辑说明grub2-mkpasswd-pbkdf2生成的是不可逆的 PBKDF2 哈希不是明文密码。把set superusers和password_pbkdf2追加到 00_header 末尾重新生成 grub.cfg 后这段配置会原样进入启动菜单。设置生效后每次开机按 e 想编辑启动参数grub 会先要求输入用户名 root 和密码输错就只能在菜单列表里选已有项目不能做任何参数修改。参数说明set superusersroot声明权限级别最高的用户password_pbkdf2 root 哈希串把用户名和密码哈希关联起来。这里有个必须警惕的坑加密后如果你自己忘了密码就只能拿 Linux 安装镜像进 troubleshooting 模式chroot 后把 00_header 里加的这两行删掉再重新生成 grub.cfg 才能解锁。所以生产环境里加密后的哈希值一定要单独备份一份别只存在服务器上。6.2 我的固化习惯改配置、验配置、备份引导三件事从那以后我每次动与启动相关的配置都强制走同样的流程先在 /etc/default/grub 或 /etc/grub.d/ 下的脚本里改接着执行grub2-mkconfig -o /boot/grub2/grub.cfg然后立刻 grep 新生成的菜单文件确认预期改动的内核参数或菜单项已经生效最后把 grub.cfg、fstab、shadow 各备份一份到 /root 下的固定目录。这三件事看起来简单但能挡住前面五个坑里的四个。手边再常备一张 Linux 安装镜像盘所有远程修复手段都失效的时候它就是最后一道保底。启动问题十有八九是急出来的按这条流程走一遍至少能保证每一步改动了什么、为什么改动是清楚的。希望帮到你。本文还有配套的精品资源点击获取