軟件包類故障在Linux系統中比較常見，例如：需要編譯源碼包程序時系統中沒有安裝gcc編譯工具，安裝RPM軟件包時有未解決的依賴關系，程序庫文件或頭文件的安裝路徑不正確等，軟件包類故障產生的原因非常多，通常只需要根據相應的錯誤提示信息，確認安裝好編譯環境，找到所需要的依賴軟件包，糾正庫文件或對應的頭文件路徑即可。
下面主要介紹rpm數據庫損壞和找不到“.so”文件的故障解決方法。
1、rpm數據庫損壞
rpm數據庫損壞的故障並不多見，出現該故障的原因一般是由於經常強制關機，誤刪除運行中的文件，強制替換一些rpm包文件等。rpm數據庫損壞後，在使用rpm工具查詢或安裝軟件時，將無法正常運行。
eg：模擬rpm數據庫損壞故障，並驗證錯誤信息。
RPM作為Linux系統中的軟件包管理機制，維護著一份獨立的文件數據庫，用於存儲在系統中已安裝的rpm包信息。當數據文件損壞時，將導致不能使用rpm命令或yum命令來查詢、安裝、升級、刪除rpm類軟件包。解決該故障一般只需要執行"rpm --rebuilddb"命令，重建數據庫即可。
Ps:本系統httpd包已經安裝！
eg：清除損壞的rpm數據文件，並重建數據庫信息。
看圖提示可以了吧！
2、缺少*.so類文件
在通過源碼編譯的方式安裝軟件包時，程序的可執行文件、函數庫、配置文件等一般會默認安裝到"/usr/local'目錄下的相應位置(前提是你的程序安裝在"/usr/local"下喔，比如：/usr/local/mysql/bin、/usr/local/mysql/lib等)，以便與系統程序的相關目錄區別開來。
*.so文件就如同Windows系統中的.dll文件一樣，是庫文件。一個程序的正常安裝和運行需要特定庫文件的支持。由於類似於"/usr/local/mysql/lib"的目錄並不包括在Linux系統的默認庫文件路徑下，當安裝其他軟件包時，如果需要用到這些目錄中的動態鏈接庫文件，將會無法找到，從而出現缺少".so"文件的錯誤信息。
在RHEL5系統中，配置文件“/etc/ld.so.conf”記錄了動態鏈接庫的默認搜索路徑。當需要添加新的庫文件搜索路徑時，則必須在該文件中進行相應修改，修改完畢後執行"ldconfig"命令，重新讀取新的配置信息。
eg：將"/usr/local/mysql/lib/mysql'目錄添加到系統的庫文件搜索路徑中。
vi /etc/ld.so.conf //在文件末尾添加一行記錄
/usr/local/mysql/lib/mysql
ldconfig
當安裝新的應用程序時，如果提示缺少".so"文件，應首先使用find命令查找系統中是否存在對應的文件，若不存在則表示提供該鏈接庫的依賴軟件並沒有安裝，需要先獲取相應的軟件包並安裝才行。若在系統中已經存在對應的".so"文件，則可以通過上述修改ld.so.conf文件的方法解決庫文件搜索的問題。
3、修復文件系統
Linux主機經常因為非正常關機、突然斷電、設備數據讀寫異常等原因導致文件系統的破壞。比較常見的是超級塊（super-block）損壞，超級塊是文件系統的核心"檔案"，它記錄了該文件系統的類型、大小、空閒磁盤塊等信息。當文件系統的超級塊數據損壞時，Linux將無法識別該文件系統，也就無法掛載使用。
當通過"/etc/fstab"配置文件自動加載的文件系統出現錯誤時，Linux系統開機後一般會自動進行檢測，並提示用戶需要進行文件系統的修復操作，例如：當"/dev/sdb1"分區的超級塊出現錯誤時，啟動後系統將提示"Give root password for maintenance"
這時只需要輸入root用戶的密碼，即可進入到一個臨時的Shell環境，在這裡用戶可以對出現錯誤的文件系統進行修復。修復一般的文件系統錯誤可以使用fsck命令，結合"-t"選項指定文件系統類型，結合“-y”選擇對發現的問題自動回答“yes”。需要注意的是，如果該文件系統遭受破壞的情況很嚴重，則修復完畢後可能仍然會丟失一些數據，因此請慎重決定是否進行修復。
eg：使用fsck命令修復位於"/dev/sdb1"分區中的ext3文件系統。
fsck -yt ext3 /dev/sdb1
exit //退出臨時Shell環境後將自動重啟。
4、磁盤資料耗盡故障
顯而易見，當一個文件系統的磁盤空間被耗盡以後，將無法繼續在該分區創建新的文件數據，從而導致故障的出現，例如：當根分區"/"中的磁盤空間耗盡以後，將可能導致部分程序乃至整個系統無法正常啟動或進行，因為一些臨時的運行文件將無法建立。
當根分區磁盤空間不足無法啟動進入Linux系統時，可以通過RHEL5的光盤進入急救模式，轉移或清除掉根分區占用大量空間的文件。過程不再描述。
除此以外，當ext3文件系統中，i節點作為文件的索引節點，決定了該磁盤中文件數據的存儲位置。當一個文件系統被創建以後，其i節點數就已經固定下來了，從而在該文件系統中能夠使用的文件數量也就固定下來了。如果用戶在該分區中創建了巨量的細小文件（耗盡i節點），將可能出現這種情況；雖然該分區中仍然有大量的剩余磁盤空間，但是用戶卻無法再 建立新的文件。
4.1、模擬i節點耗盡故障
eg：1、以一個20M的ext3文件系統為例（“/dev/sdb2”），將其掛載到"/data"目錄下。並使用帶“-i”選項的df命令確認該分區的i節點的使用情況。
4.2、編寫一個循環創建空文件的腳本程序，運行該腳本直至耗盡sdb2分區中的i節點。
4.3、i節點耗盡以後，再次創建新的文件時，將會出現"設備上沒有空間"的錯誤信息，但是使用df命令可以查看到該分區中還有可用的剩余空間，只是i節點數已經用完。
4.4、修復i節點耗盡故障
理解i節點耗盡故障的根結以後，問題就好了點了，只要找出該分區中占用大量i節點的細小文件，並進行轉移或者刪除即可。
rm -rf `find /data -empty -a -type f`
5、無法卸載已掛載的設備
在Linux系統中，通過umount命令卸載光驅等設備時，有時候會出現"device is busy"的提示信息，而無法卸載。這表示"設備正忙"，很可能是由於用戶或者其他程序正在使用設備的資料而造成的，系統基於保護性考慮，將禁止直接卸載該設備。
eg：當用戶的當前功能路徑位於光盤中的目錄時，將無法卸載該光盤設備。
由於umount命令並不會告知是那個用戶、程序正在使用該設備中的資源，因此在當前登錄的用戶數量較多、進程結構復雜的情況下會很難定位正在使用該目錄的進程。使用fuser命令可以幫助解決這個問題
fuser命令用戶找出正在使用某個設備或文件/目錄的用戶、程序等相關信息。通過“-m”選項可以指定相應的文件或目錄，“-v”選項可以顯示詳細信息。如果使用"-k"選項，還可以強制關閉正在使用該文件或目錄的進程（當然，也可以使用kill命令終止該進程。）
eg：查看正在使用"/media"目錄的用戶、進程等相關信息，然後關閉正在使用該目錄的進程。
6、檢測硬盤壞道
磁盤壞道分為邏輯壞道和物理壞道兩種，前者主要由於軟件操作不當造成，可以使用軟件修復；而後者是物理性損壞，只能通過更改磁盤分區或扇區占用位置來進行改善，排除掉包含壞塊的磁盤空間。當磁盤出現一下現象時，有可能是磁盤出現壞道，需要進行檢測和修復。
>：讀取磁盤中的數據時，磁盤設備發出異常聲響。
>：訪問磁盤中的某個文件時，反復讀取且出錯，提示文件損壞。
>：對於新建立的分區無法完成格式化。
>：系統使用該磁盤時頻繁死機。
硬盤出現壞道後，如果不及時更換或進行技術出來，壞道就會越來越多，並可能造成頻繁死機和數據丟失的後果。所有必要時應該對磁盤進行定期檢測，檢測是否存在壞道。
在Linux系統中，檢測磁盤的壞道情況可以使用badblocks命令進行，在創建文件系統的過程中也可以結合mkfs命令的選項進行檢測。使用badblocks命令時，“-s”選項用戶顯示進度信息，“-v”選項用於顯示詳情。
eg：使用mkfs命令格式化"/dev/sdb2"分區，並結合"-c"選項進程壞塊檢測。
eg：使用badblocks命令檢測"/dev/sdb2"分區中是否存心壞塊。
以上為常見問題；歡迎補充~~