感謝TechRoomage網友 鳶一雨音 的投稿

寫這篇文章是有原因的。為了配置完全的靜默啟動,筆者對自己的工作電腦上運行的Linux執行了不當的mkinitcpio操作,原因是忽略了mkinitcpio.conf文件中的一處邏輯錯誤。這使得mkinitcpio生產了新的內核文件,但這個內核文件不能正常工作。重啟的時候,內核啟動中止於Panic狀態。

TechRoomage學院:如何修復一個Panic的Linux內核” data-original=”https://img.ithome.com/newsuploadfiles/2017/06/[email protected]_1,k_aW1hZ2VzL3F3LnBuZw==,y_20,o_60,x_20,g_7″ alt=”TechRoomage學院:如何修復一個Panic的Linux內核”>

一般情況下,新內核不能正常工作時,可以通過使用initramfs內核文件的fallback版本來臨時啟動系統,甚至可以直接將fallback版本覆蓋回去以回退更改,但這次要命的是,mkinitcpio同時修改了vmlinuz內核文件,而且vmlinuz沒有fallback版本。對於一般用戶,可以直接重裝系統解決;但是筆者的工作站環境配置相當複雜,這意味著除了可能損失我的工作文件之外,我還需要花費大量額外的時間來重配開發環境。

注意本教程之「修復」,指「嘗試回退毀滅性的人為更改」,故不可用於恢復不知原因的內核崩潰。

一、從LiveCD啟動並查看磁碟

憑著兼職Linux伺服器運維那段時間積累的經驗,我立即想到可以用LiveCD啟動來獲得一個臨時的、用於修復內核的Linux環境。

筆者使用的是Arch Linux 64位版,所以我從從Arch Linux的LiveCD啟動。正確進入LiveCD內建的root用戶之後,我們需要查看自己的主硬碟的設備名。執行fdisk -l,在筆者的情況下,我的主硬碟、掛載至根目錄的分區對應的設備文件是/dev/sdb2。

二、chroot至硬碟上的系統根目錄

要chroot到硬碟上的系統根目錄,並能正常調用硬碟上的系統組件對硬碟上的系統作出更改,我們首先要手動掛載硬碟上的根分區。執行(我的設備文件是/dev/sdb2):

mount /dev/sdb2 /mnt

先不要急。這時候chroot到/mnt雖然能進入硬碟上主系統的bash,但是你幾乎不能正確完成任何複雜的任務,因為還有一些重要的目錄沒有掛載。我們執行指令,分別掛載proc目錄、/sys目錄、/dev目錄和/run目錄。進入/mnt,分別執行:

mount -t proc proc proc/

mount –rbind /sys sys/

mount –rbind /dev dev/

mount –rbind /run run/

這些目錄的作用分別是:

proc目錄:虛擬的、Procfs格式的文件系統,用於存放進程狀態文件(在Linux下,這些文件表面看起來都是文本文件,實際上是進程狀態的文件映射);

/sys目錄:對於Arch Linux,這是一個類似proc目錄的、Sysfs格式的虛擬文件系統,用於儲存連接到系統的設備文件;對於傳統Unix和類Unix,它是一個指向內核代碼樹的軟鏈接;

/dev目錄:儲存設備文件,比如你的硬碟就是/dev/sdXY之類的;

/run目錄:存放最近的啟動之後系統的部分信息;

掛載了這些東西之後,我們可以chroot到我們的主硬碟的根目錄了:

chroot /mnt

後悔葯++。對於我來說,我只需要修改mkinitcpio.conf文件並重新執行mkinitcpio操作,就能重新生成正確的內核文件。一般的,如果是錯誤地修改了配置導致的內核Panic,這個環境可以解決大部分問題。

三、一些技巧

1、許多配置文件在LiveCD里的那個系統里有正確的版本或範本,如果不記得正常的時候是什麼樣子的,可以參照一下它們;

2、對於Arch Linux,可以在不chroot到/mnt的情況下,直接使用pacstrap指令對/mnt這個掛載點進行軟體包管理;

3、可以在兩個tty下操作,這樣在chroot到/mnt下之後依然能從LiveCD的文件系統里向/mnt轉移文件。

本教程應該對大部分Linux發行版都可用,希望能對部分Linux用戶產生幫助。

轉載文章請附上來源:IT之家學院:如何修復一個Panic的Linux內核 – 科技空間 TechRoomage

LEAVE A REPLY

Please enter your comment!
Please enter your name here