CentOS 7开机卡死不动，到底是什么原因造成的？

初步诊断：观察开机卡滞点

当遇到 centos 7 开机死机时，首要任务不是立即进行复杂操作，而是仔细观察屏幕上最后显示的信息，这些信息是定位问题的第一线索。

1. GRUB 引导阶段：如果系统在显示 GRUB 引导菜单之前就卡住或黑屏，问题可能出在硬件（如硬盘、主板）或 BIOS/UEFI 设置上，可以尝试检查 BIOS 中的启动顺序，或移除不必要的硬件（如新增的 USB 设备）。
2. 内核加载阶段：如果能看到 CentOS 7 的启动进度条，但卡在某个位置，通常意味着内核或其初始化进程（systemd）遇到了问题，屏幕下方可能会显示一些加载服务的信息，卡在 “Starting SELinux…” 可能与文件系统标签有关；卡在 “Starting Network…” 则可能与网络配置或驱动有关。
3. 内核恐慌：如果屏幕上出现大量滚动代码，并以 “Kernel Panic” 这通常是内核遇到了无法恢复的致命错误，可能由硬件故障、不兼容的内核模块或系统文件损坏引起。

进入救援模式：故障排查的第一步

由于系统无法正常启动,我们需要进入一个特殊的维护环境来进行修复，CentOS 7 提供了“紧急模式”和“救援模式”。

1. 重启服务器：在启动时，当看到 GRUB 引导菜单出现时，立即按下键盘上的 e 键，进入编辑界面。
2. 编辑启动参数：使用方向键找到以 linux16 或 linuxefi 开头的行，移动光标到该行的末尾，添加以下参数之一：
   • systemd.unit=rescue.target 或 single：进入单用户/救援模式，该模式会挂载根文件系统（通常为只读）并提供一个基本的 shell。
   • systemd.unit=emergency.target：进入紧急模式，这是一个比救援模式更底层的模式，可能不会挂载任何文件系统。
3. 启动系统：按下 Ctrl + X 组合键，系统将使用修改后的参数启动。

进入救援模式后,您将获得一个 root shell，这是进行后续诊断和修复的起点。

深入分析：日志是关键

在救援模式下,系统日志是定位问题的核心工具，systemd 使用 journalctl 来管理日志。

• 查看本次启动的错误日志：执行以下命令，可以查看自系统启动以来的所有优先级为错误（error）及以上的日志。

  journalctl -b -p err

  -b 表示仅显示本次启动的日志，-p err 表示按优先级过滤。

  

• 查看详细的错误信息：如果上述命令输出不够详细，可以使用 -xe 参数获取更完整的上下文信息。

  journalctl -xe

通过仔细分析日志中的错误信息,往往可以直接定位到导致 centos 7 开机死机的元凶，例如某个服务启动失败、文件系统权限错误等。

常见原因与解决方案

结合日志分析,我们可以针对性地解决一些常见问题。

症状表现	可能原因	排查思路
卡在文件系统检查	非正常关机导致文件系统不一致	在救援模式下，对根分区或其他分区运行 fsck 命令进行修复。fsck -y /dev/sda1。
内核恐慌	新安装的内核、硬件驱动不兼容或硬件故障	在 GRUB 菜单中，选择一个旧版本的内核启动，如果能正常启动，说明是新内核的问题，可以卸载新内核或检查新硬件的驱动。
卡在某个服务启动	该服务配置错误或依赖资源不可用	使用 systemctl --failed 命令查看失败的服务，可以暂时禁用该服务（systemctl disable service_name）看是否能启动，然后检查其配置文件。
首次启动后长时间卡住	SELinux 上下文重构	如果系统经历了强制关机或文件系统修复，SELinux 可能会在下次启动时对所有文件重新打标签，这个过程非常耗时，耐心等待，或检查 /var/log/audit/audit.log 确认是否在进行 autorelabel。
黑屏，但系统仍在运行	显卡驱动问题	尝试进入救援模式，检查或重新安装显卡驱动，或者，在 GRUB 启动参数中添加 nomodeset，临时禁用内核模式设置，以基本图形模式启动。

文件系统修复示例：
假设日志提示根分区 存在错误，在救援模式下，根分区可能已经被挂载为 /sysroot。

# 确保文件系统未被以读写方式挂载
mount | grep "on /sysroot"
# 如果是只读挂载，直接运行 fsck
fsck -y /dev/mapper/centos-root
# 如果没有挂载，直接运行 fsck
fsck -y /dev/mapper/centos-root
# 修复完成后，重启系统
reboot

预防胜于治疗

解决 centos 7 开机死机问题后，更重要的是建立预防措施，避免问题再次发生。

• 规范关机：始终使用 shutdown 或 reboot 命令正常关闭系统，避免强制断电。
• 定期更新：保持系统内核和软件包为最新版本，以修复已知的漏洞和 bug。
• 做好备份：定期备份重要数据和系统配置，这是应对灾难性故障的最后防线。
• 谨慎操作：在进行内核升级、修改关键系统文件或安装新硬件驱动前，做好回滚计划。

---

相关问答 FAQs

Q1: 如果系统连 GRUB 引导菜单都看不到，一开机就黑屏怎么办？
A1: 这种情况通常问题更为底层，指向硬件或 BIOS/UEFI，请按以下步骤排查：

1. 检查显示器连接：确保显示器电源和信号线连接正常。
2. 进入 BIOS/UEFI 设置：重启电脑，按下特定键（如 Del, F2, F10, Esc）进入 BIOS/UEFI，检查是否能正常显示，如果这里也黑屏，很可能是主板、显卡或内存条等硬件故障。
3. 重置 BIOS/UEFI：在 BIOS 设置中，找到 “Load Optimized Defaults” 或类似选项，加载默认设置，然后保存退出。
4. 硬件最小化：断开所有非必要的外部设备（USB 硬盘、U盘、打印机等），并尝试移除主板上的扩展卡（如独立显卡、声卡），只保留 CPU、一根内存条和电源，看是否能点亮屏幕，如果能，再逐一添加硬件，找出故障部件。

Q2: 系统每次启动都卡在 “A start job is running for /dev/mapper/centos-swap” 处，很长时间才动一下，如何解决？
A2: 这个问题通常与交换分区有关，系统在尝试激活 swap 分区时遇到了困难。

1. 进入救援模式：按照前述方法进入救援模式。
2. 检查 swap 分区：执行 swapon -s 或 free -h 查看当前 swap 状态，执行 lsblk -f 查看 swap 分区的 UUID 和类型。
3. 关闭 swap：执行 swapoff -a 关闭所有 swap。
4. 重建 swap：很可能 swap 分区的文件系统签名已损坏，使用 mkswap 命令重新格式化 swap 分区，如果 swap 分区是 /dev/mapper/centos-swap，则执行：

   mkswap /dev/mapper/centos-swap

5. 重新激活并更新 fstab：执行 swapon -a 重新激活 swap，然后检查 /etc/fstab 文件，确保 swap 分区的条目 UUID 是正确的（mkswap 命令执行后会输出新的 UUID，可以复制过来替换旧的）。
6. 重启系统：执行 reboot 重启，问题通常能得到解决。