分享如何修复一个Panic的Linux内核

如何修复一个Panic的Linux内核？Linux是一个一体化内核（monolithic kernel）系统，一些用户在操作Linux系统的过程中，有时候由于操作不当，会导致Linux内核不能正常工作。最近就有一位用户由于操作问题，使得内核启动中止于Panic状态，那么要如何修复一个Panic状态的Linux内核呢？下面我们一起来看看。

问题描述：

为了配置完全的静默启动，用户对工作计算机上运行的Linux执行了不当的mkinitcpio操作，原因是忽略了mkinitcpio.conf文件中的一处逻辑错误。这使得mkinitcpio生产了新的内核文件，但这个内核文件不能正常工作。重启的时候，内核启动中止于Panic状态。

一般情况下，新内核不能正常工作时，可以通过使用initramfs内核文件的fallback版本来临时启动系统，甚至可以直接将fallback版本覆盖回去以回退更改，但这次要命的是，mkinitcpio同时修改了vmlinuz内核文件，而且vmlinuz没有fallback版本。对于一般用户，可以直接重装系统解决；但是该用户的工作站环境配置相当复杂，这意味着除了可能损失用户的工作文件之外，用户还需要花费大量额外的时间来重配开发环境。

注意：本教程之“修复”，指“尝试回退毁灭性的人为更改”，故不可用于恢复不知原因的内核崩溃。

如何修复一个Panic的Linux内核？

一、从LiveCD启动并查看磁盘

凭着兼职Linux服务器运维那段时间积累的经验，小编立即想到可以用LiveCD启动来获得一个临时的、用于修复内核的Linux环境。

小编使用的是Arch Linux 64位版，所以小编从从Arch Linux的LiveCD启动。正确进入LiveCD内建的root用户之后，我们需要查看自己的主硬盘的设备名。执行fdisk -l，在小编的情况下，小编的主硬盘、挂载至根目录的分区对应的设备文件是/dev/sdb2。

二、chroot至硬盘上的系统根目录

要chroot到硬盘上的系统根目录，并能正常调用硬盘上的系统组件对硬盘上的系统作出更改，我们首先要手动挂载硬盘上的根分区。执行（小编的设备文件是/dev/sdb2）：

01mount /dev/sdb2 /mnt复制代码mount /dev/sdb2 /mnt

先不要急。这时候chroot到/mnt虽然能进入硬盘上主系统的bash，但是你几乎不能正确完成任何复杂的任务，因为还有一些重要的目录没有挂载。我们执行指令，分别挂载proc目录、/sys目录、/dev目录和/run目录。进入/mnt，分别执行：