dpkg sostituisce i file su un filesystem FAT

Quando si aggiorna o si reinstalla un pacchetto con dpkg(e in definitiva tutto ciò che lo utilizza, come apt-get ecc.) Esegue il backup dei file esistenti creando un collegamento reale al file prima di sostituirlo. In questo modo, se la decompressione fallisce, può facilmente ripristinare i file esistenti. È fantastico, poiché protegge il sistema operativo da Bad Things ™.

Tranne ... funziona solo se il tuo filesystem supporta hard link . Non tutti i filesystem lo fanno - come i filesystem FAT.

Sto lavorando su una distribuzione di Debian per una specifica piattaforma ARM integrata, e l'ambiente di boot richiede che determinati file (incluso il kernel) siano su un filesystem FAT in modo che il codice di avvio sia in grado di localizzarli e caricarli.

Quando vai ad aggiornare il pacchetto del kernel (o qualsiasi altro pacchetto che ha file in quella partizione FAT) l'installazione non riesce 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

E l'intero aggiornamento fallisce.

Ho esplorato il Web e gli unici riferimenti che posso trovare sono persone specifiche con problemi specifici durante gli aggiornamenti specifici, la cui risposta è in genere "Elimina /boot/vmlinuz-3.18.11+ e riprova", e sì, quello risolve quel problema specifico.

Ma questa non è la risposta per me. Sono un distributore del sistema operativo, non un utente del sistema operativo, quindi ho bisogno di un modo per risolvere questo problema che non comporta che l'utente finale elimini manualmente i file del kernel prima di effettuare un aggiornamento. Ho bisogno di un modo per dire a dpkg di "copiare, non hard link" per i file su / boot (o tutti i file per quello che mi interessa, anche se ciò rallenterebbe in qualche modo l'operazione di aggiornamento), o meglio ancora "Se un hard link fallisce, non lamentarti, copialo invece ".

Ho provato cose come le --force-unsafe-ioe persino le --force-allbandiere dpkg, ma nulla ha alcun effetto.

Il comportamento che stai vedendo è implementata in archives.cnella dpkgfonte, la linea 1030 (per la versione 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);

Mi sembra che tu possa gestire l'errore di collegamento ricadendo sul comportamento di rinomina usato le righe 1003 e seguenti; qualcosa del genere (questo non è testato):

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

Non sono un dpkgesperto però ... (E non è già disponibile un'opzione dpkgper fornire questo comportamento.)