重置密碼修復(fù)Linux系統(tǒng)

故障現(xiàn)象

近些天，機(jī)房的設(shè)備接二連三遭遇些不順，不是被人把服務(wù)器供電搞斷，就是碰到存儲(chǔ)故障導(dǎo)致存儲(chǔ)連接丟失，一波接一波的虛機(jī)不斷被傷害，有的虛機(jī)重啟后一切正常，有的虛機(jī)變成了只讀文件系統(tǒng)，有的則干脆在磁盤(pán)檢查報(bào)未預(yù)期的不一致錯(cuò)誤，幾番折騰下來(lái)，一直對(duì)存儲(chǔ)不太重視的我，對(duì)存儲(chǔ)的“情感”更進(jìn)了一步。

首先是變?yōu)橹蛔x文件系統(tǒng)的一類，即操作系統(tǒng)正常運(yùn)行中，突然與存儲(chǔ)失去了聯(lián)系，Windows與Linux容忍的時(shí)間是不一樣的，超出了最大容忍時(shí)間，操作系統(tǒng)就會(huì)將磁盤(pán)變?yōu)橹蛔x文件系統(tǒng)，確保數(shù)據(jù)無(wú)法寫(xiě)入，否則引發(fā)異常。此時(shí)，無(wú)論Windows還是Linux在表面上看都正常運(yùn)行著，網(wǎng)絡(luò)也通暢，讀多寫(xiě)少的業(yè)務(wù)可能都察覺(jué)不到有異常，寫(xiě)入較多的業(yè)務(wù)則會(huì)較為敏感，會(huì)在各個(gè)操作界面拋出異常。

解決這類問(wèn)題，最簡(jiǎn)單易行的辦法就是重啟虛機(jī)。重啟后有兩種可能，其一是一切正常；其二則是出現(xiàn)磁盤(pán)自檢并且需要人工干預(yù)，這是因?yàn)榕c存儲(chǔ)失聯(lián)的容忍時(shí)間內(nèi)還有未寫(xiě)入磁盤(pán)的數(shù)據(jù)，造成元數(shù)據(jù)信息不一致。當(dāng)然，也有更高要求的環(huán)境需要不重啟進(jìn)行重新掛載，這不僅要求更高超的技術(shù)水平，同時(shí)也依賴底層硬件支持在線刷新連接狀態(tài)方可。本例所遇到的環(huán)境并沒(méi)那么嚴(yán)謹(jǐn)，直接采用重啟這一“粗暴”途徑。

重新啟動(dòng)后，Linux系統(tǒng)直接拋出UNEXPECTED INCONSISTENCY錯(cuò)誤，也就是文件系統(tǒng)自檢發(fā)現(xiàn)不一致。

故障解決

在操作系統(tǒng)中，為了增加系統(tǒng)性能而采用的Cache機(jī)制，分為write-through和write-back兩 種。Writethrough也叫直寫(xiě)模式，在數(shù)據(jù)保存時(shí)，同時(shí)寫(xiě)入緩存Cache和后端存儲(chǔ)。此模式缺點(diǎn)在于數(shù)據(jù)寫(xiě)入磁盤(pán)的IO速度較慢，必須等待寫(xiě)入磁盤(pán)成功才算完畢。

Write-back也叫回寫(xiě)模式，在數(shù)據(jù)保存時(shí)只寫(xiě)入緩存Cache，只在數(shù)據(jù)被替換出緩存時(shí)，被修改的緩存數(shù)據(jù)才會(huì)被寫(xiě)到后端存儲(chǔ)。此模式的優(yōu)點(diǎn)是數(shù)據(jù)寫(xiě)入Cache速度快，不需要等存儲(chǔ)反饋落盤(pán)成功就算完畢，缺點(diǎn)是數(shù)據(jù)未被寫(xiě)入存儲(chǔ)時(shí)出現(xiàn)系統(tǒng)掉電或死機(jī)等情況，就會(huì)導(dǎo)致這一現(xiàn)象（如圖1）。

圖1 文件系統(tǒng)待修復(fù)界面及操作

