dpkg 替換 FAT 文件系統上的文件
當您使用
dpkg
(以及最終使用它的任何東西,如 apt-get 等)升級或重新安裝軟體包時,它會通過在替換文件之前創建指向文件的硬連結來備份現有文件。這樣,如果解包失敗,它可以很容易地放回現有文件。太好了,因為它可以保護作業系統免受 Bad Things™ 的影響。除了…它僅在您的文件系統支持硬連結時才有效。並非所有文件系統都這樣做 - 例如 FAT 文件系統。
我正在為特定的嵌入式 ARM 平台開發 Debian 發行版,並且引導環境要求某些文件(包括核心)位於 FAT 文件系統上,以便引導程式碼能夠找到並載入它們。
當您升級核心包(或任何其他在該 FAT 分區中有文件的包)時,安裝失敗並顯示:
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
並且整個升級失敗。
我在網上搜尋過,我能找到的唯一參考資料是在進行特定升級時遇到特定問題的特定人員,其答案通常是“刪除 /boot/vmlinuz-3.18.11+ 並重試”,是的,那個解決了該特定問題。
但這不是我的答案。我是 OS 分銷商,而不是 OS 使用者,所以我需要一種方法來解決這個問題,而不需要最終使用者在升級之前手動刪除他們的核心文件。我需要一種方法來告訴 dpkg 為 /boot 上的文件“複製,而不是硬連結”(或我關心的所有文件,儘管這會稍微減慢升級操作),或者更好的是“如果硬連結失敗,不要抱怨,只是複制它”。
我已經嘗試過諸如 the
--force-unsafe-io
甚至--force-all
flags之類的東西dpkg
,但沒有任何效果。
您看到的行為
archives.c
在dpkg
原始碼第 1030 行(對於版本 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);
在我看來,您可以通過使用第 1003 行及以下的重命名行為來處理連結故障;類似的東西(這是未經測試的):
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); }
雖然我不是
dpkg
專家……(並且已經沒有dpkg
提供這種行為的選項。)