一次因NAS儲存故障引起的Linux系統恢復案例

2021-09-22 04:39:47 字數 2878 閱讀 9712

nas作業系統核心為linux,自帶的儲存有16塊硬碟,總共分兩組,每組做了raid5,linux作業系統無法正常啟動,在服務啟動到cups那裡就停止了,按鍵ctrl+c強制斷開也沒有響應,檢視硬碟狀態,都是正常的,沒有報警或者警告現象。

1、第一次處理過程

nas系統本身就是乙個linux核心裝載了乙個檔案系統管理軟體,管理軟體可以對系統磁碟、系統服務、檔案系統等進行管理和操作,正常情況下,基於linux核心的nas系統應該啟動到init3或者init5模式下,由於nas僅用了linux乙個核心模組和幾個簡單服務,所以判斷nas下的linux系統肯定是啟動到init 3模式下,那麼現在無法啟動到多使用者字元介面下,何不讓linux直接進入單使用者(init 1)模式下呢,因為單使用者模式下僅僅啟用系統所必須的幾個服務,而cpus服務是應用程式級別的,肯定不會在「init 1」模式下啟動,這樣就避開了cups無法啟動的問題,所以,下面的工作就是要進入linux的單使用者模式下。

很多的linux發行版本都可以在啟動的引導介面通過相關的設定進入單使用者模式下,通過檢視nas的啟動過程,基本判斷這個linux系統與rhel/centos發行版極為類似,因此,就通過rhel/centos進入單使用者模式的方法試一試。

rhel/centos進入單使用者模式很簡單,就是在系統啟動到引導歡迎介面下,按鍵e,然後編輯正確的核心引導選項,在最後面加上「single」選項,最後直接按鍵「b「即可進入單使用者了。

接下來,重新啟動nas,然後硬體自檢,接著開始啟動linux,一直在等待這個nas的啟動歡迎介面,但是歡迎介面一直沒出來,就直接進入核心映象,載入核心階段了,沒有核心引導介面,如何進入單使用者啊,經過簡單思考,還是決定在硬體檢測完畢後直接按鍵盤」e「鍵,奇蹟出現了,還真的可以,nas進入到了核心引導介面,通過簡單觀察,發行第二個正是要引導的核心選項,於是移動鍵盤上下鍵,選擇這個核心,然後在按鍵」e「,進入核心引導編輯介面了,在這行的最後面,輸入「single」,然後按回車鍵,返回上個介面,接著按鍵「b」開始進行單使用者引導,經過一分鐘的時間,系統如願以償的進入了單使用者下的shell命令列。

進入單使用者模式後,能做的事情就很多了,首先要做的就是將cups服務在多使用者模式下自啟動關閉,執行命令如下:

chkconfig --levle 35 cups off

執行成功後,重啟系統進入多使用者模式下,看看系統是否能正常啟動。

2、第二次處理過程

將cups服務開機自啟動關閉後,重啟nas,發現問題依舊,nas還是啟動到cups服務那裡停止了,難道上面的命令沒有執行成功嗎?明明已經禁止了cups服務啟動了,怎麼還是啟動了呢?於是,繼續重啟nas,再次進入單使用者模式下,看看問題究竟出在**了。

進入單使用者後,再次執行chkconfig 命令,依舊可以成功,難道是cups服務有問題,先看看配置檔案,執行如下命令:

1

vi/etc/cups/cupsd.conf

在這裡發現了乙個問題,vi開啟cupsd.conf時,提示「write file in swap」,檔案明明真實存在,怎麼說在虛擬記憶體中呢,經過思考,只有一種可能,nas裝置的linux系統分割槽應該沒有正確掛載,導致在進入單使用者的時候,所有檔案都儲存在了虛擬記憶體中,要驗證非常簡單,執行「df」命令檢視即可,如下圖所示:

從這裡可以看出,linux的系統分割槽並未掛載,通過"fdisk -l"檢查下磁碟分割槽狀態,輸出如下圖所示:

通過輸出可知,nas的系統盤是/dev/sda,僅劃分了/dev/sda1和/dev/sda2兩個系統分割槽,而資料磁碟是經過做raid5完成的,在系統上的裝置標識分別是/dev/sdb1和/dev/sdc1,由於單使用者預設沒有掛載任何nas磁碟,這裡嘗試手動掛載nas的系統盤,執行如下命令:

[root@nasserver ~]#mount /dev/sda2 /mnt

[root@nasserver ~]#mount /dev/sda1 /opt

這裡的/mnt、/opt是隨意掛載的目錄,也可以掛載到其他空目錄下,掛載完成,分別進入這連個目錄看看內容有什麼,如下圖所示:

通過這兩個內容的檢視,初步判斷,/dev/sda2分割槽應該是linux的根分割槽,而/dev/sda1應該是/boot分割槽。現在分割槽已經掛載上去了,再次執行df命令看看掛載情況,如下圖所示:

到這裡為止,發現問題了。/dev/sda2磁碟分割槽已經沒有可用的磁碟空間了,而這個分割槽剛好是nas系統的根分割槽,根分割槽沒有空間了,那麼系統啟動肯定就出問題了。

下面再把思路轉到前面介紹的案例中,由於系統cups服務在啟動的時候會寫啟動日誌到根分割槽,而根分割槽因為沒有空間了,所以也就無法寫日誌了,由此導致的結果就是cups服務無法啟動,這就解釋了此案例中nas系統每次啟動到cups服務就停止的原因。

[root@nasserver ~]#  du -sh /var/log

50.1g    /var/log

通過命令輸出發現/var/log目錄佔據了根分割槽僅70%的空間,清理這個目錄下的日誌檔案即可釋放大部分根分割槽空間,清理完畢,重啟nas系統,發現系統cups服務能正常啟動了,nas服務也啟動正常了。

一次因NAS儲存故障引起的Linux系統恢復案例

nas作業系統核心為linux,自帶的儲存有16塊硬碟,總共分兩組,每組做了raid5,linux作業系統無法正常啟動,在服務啟動到cups那裡就停止了,按鍵ctrl c強制斷開也沒有響應,檢視硬碟狀態,都是正常的,沒有報警或者警告現象。1 第一次處理過程 nas系統本身就是乙個linux核心裝載了...

記 一次電流不夠引起的故障解決

前兩天處理了乙個筆者不怎麼常見的問題點,特別的在這裡記錄一下,以備之後不小心忘記後的註記。技能名稱 技能熟練度 技能教程鏈結 模擬電路 了解暫無 當前除錯一塊單板,筆者除錯的模組主要為訊號採集電路。功能為採集輸入的訊號波形並進行引數的輸出。測試人員在進行功能的驗證過程中,使用外部的輸入的交流訊號進入...

一次svn的故障處理

辦公室乙個妹紙在用svn的時候,刪掉了乙個目錄,然後上傳的時候出現錯誤,根據報錯,度娘解釋要用cleanup,但是cleanup不能用,妹紙從網上查到要用sqlite3連線wc.db,然後delete一下任務堆積,但是妹紙執行後沒反應,於是妹紙就沒招了 把我叫了過去,於是排障開始了。根據報錯 回到工...