重置密碼修復Linux系統

故障現象

近些天，機房的設備接二連三遭遇些不順，不是被人把服務器供電搞斷，就是碰到存儲故障導致存儲連接丟失，一波接一波的虛機不斷被傷害，有的虛機重啟后一切正常，有的虛機變成了只讀文件系統，有的則干脆在磁盤檢查報未預期的不一致錯誤，幾番折騰下來，一直對存儲不太重視的我，對存儲的“情感”更進了一步。

首先是變為只讀文件系統的一類，即操作系統正常運行中，突然與存儲失去了聯系，Windows與Linux容忍的時間是不一樣的，超出了最大容忍時間，操作系統就會將磁盤變為只讀文件系統，確保數據無法寫入，否則引發異常。此時，無論Windows還是Linux在表面上看都正常運行著，網絡也通暢，讀多寫少的業務可能都察覺不到有異常，寫入較多的業務則會較為敏感，會在各個操作界面拋出異常。

解決這類問題，最簡單易行的辦法就是重啟虛機。重啟后有兩種可能，其一是一切正常；其二則是出現磁盤自檢并且需要人工干預，這是因為與存儲失聯的容忍時間內還有未寫入磁盤的數據，造成元數據信息不一致。當然，也有更高要求的環境需要不重啟進行重新掛載，這不僅要求更高超的技術水平，同時也依賴底層硬件支持在線刷新連接狀態方可。本例所遇到的環境并沒那么嚴謹，直接采用重啟這一“粗暴”途徑。

重新啟動后，Linux系統直接拋出UNEXPECTED INCONSISTENCY錯誤，也就是文件系統自檢發現不一致。

故障解決

在操作系統中，為了增加系統性能而采用的Cache機制，分為write-through和write-back兩 種。Writethrough也叫直寫模式，在數據保存時，同時寫入緩存Cache和后端存儲。此模式缺點在于數據寫入磁盤的IO速度較慢，必須等待寫入磁盤成功才算完畢。

Write-back也叫回寫模式，在數據保存時只寫入緩存Cache，只在數據被替換出緩存時，被修改的緩存數據才會被寫到后端存儲。此模式的優點是數據寫入Cache速度快，不需要等存儲反饋落盤成功就算完畢，缺點是數據未被寫入存儲時出現系統掉電或死機等情況，就會導致這一現象（如圖1）。

圖1 文件系統待修復界面及操作

遇到這一問題不用太擔心，只要輸入正確的根用戶密碼，執行fsck-y /dev/VolGroup00/LogVol01即可完成磁盤修復，再次重啟就能正常進入操作系統了。在這一命令中，fsck是檢查文件系統并修復錯誤的命令，-y對提出的所有問題假定一個“yes”的響應，若不使用該選項，則每檢查到一個錯誤的文件都需要人工響應是否修復，/dev/VolGroup00/LogVol01即待檢測修復的目標文件系統。

然而，接下來處理的另一個虛機遇到的問題又有些棘手——根用戶密碼始終不正確。詢問了相關同事，所有可能的密碼都驗證失敗，必須另想辦法。

第一個想到的是單用戶模式重置密碼，在GRUB啟動菜單里移動光標至kernel項一行，按e編輯kernel菜單項，在行末尾輸入single，更改后按回車返回Linux啟動菜單項界面，然后按b即通過剛修改的行引導Linux從而進入單用戶模式。可是，相同的磁盤修復提示導致無法進入單用戶模式，即不能重置密碼，也不能修復磁盤。

第二個想到的是Linux救援模式，通過引導光盤進入救援模式環境，選擇不自動掛載掃描到的文件系統，救援模式下能夠找到本地磁盤的分區，可嘗試了好多種路徑都無法進行修復。重啟進入救援模式，選擇自動掛載本地文件系統，居然成功掛載，并且chroot /mnt/sysimages也能進入文件系統目錄，然而執行修復操作，依然無法成功。

轉念一想，既然能夠chroot進入到損壞的文件系統，是否能夠修改密碼呢？立即嘗試很快有了答案——可以重置root密碼。重啟系統，待提示輸入根用戶密碼進入修復操作界面，終于不再報密碼錯誤了，從而順利完成了磁盤修復。

故障分析

從修復文件系統操作忽然變成了特定情況下的重置密碼，密碼的錯誤本身就是蹊蹺的，因為在出現問題前同事都成功登錄過，懷疑是因為文件系統損壞而導致無法驗證密碼，錯誤的密碼又影響文件系統的修復操作，相互的制約使虛機承載的業務遲遲得不到恢復。救援模式從獨立的內存環境中掛載文件系統，遺憾未能找到恰當的修復文件系統的辦法，但密碼的重置也使問題的破解有了可操作性。

回顧整個問題，重置密碼和修復文件系統都還是問題的表象，存儲系統的重要性不言而喻，每個虛機根據業務屬性的不同，合理選擇writethrough和write-back兩種Cache寫機制，以期盡可能避免問題復雜度的提升。