dpkg 替换 FAT 文件系统上的文件

Question

当您升级或重新安装一个包dpkg（以及最终使用它的任何东西，如 apt-get 等）时，它会通过在替换之前创建文件的硬链接来备份现有文件。这样，如果解包失败，它可以轻松地放回现有文件。这很棒，因为它可以保护操作系统免受 Bad Things™ 的影响。

除了...它仅在您的文件系统支持硬链接时才有效。并非所有文件系统都如此——例如 FAT 文件系统。

我正在为特定的嵌入式 ARM 平台开发 Debian 发行版，并且引导环境要求某些文件（包括内核）位于 FAT 文件系统上，以便引导代码能够定位和加载它们。

当您升级内核包（或在该 FAT 分区中有文件的任何其他包）时，安装失败：

dpkg: error processing archive linux-image3.18.11+_3.18.11.2.armadillian_armhf.deb (--install):
 unable to make backup link of `./boot/vmlinuz-3.18.11+' before installing new version: Operation not permitted

并且整个升级失败。

我在网上搜索过，我能找到的唯一参考是在进行特定升级时遇到特定问题的特定人员，其答案通常是“删除 /boot/vmlinuz-3.18.11+ 并重试”，是的，那个解决了那个特定的问题。

但这不是我的答案。我是 OS 分销商，而不是 OS 用户，因此我需要一种解决此问题的方法，该方法不涉及最终用户在升级之前手动删除其内核文件。我需要一种方法来告诉 dpkg 对 /boot 上的文件（或所有我关心的所有文件，尽管这会减慢升级操作的速度）“复制，而不是硬链接”，或者更好的是“如果硬链接失败，不要抱怨，只需复制它”。

我已经尝试过诸如--force-unsafe-io甚至--force-all标志 之类的事情dpkg，但没有任何效果。

Answer 1

您看到的行为archives.c在dpkg源代码第 1030 行（版本 1.18.1）中实现：

debug(dbg_eachfiledetail, "tarobject nondirectory, 'link' backup");
if (link(fnamevb.buf,fnametmpvb.buf))
  ohshite(_("unable to make backup link of '%.255s' before installing new version"),
          ti->name);

在我看来，您可以通过回退到第 1003 行及以下使用的重命名行为来处理链接失败；类似的东西（这是未经测试的）：

debug(dbg_eachfiledetail, "tarobject nondirectory, 'link' backup");
if (link(fnamevb.buf,fnametmpvb.buf)) {
  debug(dbg_eachfiledetail,"link failed, nonatomic");
  nifd->namenode->flags |= fnnf_no_atomic_overwrite;
  if (rename(fnamevb.buf,fnametmpvb.buf))
    ohshite(_("unable to move aside '%.255s' to install new version"),
            ti->name);
}

不过，我不是dpkg专家......（并且没有可用的选项dpkg来提供这种行为。）