記一次錯誤卸載軟件包致使Linux系統崩潰的修復解決過程

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

1. Kernel panic - not syncing: Attempted to kill init!

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

2. 系統啓動加載條完成後，一直hang住不動

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

2.1 將系統DVD安裝鏡像加載到光驅

再次重啓就自動進入安裝界面，咱們固然選擇rescue mode：

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

2.2 安裝缺失的軟件包

這裏得謝天謝地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

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

3. An error occurred during the file system check

顯然，文件系統損壞。根據提示輸入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 <device>

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

1. mount -o remount,rw /
   從新掛載根分區爲讀寫，vi /etc/fstab註釋掉掛載/u1的那條記錄，此時會正常啓動，只是有一個文件系統沒有掛載，但能夠正常安裝缺失的lvm2軟件，不妨多執行幾遍2.2的安裝命令。而後手動掛載mount /dev/mapper/vg_fusion_lv_u1 /u1應該就沒問題了。記得改回/etc/fstab。
2. 與2.2步驟相似，進入rescue mode→chroot，從新執行awk '{print "yum install -y ",$5}' /var/log/yum.log.bak |sh > /root/yum_install.log，確保沒有報錯且已安裝lvm。

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

4. 總結

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

• 第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/