chroot 技术 - Linux 系统的瑞士军刀

2025年4月8日

有没有遇到过无法启动的 Linux 系统，即使 BIOS 设置正常且没有重大硬件错误？

那么你需要了解 chroot 技术，它能真正地救你一命。

例如，前几周我就用这种方法修复了一台 Nanopore GridION device，此前通过 官方提供的 .iso 文件重装方法 失败了。这提醒了我应该花时间记录下这些步骤。

我使用了 Linux 作为我的日常操作系统十多年后才接触到这项技术（感谢 Matt！），鉴于它的实用性，我认为它应该受到更多的关注。因此，我希望通过这篇文章来稍微宣传一下。

TLDR（太长不看版）

简而言之，其思想是，如果你可以访问一台损坏或无法启动的 Linux 机器的硬盘（例如，可以通过从 Live USB-stick 启动，或将硬盘作为额外的驱动器插入另一台 Linux 机器来实现），你将以一种欺骗当前 Linux 会话的方式挂载该硬盘，让它误以为这是当前正在运行的系统的硬盘，但实际上并非如此。

要使这个技巧起作用，需要创建一个基于以下两件事的文件树：

1. 损坏系统的硬盘分区，该分区在主机操作系统上挂载为 / 文件夹。
2. 来自当前运行的临时操作系统的（Live USB-stick 或替代计算机）的一组特殊的系统文件夹，它们不是磁盘上的普通目录，而是包含运行的 Linux 系统所需的系统信息。 这些包括 /sys，/proc 和其他一些，我们将在下面详细介绍。

然后，你将在此新组装的文件夹结构上运行 chroot 命令，这意味着当前正在运行的 Linux 会话将使用这个新混合的文件夹（主要来自旧的、损坏的硬盘）替换其当前的文件系统。

这有点像将一辆故障的汽车连接到外部电源，以便你可以至少访问其仪表，检查里程，显示屏上的任何错误代码等。

无论如何，这使你可以运行各种命令，有望修复或诊断你的系统，例如 apt upgrade，dpkg-reconfigure（对于基于 Debian 的系统上损坏的软件包）或其他命令，具体取决于你的系统。

过程

最好将设置组装的文件夹结构和执行 chroot 的完整过程放在一个地方，以便在需要时可以轻松找到它。 理想情况下，你甚至可以打印出包含这些命令的小抄，或将它们存储在你的“维修工具包”USB 存储设备上的文本文件中。

无论如何，以下是你将找到该过程的所有步骤：

1. 启动你的替换操作系统（Live USB-stick 或其他带有连接到它的损坏计算机硬盘的计算机）。
2. 找出损坏系统的硬盘上的哪个分区包含根文件系统，以及哪个分区包含 /boot 文件夹。
   • 我通常使用 gparted，它在大多数基于 Ubuntu/Linux Mint 的 live 磁盘上都可用。
   • 你也可以使用基于命令行的工具，例如 sudo fdisk -l
   • 我通常尝试将损坏系统的每个分区挂载到文件导航器中（它们通常在 Linux Mint XFCE 的 Thunar 中显示为可挂载的驱动器），以真正确保我选择了正确的分区。
   • 如果你无法做到这一点，则必须根据文件系统的大小和类型、它们是否已在 /etc/fstab 中可用等进行一些猜测。
   • 在此示例中，我们将假定根文件夹位于分区中：

/dev/nvme0n1p5

…并且 /boot 分区位于：

/dev/nvme0n1p3

（这些恰好是我最近用这种方法修复的 Nanopore GridION device 的情况）。 3. 在当前运行系统的文件系统中的某个位置创建一个文件夹，该文件夹将充当新的根文件夹，以及其中的 /boot 文件夹：

sudo mkdir /rescue
sudo mkdir /rescue/boot

4. 将损坏系统的主分区和启动分区挂载到这些文件夹中，例如：

sudo mount /dev/nvme0n1p5 /rescue
sudo mount /dev/nvme0n1p3 /rescue/boot

5. 然后，将当前运行系统所需的特殊文件夹挂载到此新文件结构中的适当位置（mount 命令的形式为 mount -t <file-system-type> -o <options> <device> <mount-point>）：

sudo mount -t proc proc /rescue/proc
sudo mount -t sysfs sys /rescue/sys
sudo mount -o bind /dev /rescue/dev
sudo mount -t devpts pts /rescue/dev/pts

6. 现在我们准备好 chroot，或“更改根文件夹”到这个新创建的文件夹结构中：

chroot /rescue /bin/bash -i

7. 我们完成了！

现在，你可以在文件系统中查看以尝试找出导致系统无法工作的原因，以及使用所需的任何文件命令来尝试修复损坏的系统。

在我们的损坏的 GridION device 的情况下，我们在 /boot 中找到了一些损坏的符号链接和空的 initrd.img-* 文件，这表明 Linux Kernel 更新可能在软件包更新或类似过程中中断了。

在这种情况下，通过运行 sudo apt update && sudo apt upgrade 解决了这个问题，它抱怨一些损坏的软件包，并建议我们运行 sudo dpkg-reconfigure，最终解决了该问题。

阅读更多

• 关于 Chrooting 的良好指南

更新

• 2025-04-09, 18:14 CET：我刚刚注意到这篇文章已发布到 HackerNews，并且一度出现在首页的＃2 位置。

• Linux

• Nanopore

• Gridion

版权所有©2025 Samuel Lampa。 版权所有。 在 ORCID，GitHub，Twitter 或 LinkedIn 上找到我。