㈠ 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考证
㈡ 服务器u盘rescue启动
服务器u盘rescue启动(服务器用u盘启动)小编在运维的工作中，经常能碰到各种各样的坑，下面是小编曾经遇到过的一个问题，希望能给各位一点参考。
某一天，一个同事向我求助，说某个项目的数据库无法通过集群的方式进行连接（数据库是公司自己研发的，类似Mysql）。
当日解决步骤：
1. 首先批量查看了集群的磁盘空间使用情况，发现磁盘空间正常，再检查电脑集群的数据节点服务及其他服务，均正常运行。
2. 再次检查管理服务器配置文件，发现服务器集群一共是node1-node28，而scmt批量查看的末节点只到了node24，即重新修改批量命令，发现node28的数据节点无法启动。
3. 查看node28的磁盘空间发现，/dev/sdb满，使用 -sh *的方式排查发现了脏数据表，将其删除之后，想通过lsof的方式释放进程，结果发现服务器没有lsof的命令。
重点来了！！本来正常的处理方式应该是下一个rpm包安装lsof命令，或者是通过暂时关闭数据节点的方式释放deleted进程，但偏偏选择了从其他集群拷贝lsof安装包的方式。
拷贝步骤（错误示范）：
1. 进入顺德公安其他服务器下面也没发现lsof的包，想着说只能通过从其他地方的服务器将/usr/bin/lsof以及安装文件（rpm -q /usr/bin/lsof）拷贝过来。
2. 当scp完成之后，修改权限，执行lsof命令发现报错，缺少libc.so.6下面的某个动态库的文件，这时候为了赶时间（下午要演示），没想这么多，就把centos6.7的libc.so.6文件拷到了centos6.2的/lib64/下，整台服务器直接断开远程连接。
到这里，各位应该知道原因了吧，系统版本不同，库文件内容也不相同。
挽救思路：
通过文献查到了libc.so.6文件的真正含义，是整个服务器的动态库环境，几乎所有的命令都是通过搭载libc.so.6来完成的，而幸运的是，libc.so.6是一个软连接文件，也就是说，能通过相同版本的centos进入救援模式，将软连接的源文件（libc-2.1.2.so）重新移植电脑到lib64目录下。
最后解决流程：
1. 查看node1系统版本为centos6.7，天真地认为node1-node28都是centos6.7，结果后来才发现为centos6.2.。。。
2. 将centos6.2的iso文件下载，并通过ultraiso软件写入U盘作为启动盘。
3. 修改服务器bios启动，将U盘作为第一启动项启动，进入RESCUE模式，在这里需要注意的是，centos6.2会让你选择initrd.img的位置，需要在hardisk里面选择/dev/sdx（U盘），然后等待片刻即可。
4. 进入rescue模式之后，找到原系统的位置/mnt/sysimages/，输入
cp /lib64/libc-2.1.2.so /mnt/sysimages/lib64/libc-2.1.2.socp /lib64/libc.so.6 /mnt/sysimages/lib64/libc.so.6可能会遇到/mnt/sysimages read-only的报错，这时候输入
mount -o remount rw /mnt/sysimageschroot /mnt/sysimages/ 即进入原系统测试，测试方式可以是ls,cp等命令。当时花了一个下午把系统恢复，所幸没造成什么影响，在这里要提醒各位，在生产环境进行所有操作的时候一定要谨慎谨慎再谨慎，能不用root就不用root，以免造成重大失误。电脑
电脑