パッケージ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のファイル(または関心のあるすべてのファイル、アップグレード作業が少し遅くなりますが)に「ハードリンクではなくコピー」を指示するか、「ハードリンクが失敗した場合」より良い方法が必要です。文句を言ったら、コピーしてください。」
私はマークの--force-unsafe-io
ようなものを試しましたが、何も機能しません。--force-all
dpkg
答え1
あなたが見ている動作はソースコードに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