Linux启动故障处理

【摘要】

当Linux系统出现故障无法正常启动系统时，Linux准备了单用户模式、救援模式等方式可以让我们有效的处理这类问题。本文简单分享一个利用救援模式解决Redhat系统无法启动的案例。

【正文】

一、   问题背景

1)    问题描述

一台部署了RHEL 7.2的物理服务器，突发死机故障，在尝试重启时，发现服务器无法正常进入 *** 作系统，直接进入emergency mode。本文主要分享 *** 作系统启动异常的问题排查过程。（服务器死机据后续日志分析，确定为内核的bug所致，本文不进行累述）

2)   故障现象

系统启动后，提示无法找到/dev/mapper/rhel-root，并直接进入emergency mode。

二、   排查思路

1)    收集系统启动异常的相关提示信息，获取到问题关键点：

Warning:/dev/rhel/root does not exist

初步定为配置文件问题或者逻辑卷root本身问题；

2)    尝试在应急模式下检查逻辑卷状态，发现当前情况并不稳定，常用命令无法使用、显示多为乱码；

3)    尝试进入单用户模式，发现情况和应急模式一样；

Redhat 7.2进入单用户模式：

1、开机启动至内核选择界面，选择第一项，按e进行编辑

2、定位到linux16这一行，找到ro，修改其为rw init=/sysroot/bin/sh

3、按ctrl+X启动至单用户模式

4)    利用系统安装光盘，进入Linux救援模式，进行排查。

Redhat 7.2救援模式启动方法：

1、把光盘加入光驱，然后启动，以光盘进行引导，选择救援模式（中间具体的步骤不再细说）

2、文件系统挂载到/mnt/sysimage目录下，这时切换到此目录下使用chroot /mnt/sysimage这条命令即可

5)    在救援模式下，首先查看服务器lv的情况，发现所有lv

status均为未激活状态。

查看lv

#Lvdisplay

修改lv

#vgchange -a y /dev/docker/root

6)    在尝试修改root的lv status时，发现root所在的vg名和启动时所指定的vg名不一致，基本确定问题点；

7)    修复

l  编辑文件/etc/default/grub

l  修改此文件中GRUB_CMDLINE_LINUX一行中rd.lvm.lv为合适的值

l  再执行以下命令重做grub ：

n UEFI: grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

n  非UEFI：grub2-mkconfig -o /boot/grub2/grub.cfg

l  查看文件grub.cfg中是否修改为rd.lvm.lv=rhel/root

l  修改/etc/grub2.cfg中root=后接的lv路径改为实际的路径。

8)    系统启动后，通过history日志，确定为该系统业务部署时，使用了vgrename命令修改了vg名。

三、   总结

对于Linux的问题处理，需要对Linux的运行原理有所理解，这此前提下才能根据有限的提示信息判断问题方向、确定排查范围、找到解决方法。同时，提醒各位初学linux的同事么，在进行linux的一些 *** 作时，需要充分考虑这些 *** 作可能造成的影响，避免类似上述的问题发生。

转自 嘉为教育-rhce认证_rhce培训_linux培训_linux认证_linux考证

如果问题能够再现，那么问题已经解决 80% 了。对于 *** 作系统核心而言，如果有问题的再现方法，那么可以说是已经解决 99% 了。经常遇到的问题是系统可以正常运行一段时间，然后死机。如果不好再现问题，那么只有根据死机现场遗留的东西来进行分析了。

如果系统没有死干净，比如磁盘中断和文件系统是好的，那么也许能有日志信息保留在文件中，不过这样的好运气我是从来没有遇到过的。如果键盘中断还能响应 (按下Num Lock，可以看见键盘小灯亮灭)，那么运气就算是足够好了，这时可以祭出 sysrq 大法，同时按下 Alt-Sysrq-T 获得进程系统堆栈信息，按下 Alt-Sysrq-M 获得内存分配信息，按下 Alt-Sysrq-W 获得当前寄存器信息。

linux/Documentation/sysrq.txt。另外，最好关闭终端的自动 blank 功能，这样系统死的时候至少能从屏幕上看到一些信息。设置方法是：

# echo 1 >/proc/sys/kernel/sysrq

# setterm -blank

这两个设置最好加到系统启动脚本中 (比如 /etc/rc.d/rc.local)，保证每次启动都能得到运行。

如果很不幸，键盘也死悄悄了，(更为不幸的是，这种情况很常见)，那么也不是只有等死一个办法，这时可以用串口终端 (serial console)将系统信息发送

到另一台系统上，这样可以通过对这些信息分析来定位问题。设置方法如下：

准备工作

1. 一台被监视的服务器，一台进行监视工作的PC。

