dpkg reemplazando archivos en un sistema de archivos FAT

Cuando actualiza o reinstala un paquete con dpkg(y, en última instancia, cualquier cosa que lo use, como apt-get, etc.), realiza una copia de seguridad de los archivos existentes creando un enlace rígido al archivo antes de reemplazarlo. De esa forma, si el desempaquetado falla, puede volver a colocar fácilmente los archivos existentes. Eso es genial, ya que protege el sistema operativo de que sucedan cosas malas.

Excepto ... solo funciona si su sistema de archivos admite enlaces duros . No todos los sistemas de archivos lo hacen, como los sistemas de archivos FAT.

Estoy trabajando en una distribución de Debian para una plataforma ARM incrustada específica, y el entorno de arranque requiere que ciertos archivos (el núcleo incluido) estén en un sistema de archivos FAT para que el código de arranque pueda localizarlos y cargarlos.

Cuando va a actualizar el paquete del kernel (o cualquier otro paquete que tenga archivos en esa partición FAT), la instalación falla con:

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

Y toda la actualización falla.

He explorado la web, y las únicas referencias que puedo encontrar son personas específicas con problemas específicos al realizar actualizaciones específicas, cuya respuesta generalmente es "Eliminar /boot/vmlinuz-3.18.11+ e intentar nuevamente", y sí, eso soluciona ese problema específico.

Pero esa no es la respuesta para mí. Soy un distribuidor del sistema operativo, no un usuario del sistema operativo, por lo que necesito una forma de solucionar esto que no implique que el usuario final elimine manualmente sus archivos del núcleo antes de realizar una actualización. Necesito una forma de decirle a dpkg que "copie, no enlace duro" para los archivos en / arranque (o todos los archivos para lo que me importa, aunque eso ralentizaría un poco la operación de actualización), o mejor aún "Si un enlace duro falla, no te quejes, solo cópialo ".

He intentado cosas como las banderas --force-unsafe-ioe incluso , pero nada tiene ningún efecto.--force-alldpkg

El comportamiento que está viendo se implementa en archives.cla dpkgfuente, línea 1030 (para la versión 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);

Me parece que podría manejar la falla del enlace volviendo al comportamiento de cambio de nombre utilizado en las líneas 1003 y siguientes; algo como (esto no se ha probado):

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);
}

Sin dpkgembargo, no soy un experto ... (Y ya no hay ninguna opción disponible dpkgpara proporcionar este comportamiento).