dpkg zastępuje pliki w systemie plików FAT

Kiedy uaktualniasz lub ponownie instalujesz pakiet za pomocą dpkg(i ostatecznie wszystkiego, co go używa, takiego jak apt-get itp.), Tworzy kopię zapasową istniejących plików, tworząc twardy link do pliku przed jego zastąpieniem. W ten sposób, jeśli rozpakowanie nie powiedzie się, można łatwo przywrócić istniejące pliki. To świetnie, ponieważ chroni system operacyjny przed działaniem Bad Things ™.

Z wyjątkiem ... to działa tylko wtedy, gdy twój system plików obsługuje twarde linki . Nie wszystkie systemy plików - na przykład systemy plików FAT.

Pracuję nad dystrybucją Debiana dla konkretnej wbudowanej platformy ARM, a środowisko rozruchowe wymaga, aby niektóre pliki (łącznie z jądrem) znajdowały się w systemie plików FAT, aby kod rozruchowy mógł je zlokalizować i załadować.

Gdy przejdziesz do aktualizacji pakietu jądra (lub innego pakietu zawierającego pliki na tej partycji FAT), instalacja nie powiedzie się:

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

Cała aktualizacja kończy się niepowodzeniem.

Przeszukałem Internet, a jedyne odniesienia, które mogę znaleźć, to konkretne osoby z konkretnymi problemami podczas wykonywania określonych aktualizacji, na które zazwyczaj odpowiada „Usuń /boot/vmlinuz-3.18.11+ i spróbuj ponownie”, i tak, że naprawia ten konkretny problem.

Ale to nie jest dla mnie odpowiedź. Jestem dystrybutorem systemu operacyjnego, a nie użytkownikiem systemu operacyjnego, dlatego potrzebuję sposobu, aby to naprawić, co nie wymaga od użytkownika końcowego ręcznego usuwania plików jądra przed wykonaniem aktualizacji. Potrzebuję sposobu, aby powiedzieć dpkg, aby „kopiowało, a nie twarde łącze” dla plików na / boot (lub dla wszystkich plików, na których mi zależy, choć nieco to by spowolniło aktualizację), lub jeszcze lepiej „Jeśli twardy link zawiedzie, nie narzekaj, po prostu skopiuj go zamiast tego ”.

Próbowałem takich rzeczy, jak --force-unsafe-ioi nawet --force-allflagi dpkg, ale nic nie ma żadnego wpływu.

Zachowanie widzisz jest realizowany archives.cw dpkgźródle, linia 1030 (dla wersji 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);

Wydaje mi się, że można poradzić sobie z awarią łącza, powracając do zachowania zmiany nazwy używanego wiersza 1003 i kolejnych; coś w stylu (jest to niesprawdzone):

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

Nie jestem jednak dpkgekspertem ... (I nie ma już dostępnej opcji dpkgzapewniającej takie zachowanie).