dpkg substituindo arquivos em um sistema de arquivos FAT

Quando você atualiza ou reinstala um pacote com dpkg(e, finalmente, qualquer coisa que o use, como apt-get etc), ele faz backup dos arquivos existentes, criando um link físico para o arquivo antes de substituí-lo. Dessa forma, se a descompactação falhar, poderá facilmente colocar de volta os arquivos existentes. Isso é ótimo, pois protege o sistema operacional das coisas ruins que acontecem.

Exceto ... só funciona se o seu sistema de arquivos suportar links físicos . Nem todos os sistemas de arquivos funcionam - como os sistemas de arquivos FAT.

Estou trabalhando em uma distribuição do Debian para uma plataforma ARM incorporada específica, e o ambiente de inicialização exige que certos arquivos (incluindo o kernel) estejam em um sistema de arquivos FAT, para que o código de inicialização possa localizá-los e carregá-los.

Quando você vai atualizar o pacote do kernel (ou qualquer outro pacote que possua arquivos nessa partição FAT), a instalação falha com:

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

E toda a atualização falha.

Examinei a web e as únicas referências que posso encontrar são pessoas específicas com problemas específicos ao fazer atualizações específicas, cuja resposta geralmente é "Excluir /boot/vmlinuz-3.18.11+ e tente novamente" e sim, isso corrige esse problema específico.

Mas essa não é a resposta para mim. Como sou um distribuidor de SO, não um usuário de SO, preciso de uma maneira de corrigir isso que não envolva o usuário final excluindo manualmente seus arquivos do kernel antes de fazer uma atualização. Eu preciso de uma maneira de dizer ao dpkg para "copiar, não vincular" para arquivos em / boot (ou todos os arquivos que eu me importo, embora isso atrasasse um pouco a operação de atualização), ou melhor ainda "Se um link físico falhar, não reclame, apenas copie-o ".

Eu tentei coisas como as bandeiras --force-unsafe-ioe até mesmo , mas nada tem efeito.--force-alldpkg

O comportamento que você está vendo é implementado em archives.cna dpkgfonte, linha 1030 (para a versão 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);

Parece-me que você poderia lidar com a falha do link voltando ao comportamento de renomeação das linhas 1003 e seguintes; algo como (isto não foi testado):

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

Eu não sou um dpkg especialista ... (E ainda não há uma opção disponível dpkgpara fornecer esse comportamento.)