摘要：于是檢查時發現，拼寫錯誤，應為。第個問題，是真真切切錯誤卸載重要軟件包，導致系統崩潰，修復系統的方法自然也就是利用原鏡像在下把該裝的都裝回去，前提是日志存在，萬幸沒有執行過。

首先問題產生的緣由很簡單，是我一同事在安裝oracle一套軟件時，按照要求需要binutils軟件包的32位版本，然而在Oracle Linux已經裝有64位，按理說是可以安裝i686的，我猜應該是32位的版本低于這個已有的64位所以導致沖突而安裝失敗，因此同事就用yum remove binutils，這個命令也奇葩，由于是root權限導致依賴于它的200多個軟件包也被卸載，最終導致網絡斷開，系統崩潰，在vSphere虛擬機上重新啟動發現再也起不來。下面看問題：

這個錯誤時在重新啟動Oracle Linux一開始就出現，查閱的相關資料得知Kernel panic問題一般是由驅動模塊終端處理終端問題導致的（不懂。。。），一開始我以為是驅動程序依賴于binutils導致被卸載，因此第一反應是想辦法把缺失的軟件裝回去。實際上，是由于安全訪問控制模塊selinux的問題，參考類似問題。于是檢查vi /etc/selinux/config時發現SELINUX=disables，拼寫錯誤，應為disabled。
當再次啟動沒再出現該錯誤時，我高興的認為原來這么簡單就幫同事解決了，事實這根本還沒到200多個軟件包缺失而導致系統崩潰那一步。

這無疑要使用LiveCD修復系統了，參考Ultimate method to install package from linux rescue mode或Using Rescue Mode to Fix..Problems。因為知道出問題前做過什么操作，下面直接上解決問題的過程。

再次重啟就自動進入安裝界面，我們當然選擇rescue mode：

一路按照提示確定（可以不配置network，這里就不貼圖了，很簡單），最終會提供給用戶一個shell終端，對應的是從DVD光驅加載進來的系統，執行chroot /mnt/sysimage才會進入到原損壞的Linux系統，還好yum和rpm命令還可以使用，悲劇的是我并不知道yum remove命令卸載了哪些軟件包。

這里得謝天謝地yum命令的安裝卸載日志/var/log/yum.log，這個日志里清楚的記錄了installed和erased的所有軟件包，用rpm是不可能了，因為270多個包的依賴關系難以解決，只能通過yum方式，而由于rescue模式沒有配置網絡，因此只能使用本地鏡像源。

在rescue系統下掛載光驅到待修復系統中的/media目錄
bash-4.1# mount /dev/cdrom /mnt/sysimage/media

chroot進入待修復系統
bash-4.1# chroot /mnt/sysimage

手動編輯一個倉庫源（真實待修復的系統）
sh-4.1# cd /etc/yum.repos.d/ && vi Oracle-Media.repo
[DVD-media]
name=oracle-$releasever - Media
baseurl=file:///media
gpgcheck=0
enabled=1

建議只留Oracle-Media.repo文件，其他的.repo文件都mv成.bak，以防連接不了這些源而報錯，雖然報錯關系不大。
獲取被依賴erased掉的軟件列表

你可以將yum.log中多余的部分去掉，篩選出應該重新安裝的packages：
sh-4.1# cp /var/log/yum.log{,.bak}
sh-4.1# less /var/log/yum.log.bak
Oct 29 20:17:34 Erased: gcc-c++
Oct 29 20:18:44 Erased: gcc
Oct 29 20:22:59 Erased: xorg-x11-drivers
...
Oct 29 20:24:46 Erased: iputils
Oct 29 20:24:46 Erased: udev
Oct 29 20:24:46 Erased: initscripts
Oct 29 20:24:46 Erased: hwdata
Oct 29 20:24:46 Erased: module-init-tools
Oct 29 20:24:48 Erased: binutils

下面一條命令應該要徹底解決問題了
sh-4.1# awk "{print "yum install -y ",$5}" /var/log/yum.log.bak |sh > /root/yum_install.log

保險起見，可以查看一下產生的日志文件。此時重啟（記得拿出光盤）應該是修復問題了。但我遇見的問題還沒完。

顯然，文件系統損壞。根據提示輸入root密碼后可以進入到shell中，網上有辦法說執行fsck命令來修復分區，又說且不能是mounted狀態，但無論我怎么去fsck.ext4 /dev/mapper/vg_fusion_lv_u1，提示

WARNING!!!  The filesystem is mounted.   if you continue you ***WILL*** 
cause ***SEVERE*** filesystem damage`

Do you really want to continue (y/n)? yes

fsck.ext4: No such file or directory while trying to open /dev/mapper/vg_fusion_lv_u1

The superblock could not be read or does not describe a correct ext2 
filesystem.  If the device is valid and it really contains an ext2 
filesystem (and not swap or ufs or something else), then the superblock 
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 

聽起來好像還挺嚴重的，我之前猜想的是不是反復的開關電源來重啟導致lvm文件系統corrupt，但事實我發現/dev/mapper/vg_fusion_lv_u1不存在，但lv_fusion_lv_root卻完好，執行lvdisplay發現這個命令根本不存在，這才發現原來lvm2軟件沒有安裝（難道是第2部分安裝少許出錯？）。
這下容易多了，反正現在系統不借助rescue mode就可以起來，重新安裝軟件包，但是此時的整個文件系統是read only，有兩個辦法可以解決：

mount -o remount,rw /
重新掛載根分區為讀寫，vi /etc/fstab注釋掉掛載/u1的那條記錄，此時會正常啟動，只是有一個文件系統沒有掛載，但可以正常安裝缺失的lvm2軟件，不妨多執行幾遍2.2的安裝命令。然后手動掛載mount /dev/mapper/vg_fusion_lv_u1 /u1應該就沒問題了。記得改回/etc/fstab。

與2.2步驟類似，進入rescue mode→chroot，重新執行awk "{print "yum install -y ",$5}" /var/log/yum.log.bak |sh > /root/yum_install.log，確保沒有報錯且已安裝lvm。

這下問題總是解決了，避免了刪除系統的災難（測試環境）。

回頭去看這三個問題，其他它們是各自獨立的

第1個問題，是由于設置selinux有人拼寫錯誤，哪怕沒做后續的任何操作，重啟系統就會啟動不了，是早已存在到目前才發現。也有人說遇見過同樣的Kernel panic錯誤但嘗試各種辦法都難以解決的，這就看具體問題具體分析了。

第2個問題，是真真切切錯誤卸載重要軟件包，導致系統崩潰，修復系統的方法自然也就是利用原鏡像在rescue mode下把該裝的都裝回去，前提是yum.log日志存在，萬幸沒有執行過yum clean all。

第3個問，題實際文件系統并沒有損壞，還是lvm2缺失，但是此處必須小心，免得SEVERE filesystem damage，那么修復過程就沒意義了。

以后處理其他系統故障時也可使用類似的方法修復，Redhat、CentOS、OracleLinux、Ubuntu等都適用。

原文鏈接地址：http://seanlook.com/2014/11/03/one-troubleshooting-for-centos-corrupt/