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考证

除了检查本机防火墙和云控制台安全组之外，可以通过 telnet 去连接

运行命令 tailf /var/log/messages

当linux服务启动失败的时候，系统会提示我们使用 journalctl -xe 命令来查询详细信息，定位服务不能启动的原因。

mod_evasive是Apache防御攻击的模块，有助于防止DoS、DDoS以及对Apache服务器的暴力攻击。它可以在攻击期间提供规避行动，并通过电子邮件和系统日志工具报告滥用行为。该模块的工作原理是创建一个IP地址和URI的内部动态表，并拒绝以下任何一个IP地址：

如果满足上述任何条件，则发送403响应并记录IP地址。

案例：某客户服务器因机房断电，导致多台设备无法进入 Linux *** 作系统，报错 XFS 文件系统损坏。如图：故障原因： 维护 Linux 服务器时会面临这样一种错误，即显示文件系统变成(Read Only System)，即 文件系统变成只读的方式，产生这一问题的原因可能有两种，一种是多机写入时同步机制出 现问题，另一种方式是单机写入时出现服务器掉电的情况 而本案例故障演员则为后者：单机写入时出现服务器掉电的情况。名称解析: XFS 文件系统:             文件系统的定义：                        文件系统是 *** 作系统用于明确存储设备（常见的是磁盘，也有基于 NAND Flash 的固态硬盘）或分区上的文件的方法和数据结构；即在存储设备上组织文件的方法。            xfs 文件系统：                                是一个日志型文件系统日志文件系统？加一个日志来记录文件系统的更改，即使在断电或者是 *** 作系 统崩溃的情况下也能保证文件系统一致性怎么保持的？要向磁盘写数据的时候，肯定要改变元数据，日志就要在这之前记录要怎么去 改元数据的，当发生异常掉电或者文件系统崩溃后，进行修复时会检查文件系统的一致性， 当出现不一致时，可通过它来恢复。故障处理方法: 第一步：使用#lsblk 查找挂载路径，用#umount 将其卸载；确保分区处于 umount 状态 (xfs_check /dev/sdb(盘符)echo $?返回 0 表示正常)，进行下一步；第二步：检测文件系统是否损坏：执行 xfs_repair -n，检查文件系统是否损坏。第三步：修复文件系统： xfs_repair /dev/sdb 以本案例为例。 注: XFS 文件系统在异常断电后发生文件系统报错概率很高。若仅仅因为断电导致文件系统 报错，通常是可以通过命令修复的。执行以上 repair *** 作不会对数据产生进一步损坏风险， 如发生修复失败是由于文件系统损坏严重，而不是此 *** 作导致第四步：强制修复（会造成文件丢失,需要与客户说明数据安全&得到客户允许下才能 *** 作。） 先执行 xfs_repair -L /dev/sdb(清空日志，会丢失文件)，再执行 xfs_repair /dev/sdb，再执行 xfs_check /dev/sdb 检查文件系统是否修复成功说明：-L 是修复 xfs 文件系统的最后手段，慎重选择，它会清空日志，会丢失用户数据和文 件。备注：在执行 xfs_repair *** 作前，最好使用 xfs_metadump 工具保存元数据，一旦修复失败， 最起码可以恢复到修复之前的状态 注:仅用作经验分享。参考文献： https://blog.csdn.net/yuanfang_way/article/details/78700089 https://www.cnblogs.com/yuzhaoxin/p/4083582.html

---