🎯 经典实战案例 | 6大启动故障场景，从内核崩溃到文件系统损坏全解析！

📖 写在开头：你是不是也这样？

第一段：痛点场景

你有没有遇到过这样的绝望场景？系统更新后无法启动，显示"Kernel panic - not syncing: VFS: Unable to mount root fs"，你完全不知道该怎么办。更糟糕的是，你尝试从旧内核启动，但系统还是不断重启，你连问题出在哪里都不知道！

你可能会遇到：

•

系统更新后新内核崩溃，但不知道如何从旧内核启动

•

系统启动时显示"Out of memory"错误，无法完成启动

•

系统更新后显示"Unable to mount root fs on unknown-block(0,0)"

•

系统启动后进入维护模式，要求输入root密码

•

系统启动时显示文件系统损坏的traceback信息

•

系统在启动过程中不断重启，陷入重启循环

你尝试各种方法，但就是找不到问题的根源。老板问你："为什么系统启动不了？"你只能无奈地回答："更新后出问题了，但不知道具体原因..."这种"更新后启动失败，诊断无门"的恶性循环，是不是让你抓狂？

如果你也经历过这种"系统更新后启动失败无法诊断"的噩梦，那么今天FYC要告诉你一个好消息：Red Hat官方提供了6大经典实战案例！这些案例覆盖了从内核崩溃到文件系统损坏的所有常见场景，只要按照案例操作，就能快速解决问题！

第二段：解决方案概述

今天我们要聊的是Red Hat官方经典实战案例，这是RHEL系统启动故障诊断的精华总结。我们将从6大实战场景讲起，带你一步步学会如何处理内核崩溃、内存不足、文件系统损坏、维护模式等常见启动问题。

本文将为你带来：

•

🎯 案例1：备用内核启动：新内核崩溃怎么办？如何从旧内核启动？

•

🔧 案例2：大页配置错误：OOM无法启动怎么办？如何在不使用ISO的情况下修复？

•

✅ 案例3：initramfs缺失：更新后无法挂载根文件系统怎么办？

•

⚠️ 案例4：维护模式：系统启动后进入维护模式怎么办？

•

💡 案例5：文件系统修复：文件系统损坏怎么办？如何在救援模式下修复？

•

🚨 案例6：audit日志空间不足：系统在启动过程中关闭怎么办？

跟着FYC走，从此告别"系统更新后启动失败无法诊断"的时代！

第三段：5维度评分表

维度	评分	说明
难度等级	⭐⭐⭐⭐	需要深入理解启动流程和故障诊断方法
实用价值	⭐⭐⭐⭐⭐	解决系统更新后启动失败的关键问题
技术深度	⭐⭐⭐⭐	涉及内核、内存管理、文件系统、LVM等
可操作性	⭐⭐⭐⭐⭐	所有命令和诊断步骤都可以直接使用
紧急性	⭐⭐⭐⭐⭐	系统无法启动通常是最高优先级的故障，影响范围广

---

📚 正文：干货满满，但要"喂到嘴里"！

⚡ 一、案例1：新内核崩溃怎么办？从备用内核启动的完整指南

📋 问题场景

系统更新后安装了新内核，但新内核导致系统崩溃，无法启动。你需要从旧内核启动系统。

🎯 解决方案：临时从备用内核启动

步骤1：进入GRUB菜单

# 1. 系统启动时，会显示类似以下消息：# "Press any key to enter the menu#  Booting Red Hat Enterprise Linux (3.10.0-1062.4.1.el7.x86_64) in 3 seconds..."# 2. 在倒计时期间，按任意键进入GRUB菜单

步骤2：选择备用内核

# 1. 在GRUB菜单中，使用方向键选择之前的内核版本# 2. 高亮显示旧内核后，按Enter键启动# 3. 系统会使用旧内核启动

GRUB菜单示例：

Red Hat Enterprise Linux Server (3.10.0-1062.4.1.el7.x86_64)  ← 新内核（有问题）Red Hat Enterprise Linux Server (3.10.0-1062.1.1.el7.x86_64)  ← 旧内核（选择这个）Red Hat Enterprise Linux Server (3.10.0-957.el7.x86_64)        ← 更旧的内核

🔧 解决方案：永久设置默认内核

如果新内核持续有问题，可以永久设置默认内核：

参考文档：

•

How do I change the default kernel in GRUB that is loaded at startup?

📊 诊断步骤

