☰

アップグレード時に「ブロック」されるパッケージがほとんどないのはなぜですか？ [コピー]

tag-icon • tag-icon linux apt sudo package-management upgrade
アップグレード時に「ブロック」されるパッケージがほとんどないのはなぜですか？ [コピー]

時々、パッケージをアップグレードしようとすると、アップグレードされないパッケージはほとんどありません。

root@pc:/home/user# sudo apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  linux-headers-amd64 linux-image-amd64
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

システムがこれらのパッケージをアップグレードしないことにしたのはなぜですか？どのようにアップグレードできますか？

答え1

最も一般的な2つの理由は次のとおりです。

  1. 「予約済み」パッケージは、まだアーカイブで使用できない1つ以上のパッケージによって異なります。これは、Debian Sid、Debian Testing、またはその他の「ローリング」タイプのディストリビューションを使用する場合に最も一般的ですが、一般的なアップデートディストリビューションとセキュリティアップデートディストリビューションでも時々発生します。

    タイミングの問題です。パッケージがアップロードされ、アーカイブに承認され、ローカルストレージミラーに展開される時期。通常、1 日か 2 日以内に解決されますが、メジャーアップグレードが進行中である場合 (たとえば、KDE ​​または Gnome の新しいバージョンまたは多くのパッケージが含まれている場合)、1 つのパッケージが他のパッケージを大量に占める場合、時間がかかることがあります。 。バッグ。

    心配する価値はありません。数日待ってからapt updateやり直してくださいapt upgrade。apt dist-upgrade

  2. 一部のパッケージを手動でアーカイブしました（例：を使用してapt-mark hold）。を使用してこの問題を直接解決できますapt-mark unhold。

    ちなみに、特にまたは同じDKMSパッケージを使用している場合とlinux-headers-amd64その両方を維持することをお勧めします。新しいカーネルと競合したり、新しいカーネルと連携したりするには、新しいパッチが必要な場合があります。linux-image-amd64nvidia-kernel-dkmszfs-dkmsいいえこれらのDKMSパッケージが新しいカーネルにコンパイルされることがわかるまで、カーネルをアップグレードしてください。また、パッケージ*dkms*も維持する必要があり、手動でのみアップグレードできます。その後、次のように手動でアップグレードして再び維持できます。

     apt-get install linux-image-amd64 linux-headers-amd64 ; apt-mark hold linux-image-amd64 linux-headers-amd64

apt-cache（特にコマンドshowとpolicyサブコマンド）と（有用なコマンドとサブコマンドaptitudeがある）を使用して、システムの実際の原因調査を開始できます。たとえば、次のようにします。whywhy-not

apt-cache show linux-image-amd64
apt-cache policy linux-image-amd64

aptitude why-not linux-image-amd64
aptitude why linux-image-amd64

出力を解釈するには、マニュアルをapt読んで理解する必要があります。dpkgほとんどは非常にシンプルで明確ですが、一部はそうではありません。特に、出力はaptitude why各出力行の先頭にあるコード文字を理解する必要があります。

関連情報