dpkg substituindo arquivos em um sistema de arquivos FAT

19

Ao atualizar ou reinstalar um pacote com dpkg (e, por fim, qualquer coisa que o use, como o apt-get, etc), ele faz backup dos arquivos existentes criando um link físico para o arquivo antes de substituí-lo. Dessa forma, se o desempacotamento falhar, ele poderá facilmente recuperar os arquivos existentes. Isso é ótimo, já que protege o sistema operacional do Bad Things ™ acontecendo.

Exceto ... ele só funciona se o seu sistema de arquivos suportar hard links . Nem todos os sistemas de arquivos - como sistemas de arquivos FAT.

Estou trabalhando em uma distribuição do Debian para uma plataforma ARM embarcada específica, e o ambiente de inicialização requer que certos arquivos (o kernel incluído) 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 tenha arquivos naquela 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.

Eu vasculhei 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 tentar novamente", e sim, isso corrige esse problema específico.

Mas essa não é a resposta para mim. Eu sou um distribuidor de sistema operacional, não um usuário do sistema operacional, então eu preciso de uma maneira de corrigir isso que não envolve o usuário final excluindo manualmente seus arquivos de kernel antes de fazer uma atualização. Eu preciso de uma maneira de dizer ao dpkg para "copiar, não hard link" para arquivos em / boot (ou todos os arquivos para todos os cuidados, embora isso atrapalhasse a operação de upgrade), ou melhor ainda "Se um hard link falhar, não reclame, apenas copie-o ".

Eu tentei coisas como --force-unsafe-io e até --force-all sinalizam para dpkg , mas nada tem efeito.

Eu preciso resolver isso com urgência, pois está bloqueando o lançamento de uma nova versão do sistema operacional para este sistema ...

    
por Majenko 07.06.2015 / 13:14

1 resposta

13

O comportamento que você está vendo é implementado em archives.c na dpkg source, 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 para o comportamento de renomear linhas usadas 1003 e seguintes; algo como (isso 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);
}

Não sou um especialista em dpkg ... (e não há nenhuma opção já disponível em dpkg para fornecer esse comportamento.)

    
por 07.06.2015 / 14:40