摘要：于是檢查時發(fā)現(xiàn)，拼寫錯誤，應(yīng)為。第個問題，是真真切切錯誤卸載重要軟件包，導(dǎo)致系統(tǒng)崩潰，修復(fù)系統(tǒng)的方法自然也就是利用原鏡像在下把該裝的都裝回去，前提是日志存在，萬幸沒有執(zhí)行過。

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

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

這無疑要使用LiveCD修復(fù)系統(tǒng)了，參考Ultimate method to install package from linux rescue mode或Using Rescue Mode to Fix..Problems。因?yàn)橹莱鰡栴}前做過什么操作，下面直接上解決問題的過程。

再次重啟就自動進(jìn)入安裝界面，我們當(dāng)然選擇rescue mode：

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

這里得謝天謝地yum命令的安裝卸載日志/var/log/yum.log，這個日志里清楚的記錄了installed和erased的所有軟件包，用rpm是不可能了，因?yàn)?70多個包的依賴關(guān)系難以解決，只能通過yum方式，而由于rescue模式?jīng)]有配置網(wǎng)絡(luò)，因此只能使用本地鏡像源。

在rescue系統(tǒng)下掛載光驅(qū)到待修復(fù)系統(tǒng)中的/media目錄
bash-4.1# mount /dev/cdrom /mnt/sysimage/media

chroot進(jìn)入待修復(fù)系統(tǒng)
bash-4.1# chroot /mnt/sysimage

手動編輯一個倉庫源（真實(shí)待修復(fù)的系統(tǒng)）
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，以防連接不了這些源而報錯，雖然報錯關(guān)系不大。
獲取被依賴erased掉的軟件列表

你可以將yum.log中多余的部分去掉，篩選出應(yīng)該重新安裝的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

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

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

顯然，文件系統(tǒng)損壞。根據(jù)提示輸入root密碼后可以進(jìn)入到shell中，網(wǎng)上有辦法說執(zhí)行fsck命令來修復(fù)分區(qū)，又說且不能是mounted狀態(tài)，但無論我怎么去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 

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

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

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

這下問題總是解決了，避免了刪除系統(tǒng)的災(zāi)難（測試環(huán)境）。

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

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

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

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

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

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