# 1. 检查当前内核版本uname -r# 2. 检查yum日志，查看最近的内核更新grep kernel /var/log/yum.log | tail -20# 3. 检查GRUB配置中的默认内核# RHEL 6及以下：cat /boot/grub/grub.conf | grep default# RHEL 7+：cat /boot/grub2/grub.cfg | grep "menuentry"

💡 根本原因

•

运行 yum update可能安装新内核，新内核会成为默认内核

•

新内核可能与硬件或驱动不兼容，导致系统崩溃

•

Red Hat提供的内核会自动添加到启动加载器中，但仍可以启动之前安装的内核

⚠️ 预防措施

如果不想让 yum update更新或安装新内核，可以参考：

•

How do I exclude updating the kernel or other packages in RHEL 5/6 while updating system via yum?

---

🔧 二、案例2：大页配置错误导致OOM无法启动（不使用ISO修复）

📋 问题场景

系统启动时显示"Out of memory"错误，无法完成启动。通常是因为大页（hugepages）配置值超过了系统总内存。你需要在不使用ISO的情况下修复问题。

🎯 场景1：大页在内核命令行中设置

问题诊断：

# 1. 在GRUB菜单按'e'编辑启动项# 2. 查看内核命令行参数，发现：# hugepagesz=2M hugepages=6000# 系统总内存：10GiB# 计算：2M * 6000 = 12GiB > 10GiB（超过总内存！）

解决方案：

# 1. 启动系统，在GRUB菜单停止# 2. 按'e'编辑启动项# 3. 找到包含hugepages的行，删除hugepages相关参数#    删除：hugepagesz=2M hugepages=6000# 4. 按Ctrl+X继续启动# 5. 系统启动后，计算正确的大页数量并修改GRUB配置# 计算示例：如果系统有10GiB RAM，大页大小为2MiB# 大页数量不应超过4500（约8.78GiB）echo "2*4500/2^10" | bc -l# 输出：8.78906250000000000000# 修改GRUB配置，使用正确的大页数量grub2-mkconfig -o /etc/grub2.cfg

🎯 场景2：大页在配置文件中设置（RHEL 7）

解决方案：

# ======== Step 1: 绕过sysctl服务 ========# 1. 重启系统，在GRUB菜单停止# 2. 按'e'编辑启动项# 3. 找到以linux16或linuxefi开头的行# 4. 添加以下参数：systemd.mask=systemd-sysctl.service rd.systemd.unit=emergency.target systemd.mask=tuned.service# 5. 按Ctrl+X继续启动# 6. 系统会进入emergency模式（dracut shell）# ======== Step 2: 在emergency模式下修复配置 ======# 系统会显示：# [    2.906661] systemd[1]: Started Emergency Shell.# [  OK  ] Started Emergency Shell.# [    2.909506] systemd[1]: Reached target Emergency Mode.# [  OK  ] Reached target Emergency Mode.# Generating "/run/initramfs/rdsosreport.txt"# Entering emergency mode. Exit the shell to continue.# Type "journalctl" to view system logs.# :/# # 7. 查找包含nr_hugepages的文件grep -r nr_hugepages /etc/* -l# 8. 编辑包含大页配置的文件（使用vi）：# /etc/sysctl.conf# /etc/sysctl.d/*.conf# /usr/lib/sysctl.d/*.conf# /lib/sysctl.d/*.conf# /usr/local/lib/sysctl.d/*.conf# 9. 删除或注释大页配置行# 10. 退出dracut shell：exit# ====== Step 3: 系统启动后完成修复 ========# 11. 系统启动后，执行以下步骤：# 设置大页为0echo 0 > /proc/sys/vm/nr_hugepages# 修改配置文件，注释或删除错误的大页设置# 重建initramfsdracut -f# 12. 重启系统验证reboot

原理说明：

•

通过 rd.systemd.unit=emergency.target，系统会在initramfs阶段进入emergency模式，在应用sysctl之前停止

•

通过 systemd.mask=systemd-sysctl.service，告诉systemd在切换根后不要应用sysctl

•

通过 systemd.mask=tuned.service，屏蔽tuned服务，因为它会重新应用sysctl设置

🎯 场景2：大页在配置文件中设置（RHEL 8/9）

解决方案：

# 1. 重启系统，在GRUB菜单停止# 2. 按'e'编辑启动项# 3. 添加以下参数：systemd.mask=systemd-sysctl.service rd.systemd.mask=systemd-sysctl.service systemd.mask=tuned.service# 4. 按Ctrl+X继续启动# 5. 系统启动后，修复大页配置并重建initramfsdracut -f# 6. 重启系统验证reboot

💡 根本原因

•