遇到這一問(wèn)題不用太擔(dān)心，只要輸入正確的根用戶密碼，執(zhí)行fsck-y /dev/VolGroup00/LogVol01即可完成磁盤(pán)修復(fù)，再次重啟就能正常進(jìn)入操作系統(tǒng)了。在這一命令中，fsck是檢查文件系統(tǒng)并修復(fù)錯(cuò)誤的命令，-y對(duì)提出的所有問(wèn)題假定一個(gè)“yes”的響應(yīng)，若不使用該選項(xiàng)，則每檢查到一個(gè)錯(cuò)誤的文件都需要人工響應(yīng)是否修復(fù)，/dev/VolGroup00/LogVol01即待檢測(cè)修復(fù)的目標(biāo)文件系統(tǒng)。

然而，接下來(lái)處理的另一個(gè)虛機(jī)遇到的問(wèn)題又有些棘手——根用戶密碼始終不正確。詢問(wèn)了相關(guān)同事，所有可能的密碼都驗(yàn)證失敗，必須另想辦法。

第一個(gè)想到的是單用戶模式重置密碼，在GRUB啟動(dòng)菜單里移動(dòng)光標(biāo)至kernel項(xiàng)一行，按e編輯kernel菜單項(xiàng)，在行末尾輸入single，更改后按回車返回Linux啟動(dòng)菜單項(xiàng)界面，然后按b即通過(guò)剛修改的行引導(dǎo)Linux從而進(jìn)入單用戶模式?？墒牵嗤拇疟P(pán)修復(fù)提示導(dǎo)致無(wú)法進(jìn)入單用戶模式，即不能重置密碼，也不能修復(fù)磁盤(pán)。

第二個(gè)想到的是Linux救援模式，通過(guò)引導(dǎo)光盤(pán)進(jìn)入救援模式環(huán)境，選擇不自動(dòng)掛載掃描到的文件系統(tǒng)，救援模式下能夠找到本地磁盤(pán)的分區(qū)，可嘗試了好多種路徑都無(wú)法進(jìn)行修復(fù)。重啟進(jìn)入救援模式，選擇自動(dòng)掛載本地文件系統(tǒng)，居然成功掛載，并且chroot /mnt/sysimages也能進(jìn)入文件系統(tǒng)目錄，然而執(zhí)行修復(fù)操作，依然無(wú)法成功。

轉(zhuǎn)念一想，既然能夠chroot進(jìn)入到損壞的文件系統(tǒng)，是否能夠修改密碼呢？立即嘗試很快有了答案——可以重置root密碼。重啟系統(tǒng)，待提示輸入根用戶密碼進(jìn)入修復(fù)操作界面，終于不再報(bào)密碼錯(cuò)誤了，從而順利完成了磁盤(pán)修復(fù)。

故障分析

從修復(fù)文件系統(tǒng)操作忽然變成了特定情況下的重置密碼，密碼的錯(cuò)誤本身就是蹊蹺的，因?yàn)樵诔霈F(xiàn)問(wèn)題前同事都成功登錄過(guò)，懷疑是因?yàn)槲募到y(tǒng)損壞而導(dǎo)致無(wú)法驗(yàn)證密碼，錯(cuò)誤的密碼又影響文件系統(tǒng)的修復(fù)操作，相互的制約使虛機(jī)承載的業(yè)務(wù)遲遲得不到恢復(fù)。救援模式從獨(dú)立的內(nèi)存環(huán)境中掛載文件系統(tǒng)，遺憾未能找到恰當(dāng)?shù)男迯?fù)文件系統(tǒng)的辦法，但密碼的重置也使問(wèn)題的破解有了可操作性。

回顧整個(gè)問(wèn)題，重置密碼和修復(fù)文件系統(tǒng)都還是問(wèn)題的表象，存儲(chǔ)系統(tǒng)的重要性不言而喻，每個(gè)虛機(jī)根據(jù)業(yè)務(wù)屬性的不同，合理選擇writethrough和write-back兩種Cache寫(xiě)機(jī)制，以期盡可能避免問(wèn)題復(fù)雜度的提升。