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

升级或重新安装软件包时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标志to之类的事情dpkg，但是没有任何效果。

你看到的是在实施的行为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提供这种行为的选项。）