大页配置值超过了系统总内存，导致系统在启动时内存不足（OOM）

•

大页在initramfs阶段或systemd启动时被应用，导致系统无法完成启动

---

✅ 三、案例3：更新后无法挂载根文件系统（initramfs缺失）

📋 问题场景

系统更新后无法启动，显示以下错误：

VFS: Cannot open root device XXX or unknown-block(0,0)Please append a correct "root=" boot option; here are the available partitions:Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

🎯 解决方案：7步完整修复流程

步骤1：从旧内核启动

# 1. 等待"Booting Red Hat Enterprise Linux Server in X seconds"倒计时# 2. 按任意键进入GRUB菜单# 3. 使用方向键选择旧内核，按Enter启动# 注意：如果没有旧内核可用，进入救援模式，然后chroot到根文件系统，继续步骤2

步骤2：检查/boot和/tmp空间

# 检查/boot和/tmp分区空间（RHEL 7/8检查/boot和/var/tmp）df -h /boot /tmp# 如果空间几乎满了，检查已安装的内核版本# RHEL 6/7：rpm --last -q kernel# RHEL 8/9：rpm --last -q kernel-core kernel# 移除最旧的内核以释放空间yum remove kernel-<oldest-version>

步骤3：移除并重新安装最新内核

# RHEL 6 & 7：yum remove kernel-<newversion>-<release>.<arch>yum install kernel-<newversion>-<release>.<arch># RHEL 8 & 9：yum remove kernel-core-<newversion>-<release>.<arch> kernel-<newversion>-<release>.<arch>yum install kernel-core-<newversion>-<release>.<arch> kernel-<newversion>-<release>.<arch># 警告：移除和重新安装内核时，建议至少保留一个已知良好的内核作为备用

步骤4：验证initramfs文件已创建

# 检查/boot目录ls -l /boot# 应该看到对应内核的initramfs文件：# initramfs-<kernel-version>.img

步骤5：检查GRUB配置中的initramfs声明

# RHEL 6及以下：cat /boot/grub/grub.conf | grep -A 5 "<kernel-version>"# RHEL 7（BIOS）：cat /boot/grub2/grub.cfg | grep -A 5 "<kernel-version>"# RHEL 7（UEFI）：cat /boot/efi/EFI/redhat/grub.cfg | grep -A 5 "<kernel-version>"# RHEL 8/9：cat /boot/loader/entries/<machine_id>-<kernel-version>-<release>.<arch>.conf

步骤6：手动重建initramfs（如果缺失）

# 如果initramfs文件未创建，手动重建dracut -f# 参考：How to rebuild the initial ramdisk image in Red Hat Enterprise Linux

步骤7：更新BLS配置（RHEL 8/9）

# 如果/boot/loader/entries/<machine_id>-<newversion>.conf文件未更新initramfs条目# 参考：How to generate BLS configuration files under /boot/loader/entries in Red Hat Enterprise Linux?

📊 诊断步骤

# 1. 从旧内核启动或进入救援模式# 2. 验证initrd/initramfs是否存在于/boot目录ls -lh /boot/initramfs-$(uname -r).img# 3. 验证initrd声明是否存在于以下文件：# RHEL 6及以下：/boot/grub/grub.conf# RHEL 7（BIOS）：/boot/grub2/grub.cfg# RHEL 7（UEFI）：/boot/efi/EFI/redhat/grub.cfg# RHEL 8/9：/boot/loader/entries/<machine_id>-<kernel-version>-<release>.<arch>.conf# 4. 使用df检查/boot和/tmp分区是否接近100%满df -h /boot /tmp

💡 根本原因

•

initramfs声明在启动加载器配置中缺失，或initramfs文件本身在 /boot目录中缺失

•

这可能是由于内核包安装不完整导致的，可能原因包括：

•

系统挂起/崩溃

•

/boot或 /tmp文件系统空间不足

•

检查initramfs中的第三方模块，有时第三方模块可能导致此类问题

---

⚠️ 四、案例4：系统启动后进入维护模式

📋 问题场景

系统启动后进入维护模式，显示以下消息：

Give the root password for maintenance (Or press Control-D to continue):

或者系统启动时显示VolumeGroup未找到的错误。

🎯 解决方案：5步修复流程

步骤1：提供root密码

# 在提示符处输入root密码Give the root password for maintenance (Or press Control-D to continue):      <-------- 在这里输入root密码

步骤2：重新挂载根文件系统为读写

# 重新挂载根文件系统为读写模式mount -o remount,rw /

步骤3：检查并修正/etc/fstab条目

