☰

碰撞危险？/var/log 由修复工具填充，但实际的 /var 位于单独的分区

tag-icon • tag-icon boot
碰撞危险？/var/log 由修复工具填充，但实际的 /var 位于单独的分区

我的系统出了点问题，我用一张方便的启动 CD 来修复grub，还纠正了设备分配中的一些错误。没什么大不了的，而且效果很好。很好。

然而，这张启动 CD 上的修复软件喜欢写入，/var/log/*“乐趣”就开始了。

我/var的是分离分区，而此工具却兴高采烈地创建了一棵新/var树并将其填充到我的树上/（一旦它找到一个有效的签名）。这可不好。

假设我在修复后关闭 PC，然后再次（冷）启动到我自己的发行版。这真的行不通，不是吗？因为我知道系统在/var启动时需要大量的信息文件。（它不仅仅是用作“日志文件转储”，就像大多数初学者认为的那样。）在虚拟机上，我 2 年前只是为了好玩而尝试过：结果是无法使用处女 /var目录。即使重建整个树（只有子目录，但没有里面的文件）也不起作用。似乎有一些非常重要的事情，即启动例程做需要成功到达图形登录屏幕。

/var/*那么，如果某个工具在你的/分区上创建了一棵树，不久之后，/var分区的 UUID 被系统读取，那么如何避免这种情况呢？我曾经想过/var 分割将要覆盖分区上的“伪/var” /，但似乎并非如此。另外，这不是 Windows：它没有变成/var.backup或/var (2)或任何此类东西。

在 /etc/fstab 中：（为了便于阅读，UUID 已“标准化”）

# /boot on /dev/sda1 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee              /boot    ext4  ro        0  1
# /     on /dev/sda2 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee              /        ext4  defaults  0  2
# /var (NEW) on /dev/sda6 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee              /var     ext4  defaults  0  2
# /home on /dev/sda3 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee              /home    ext4  defaults  0  2
# /usr on /dev/sda5 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee              /usr     ext4  defaults  0  2
# /opt on /dev/sda7 after cloning system to new HDD
UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee              /opt     ext4  defaults  0  2

答案1

/var那么，您以前在根文件系统上有一个空文件，它被用作位于不同文件系统上的“真实 /var”的挂载点？当您从 ISO 启动时，它以某种方式设法在您的“根”中创建了一堆子目录/var，所以现在您担心，在重新启动后，系统将无法挂载您的“真实 /var”，因为挂载点中有一些文件和目录？

我认为您不必担心，在这种情况下，挂载过程运行正常。挂载点内的文件将无法访问（直到您卸载分区），并且挂载点的所有内容将被挂载分区的内容“替换”。

我能想到的唯一负面影响是一些磁盘空间会被不需要的日志浪费，但是，我认为删除它们是相当安全的。

相关内容