mount --bind /dev如果我对 chroot 目录执行了上述操作，并且 chroot 到 chroot 目录并从里面删除了 /dev/ 文件夹，会发生什么情况？我以为我的主机的 /dev 目录将被删除，但是网页我读到的是这样的：
上述命令会将主机系统的重要目录挂载到编辑目录。如果您稍后决定删除编辑目录，请确保在删除之前卸载所有目录（请参阅下面的清理章节）。否则，您的主机系统将无法使用，直到您重新启动它。
所以意思是如果我重启主机就没问题了。这是真的吗？
答案1
正如 muru 所评论的，我无法删除挂载点，只能删除该挂载点下的文件。我在下面做了一个简单的测试（我记得）。
$sudo debootstrap --arch=amd64 forcal edit
$mkdir mydir; mkdir mydir/{a,b,c}
$mkdir edit/mnt2
$sudo mount --bind mydir edit/mnt2
$sudo chroot edit
(now I'm in the chroot file system)
#ls /mnt2
a b c
#\rm /mnt2/c
#exit
$ls mydir
a b
我可以看到我在 chroot 文件系统中删除的文件实际上已在主机文件系统中删除，正如我预期的那样。
答案2
“如果我将 mount --bind /dev 到 chroot 目录，然后 chroot 到 chroot 目录并从里面删除 /dev/ 文件夹，会发生什么情况...... 所以这意味着如果我重新启动我的主机就没问题了。
- 不，这并不是它确切的意思，但是，网页上所描述的内容确实与你所解释的不同。
详细说明：
引用的声明并没有具体暗示将会有一个在 chroot 环境的绑定挂载文件系统中恢复已删除或移除的文件而是只表明系统可用性如果用户决定删除目录而不先卸载与主系统目录/edit中的子路径绑定的各种子路径，则直到重新启动后才会恢复。可以肯定的是，该目录与正在描述的 LiveCD 自定义过程中指示用户进入的目录相同。/edit/editchroot
话虽如此，正如您所期望的，并且正如您在自己的答案中已经展示的那样，在 chroot 中从绑定挂载的目录中删除文件也会从它绑定到的目录中删除这些文件（在本场景中为主系统）。但是，页面上描述的情况发生在退出 chroot 时，并且删除/edit仍使用绑定挂载挂载的目录时，至少在当时，也会删除它们从某种意义上来自主要系统。查看更多错误手册页的部分mount。
重启让一切恢复正常
系统在重启后将变得可用的想法来自于这样一个事实：正如下面进一步解释的那样，所提到的挂载子路径具体涉及那些挂载点：
sudo mount --bind /dev/ edit/dev
sudo chroot edit
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devpts none /dev/pts
由于以上都是引用伪文件系统的挂载点，在某种程度上可以认为每次内核启动并检测到硬件时都会重新生成。那么，可能更容易理解该陈述本身是如何正确的，但您解释的假设场景不同，在确认它是正确的之前，需要明确以下理解和区别：
- 您描述的是在文件系统的 chroot 环境中删除项目，您以 root 身份运行，同时主系统也在使用该文件系统（在这种情况下，您无论如何都会遇到权限问题），但在这方面，您是在告诉 chroot 环境中的系统删除这些项目，本质上是通知系统它们已被删除。与... 不同
- 本文描述了这样一种情况：在删除工作目录时，所有系统引用都会被突然删除，其中命名空间之间共享挂载，而命名空间与进程相关联，退出 chroot 会释放主系统对它们的直接访问，使它们保持打开状态，并且可能在该命名空间内创建其他正在运行的守护进程，然后从主系统的位置删除该命名空间会破坏在突然删除之前存在的所有端点、同步数据和内核/内核设置引用。换句话说，从系统的角度来看，当您删除包含其挂载点的目录时，它不知道这些目录突然去了哪里。请参阅内核文档文件系统和共享子树。
- 只有
/dev目录是通过 bind 从主系统挂载的，而sys、proc和/dev/pts是从 chroot 内部挂载的，这会创建各种文件系统的私有实例，以便在这个新实例中创建的对象与其他实例无关这些相同的目录（即每个目录的主系统实例） /sys不是真正的磁盘文件系统：它是一种虚拟文件系统的表示形式和访问状态的方法。它完全基于 RAM，并且内容/sys不存储在磁盘上，如前所述这里。/dev是设备文件的特殊目录，是tmpfs变体 (devtmpfs)。这些是抽象概念，不是磁盘上的真实文件。该目录在启动时填充，可能会更改以反映现有设备接口，这些接口由内核和用户空间守护进程创建和销毁udevd。（如前所述这里。/dev/pts是特定于控制台设备的虚拟系统的表示。此处的每个条目都是在您打开本地 GUI 终端时创建的。（如前所述这里。/proc或者进程也是一个完全虚拟的文件系统，内核控制所有操作并定义它们的结构（如上所述这里。
/edit因此，在重新启动时，这些文件系统将由内核重新生成，并替换那些虚拟存在的文件系统，如果因删除包含那些仍挂载的目录而停止，则系统将恢复功能退出后chroot。
总结一下：
如果这造成的混乱多于清晰度，是的，从技术上讲，如果您能够以/dev某种方式在 chroot 中成功删除文件夹，则在重新启动后，您的主系统将恢复。但是，再次说明，您所描述的涉及 chroot 进入文件系统并以 chroot 形式删除某些内容，而指南指出如何离开 chroot 然后从 chroot 外部删除工作目录会导致问题。因此，虽然您的理解在一般意义上是正确的，但比较这两种情况时完全不同，对重新启动后将恢复的内容的理解应该有助于澄清为什么我最初说“不”，这不是它所说的，但现在将其描述为“是”，这是真的。
添加了边注：
- 本指南的这一部分有点过时，是在 2008 年添加的修订 78而在较旧的内核（大约 3.x）中，绑定挂载与原始挂载确实没有区别。直到 2012 年左右，内核才开始跟踪绑定挂载并公开信息，
/proc/PID/mountinfo这意味着如果您在其目录/文件系统中/edit仍然挂载了/edit/procn/edit/sys和 时删除了它们，而/edit/dev/pts它们分别绑定到主系统的/proc//sys和/dev/pts，那么它们的删除也适用于主系统，正如您在上面的回答中所确认的那样。 - 在现代系统上，当我们尝试在不卸载的情况下删除目录时，我们更有可能遇到文件权限问题和限制，以防止系统首先停止运行
/edit。 - 有一篇关于绑定挂载的精彩文章，提供了更加用户友好且易于理解的绑定挂载解释这里。
总之，也许这仅仅是一个语义问题，但似乎仍然存在一些脱节，即为什么会这样说，而你的测试证明了你所理解的是真实的。而且，希望现在更加明显，他们对非常相似的事情的解释略有不同。