# 检查LVM卷组和逻辑卷lvm lvs# 激活所有卷组lvm vgchange -ay# 尝试挂载所有fstab条目（详细模式）mount -a -v# 查看fstab内容cat /etc/fstab

步骤4：注释失败的挂载

# 根据mount -a -v的输出，找出失败的挂载# 在/etc/fstab中注释掉失败的条目（在行首添加#）# 示例：# /dev/mapper/vg-failed /mnt/failed ext4 defaults 0 0

步骤5：检查并设置默认target

# 检查系统默认targetsystemctl get-default# 输出应该是"multi-user.target"或"graphical.target"# 如果不是，设置默认targetsystemctl set-default multi-user.target# 或systemctl set-default graphical.target

📊 诊断步骤

# 在维护模式下，提供root密码后执行以下命令：# 1. 检查LVM逻辑卷lvm lvs# 2. 激活所有卷组lvm vgchange -ay# 3. 尝试挂载所有fstab条目mount -a -v# 4. 查看fstab内容cat /etc/fstab# 5. 比较lvm命令的输出与mount -a -v的输出和/etc/fstab中的实际条目

💡 根本原因

•

/etc/fstab文件中的无效条目

•

由于各种原因导致的 VolGroups失败

•

分配给启动的target不正确

---

💡 五、案例5：文件系统损坏（在救援模式下修复）

📋 问题场景

系统无法启动，需要修复操作系统依赖的文件系统（通常是 /或 /var）。或者根文件系统进入只读模式。

🎯 解决方案：8步完整修复流程

步骤1：从安装介质启动

# 1. 从二进制DVD或启动盘启动系统# 2. 使用与系统相同主版本的安装介质# 3. 如果可能，从access.redhat.com下载最新的次版本#    例如：使用RHEL 8.10而不是RHEL 8.0# RHEL 7/8/9/10：选择Troubleshooting → Rescue a Red Hat Enterprise Linux system# RHEL 6：选择Rescue installed system# RHEL 5：在提示符处输入"linux rescue"（不带引号）

步骤2：选择语言和键盘

# 根据系统提示，提供语言和键盘信息

步骤3：禁用网络

# 当提示启用系统上的网络设备时，选择：No

步骤4：跳过挂载

# 当提示时，选择：Skip

步骤5：初始化软件RAID（如果使用）

# 如果使用软件RAID，首先初始化RAID阵列mdadm --assemble --scan

步骤6：激活LVM卷（如果使用）

# 如果使用LVM，激活卷以便扫描lvm vgchange -ay# 输出示例：# 1 logical volume(s) in volume group "VolGroup00" now active

步骤7：修复文件系统

对于XFS文件系统：

# 在包含文件系统的设备上执行检查xfs_repair /dev/mapper/<vg>-<lv># 或xfs_repair /dev/<sd device># 或xfs_repair /dev/<md device># 注意：如果xfs_repair无法运行，可能需要重新创建日志# 可以通过运行 xfs_repair -L 来完成# 警告：请确保在尝试修复之前，对受影响文件系统上的数据有已知良好的备份

对于EXT文件系统：

# 在包含文件系统的设备上执行检查e2fsck -fvy /dev/mapper/<vg>-<lv># 或e2fsck -fvy /dev/<sd device># 或e2fsck -fvy /dev/<md device># 参数说明：# -f：强制检查，即使文件系统看起来干净# -v：详细模式# -y：自动回答"yes"到所有问题

步骤8：退出救援环境

# 退出救援环境并正常启动系统exit

📊 视频教程

参考Red Hat知识库视频：Repairing Filesystems in Rescue Mode. (7:11)

💡 根本原因

文件系统可能因多种原因而损坏，最显著的原因包括：

•

在 write()期间连接失败

•

硬件故障（间歇性硬件故障）

•

坏电缆/光纤

•

断电

•

网络连接故障

•

NIC抖动

•

软件/固件bug

•

不正确的文件系统调整操作，如逻辑卷调整大小

---

🚨 六、案例6：系统在启动过程中关闭（audit日志空间不足）

📋 问题场景

系统在完成启动过程之前关闭。尝试启动时出现以下情况：

•

系统启动过程中突然关闭

•

控制台没有显示任何错误消息

•

系统不断重启

🎯 解决方案：扩大/var/log/audit文件系统或清理旧audit日志

⚠️ 重要提示：

通常这个问题发生在CIS加固之后，因此我们建议在采取任何行动之前与您的安全团队讨论。

🔧 诊断步骤

步骤1：在GRUB菜单添加audit=0参数

