㈠ 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，以免造成重大失誤。電腦
電腦