为什么initramfs以只读方式挂载根文件系统

将根文件系统挂载ro到initramfs（和initrd）中的原因是什么？

例如，Gentoo initramfs指南使用以下命令挂载根文件系统：

mount -o ro /dev/sda1 /mnt/root

为什么不以下？

mount -o rw /dev/sda1 /mnt/root

我可以看到，可能有一个很好的理由（可能涉及switchroot），但是似乎没有任何地方对此进行记录。

的初始ramdisk（initrd的）通常仅这是需要安装实际的根文件系统和越区切换启动到它包含根文件系统的精简版本。

存在initrd的原因是，在现代系统中，引导加载程序无法足够聪明地可靠地找到根文件系统。像引导加载程序这样的小程序存在太多的可能性。考虑NFS根目录，非标准RAID卡等。引导加载程序必须仅使用BIOS加上可以塞入引导扇区的任何代码来完成其工作。

initrd存储在引导加载程序可以找到的位置，并且它足够小，以至于占用的额外空间通常不会困扰任何人。（在小型嵌入式系统中，通常没有“真实的”根，只有initrd。）

initrd十分宝贵：它的内容必须在所有情况下都保留下来，因为如果initrd中断，系统将无法启动。设计人员为了确保这一点而做出的一个设计选择是使引导加载程序以只读方式加载initrd。还有其他一些原则也可以解决此问题，例如，在没有“真实”根目录的小型系统中，您仍然需要单独挂载/tmp，/var/cache并且用于存储事物。很少更改initrd，然后应非常小心地进行。

再回到那里正常情况下是一个真正的根文件系统，它最初是只读方式挂载因为initrd的了。然后出于相同的原因，它会尽可能长时间保持只读。需要进行的对真实根目录的所有写操作都将推迟进行，直到按偏好启动系统为止，或者至少直到无法满足该偏好的引导过程后期为止。

在此只读阶段发生的最重要的事情是检查根文件系统以查看是否已将其干净地卸载。这是引导加载程序当然可以做的，而不是将其留给initrd，但是如果没有彻底卸载根文件系统，会发生什么呢？然后，它必须调用fsck进行检查并可能修复它。因此，如果它负责此步骤，而不是等到切换到“真实”根目录后，将在哪里initrd获得fsck？您可以说在构建它时需要复制fsck到中initrd，但是现在更大了。而最重要的是，这 fsck将复制？Linux系统通常使用十几个不同的文件系统。您只复制真正根所需的那个吗？initrd被建造？如果后来将根文件系统迁移到其他文件系统类型，而又有人忘记重建initrd，您是否initrd通过复制所有可用fsck.foo程序来扩大它的大小？

Linux引导系统架构师明智地选择了不让initrd承担这些问题。他们将对真正根文件系统的检查委托给了真正根文件系统，因为这样做比initrd更好。

一旦引导过程进行得足够安全，可以将initrd从实际根目录下替换为pivot_root(8)，并以读写模式重新挂载文件系统。

因为在引导过程中，根文件系统始终始终是只读安装的。完成各种自检后，它将根文件系统重新安装为读/写并开始挂载其他文件系统。

我能想到的一个原因是防止某种腐败。例如，您可以将ext4文件系统作为ext2挂载（反之亦然），这在ro模式下是安全的，但是如果从initram挂载rw，则可能导致格式不兼容的更改。

哦，还有另一个原因：initramfs可能没有fsck，但是您可能需要在挂载rw之前检查文件系统。