# 1. 启动系统，在GRUB菜单停止# 2. 按'e'编辑启动项# 3. 在内核命令行添加：audit=0# 4. 按Ctrl+X继续启动

步骤2：检查audit日志占用的空间

# 检查audit日志占用的空间grep -e audit -e Mounted df# 输出示例：# Filesystem              1K-blocks     Used Available Use% Mounted on# /dev/mapper/rootvg-auditlv01       1038336  987208     51128  96% /var/log/audit# 在上面的示例中，audit日志存储在专用分区上，使用率96%

步骤3：检查audit配置

# 检查audit配置grep ^admin_space_left /etc/audit/auditd.conf# 输出示例：# admin_space_left = 50# admin_space_left_action = HALT# 在上面的示例中，audit配置为如果空间低于50MB则关闭系统# 从步骤1可以看出，当前可用空间为51128KB（约50MB），正好触发关闭

💡 根本原因

•

CIS加固要求如果 /var/log/audit空间不足，系统应该关闭，以避免丢失可能用于取证的audit日志

•

当这种情况发生时，系统会被关闭，但控制台上不会打印任何消息，这使得故障排除非常困难

•

BZ 2207869已在RHEL 9上提交，以增强此功能

🔧 解决方案选项

选项1：扩大/var/log/audit文件系统

# 1. 如果/var/log/audit在专用分区上，扩大该分区# 2. 如果/var/log/audit在根分区上，扩大根分区# 3. 调整文件系统大小resize2fs /dev/mapper/rootvg-auditlv01  # ext4xfs_growfs /dev/mapper/rootvg-auditlv01  # xfs

选项2：清理旧audit日志

# 1. 检查audit日志文件ls -lh /var/log/audit/# 2. 删除旧的audit日志文件（谨慎操作！）# 建议先备份tar -czf /tmp/audit_logs_backup.tar.gz /var/log/audit/# 3. 删除旧日志（例如：删除30天前的日志）find /var/log/audit/ -type f -mtime +30 -delete# 4. 或者使用audit日志轮转# 检查/etc/audit/auditd.conf中的max_log_file和num_logs设置

选项3：调整audit配置（与安全团队讨论后）

# 1. 编辑audit配置vi /etc/audit/auditd.conf# 2. 调整admin_space_left值（增加阈值）# admin_space_left = 100  # 从50MB增加到100MB# 3. 或者更改admin_space_left_action（与安全团队讨论）# admin_space_left_action = SUSPEND  # 暂停而不是关闭# 4. 重启audit服务systemctl restart auditd

---

🎁 写在结尾！

📋 价值总结

今天FYC为你带来了Red Hat官方6大经典实战案例的完整攻略：

✅ 案例1：备用内核启动：

•

新内核崩溃时，如何从旧内核临时启动

•

如何永久设置默认内核

•

如何预防内核自动更新

✅ 案例2：大页配置错误：

•

如何在不使用ISO的情况下修复大页配置错误

•

内核命令行和配置文件两种场景的处理方法

•

RHEL 7和RHEL 8/9的不同处理方式

✅ 案例3：initramfs缺失：

•

更新后无法挂载根文件系统的7步修复流程

•

如何检查/boot和/tmp空间

•

如何手动重建initramfs

✅ 案例4：维护模式：

•

系统启动后进入维护模式的5步修复流程

•

如何检查并修正/etc/fstab条目

•

如何激活LVM卷组

✅ 案例5：文件系统修复：

•

在救援模式下修复XFS和EXT文件系统的完整流程

•

如何初始化RAID和激活LVM

•

文件系统损坏的常见原因

✅ 案例6：audit日志空间不足：

•

系统在启动过程中关闭的诊断方法

•

如何扩大/var/log/audit文件系统

•

如何清理旧audit日志

掌握了这6大经典案例，你就能在系统更新后启动失败时快速定位问题并解决，确保业务连续性！

🎯 行动号召

觉得这篇文章还不够过瘾？想要看到更详细的故障诊断脚本、启动问题检查清单、以及更多真实案例吗？

👉 点击我后续的微信小程序【FYC的知识星球】，即可获取：

•

📚 启动故障诊断一键脚本（自动化诊断流程）

•

🔧 6大案例完整修复脚本（每个案例的自动化修复）

•

📊 启动问题检查清单（Checklist）

•

💡 更多启动失败案例解析（真实生产环境场景）

•

🎯 启动流程深度解析（从BIOS到systemd的完整流程）

FYC的使命：让每个运维工程师都能成为启动故障诊断专家！技术要硬核，文案要上头！🔥