快速修复一个Panic的Linux内核的技巧

感谢脚本之家网友 鸢一雨音 的投稿

写这篇文章是有缘故原由的。为了配置完全的静默启动，笔者对自己的工作计算机上运行的Linux执行了不妥的mkinitcpio操纵，缘故原由是忽略了mkinitcpio.conf文件中的一处逻辑错误。这使得mkinitcpio生产了新的内核文件，但这个内核文件不能正常工作。重启的时候，内核启动中止于Panic状态。

一样平常情况下，新内核不能正常工作时，可以通过利用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用户产生资助。

相关推荐：

Linux系统怎么配置双显卡?