2. 一根串口直连线。

配置

1. 在服务器上，加入一个新的 grub 项目，增加核心参数 "console=ttyS0 console=tty1"，如：

kernel /boot/vmlinuz-2.4.21-9.30AXsmp ro root=LABEL=/1 console=ttyS0

console=tty1

2. 在服务器上，修改 /etc/sysconfig/syslog，加入 klogd 选项 "-c 7"，保证更多内核信息得到输出。如：

KLOGD_OPTIONS="-x -c 7"

3. 重新启动服务器

4. 用串口直连线连接两台机器，测试：

1) 在PC上运行 "cat /dev/ttyS0"，在服务器上运行 "echo hi >/dev/ttyS0"，看在 PC 上是否有 "hi" 输出。

2) 在PC上运行 "cat /dev/ttyS0"，在服务器上运行 "echo w >/proc/sysrq-trigger"，看 PC 上是否有相应内核信息输出。

3) 在PC上运行 "cat /dev/ttyS0"，在服务器上运行 "modprobe loop"，看 PC 上是否有相应内核信息输出。

5. 如果测试通过，那么在 PC 上运行:cat /dev/ttyS0 | tee /tmp/result

另外，也可以用 Windows 超级终端获得串口信息。

that’s it.

此外，一些核心支持 LKCD, netdump 等调试功能，也可以一试。

剩下的，就只有靠经验和运气了，一般造成 Linux 系统死机的原因有：

系统硬件问题 (SCSI 卡，主板，RAID 卡，网卡，硬盘...)

外围硬件问题 (终端切换器，网络...)

软件问题

驱动 bug (去找更新的驱动试试)

核心系统 bug (去 LKML 上看看，或换个核心试试)

系统设置

因为 Linux 广泛用于生产环境，所以每一次宕机都会引起相当大的损失。它 Uptime 达到上百天也许你习以为常，但是只要 Down 十几秒，就会立即急的满头大汗。真的很难以想象证交所宕机会怎么样，也许全国股民会闹翻天。所以我们需要一些小技巧来查找死机的原因，从而避免死机或者内核崩溃。（话说 windows 天天蓝屏也没感觉呀 ：-o 难道已经麻木了 ：oops： ） 请注意：以下方法可能不适用于 Server，因为桌面环境和 Server 还是有很大区别的。 X Crash 事实上 Linux 内核很少出错，平常我们所遇到的“死机”都是 X 无响应造成的错觉。那 X 没响应了应该怎么处理呢？ 通常套路是 Ctrl + Alt +F7 （F8） 切换到某个 tty，然后用 root 登陆，执行 top 查看吃资源最多的程序，然后使用 pkill/kill/killall 等命令杀死该程序。或使用组合键 Ctrl + Alt + Backspace重启 X （黑日白月注：这个快捷键组合在最新的 Ubuntu 和 Fedora 中关闭）。 如果偶遇切换 tty 失败或者没响应，可以试着使用 SSH 登陆此电脑，然后再杀死程序。也许只是 X 不响应，而内核和 SSH daemon 仍然工作，故此可以实施此法。 arch 配置 SSH daemon 万一X 不给力，各种方法试了无效，又没有办法通过 SSH 登陆到此 pc，那怎么办呢？别着急，我们还有万能的 “reisub” 大法。不过在启用前先要激活内核 sysrq 功能 （via） 。系统启动时执行：echo “1” >/proc/sys/Kernel/sysrq 或者修改 /etc/sysctl.conf 文件，设置 Kernel.sysrq = 1。系统异常时依次按下 Alt+sysrq+{reisub} ，然后系统会自动重启。（有关 sysrq 请看：Linux 死机了怎么办？） 不建议长按 Power 按键强制关机，有可能损坏硬件或者丢失数据，甚至导致磁盘坏道！ X 崩溃而内核完好 常见的症状有：程序无响应，花屏，鼠标移动指针无动作，键盘输入没有识别等。但后台的音乐可以正常播放，或者键盘 Caps Lock/Num Lock/Scroll Lock 按键按后对应 LED 可以正常亮灭。遇到此种情况可以使用上述方法重启 X 或者电脑即可恢复正常。 Application Crash 这个比较常见，但是也是相当难解决的。因为 Linux 上的应用软件大部分都是开源的，所以可能没有超高的稳定性。也许由于库的缺少或者版本错误，或者代码的 Bug，都有可能导致程序出现异常。 一般遇到这种问题，建议检查配置文件是否正确，对配置文件的错误修改可能导致程序的运行失败。如果您确信配置文件没有错误但是程序仍然异常，可以尝试把配置文件删除（注意备份！），然后再次打开软件尝试。

---