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

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

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

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

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

這里得謝天謝地yum命令的安裝卸載日志/var/log/yum.log，這個(gè)日志里清楚的記錄了installed和erased的所有軟件包，用rpm是不可能了，因?yàn)?70多個(gè)包的依賴關(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

手動(dòng)編輯一個(gè)倉庫源（真實(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，以防連接不了這些源而報(bào)錯(cuò)，雖然報(bào)錯(cuò)關(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

保險(xiǎn)起見，可以查看一下產(chǎn)生的日志文件。此時(shí)重啟（記得拿出光盤）應(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)這個(gè)命令根本不存在，這才發(fā)現(xiàn)原來lvm2軟件沒有安裝（難道是第2部分安裝少許出錯(cuò)？）。
這下容易多了，反正現(xiàn)在系統(tǒng)不借助rescue mode就可以起來，重新安裝軟件包，但是此時(shí)的整個(gè)文件系統(tǒng)是read only，有兩個(gè)辦法可以解決：

mount -o remount,rw /
重新掛載根分區(qū)為讀寫，vi /etc/fstab注釋掉掛載/u1的那條記錄，此時(shí)會(huì)正常啟動(dòng)，只是有一個(gè)文件系統(tǒng)沒有掛載，但可以正常安裝缺失的lvm2軟件，不妨多執(zhí)行幾遍2.2的安裝命令。然后手動(dòng)掛載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，確保沒有報(bào)錯(cuò)且已安裝lvm。

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

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

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

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

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

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

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