(2.8) をインストールし、unattended-upgradesプロセスが実行中です。
ただし、アップグレードをインストールしようとすると、次のエラーが発生し続けます。
Processing triggers for initramfs-tools (0.140) ...
update-initramfs: Generating /boot/initrd.img-5.10.0-18-amd64
pigz: abort: write error on <stdout> (No space left on device)
E: mkinitramfs failure pigz 28
update-initramfs: failed for /boot/initrd.img-5.10.0-18-amd64 with 1.
dpkg: error processing package initramfs-tools (--configure):
installed initramfs-tools package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
initramfs-tools
この問題は、次のコマンドを使用して古いカーネルイメージを手動で削除することで解決できます。ここ。
カーネルイメージの削除が機能しない場合（一度発生する）、いくつかの背景と解決策は次のとおりです。ここDebianの完全に古い90年代スタイルの電子メールベースのバグトラッカーでこれまで使用されていなかったバグレポートは次のとおりです。ここ。
私はDebian 11とKDEを使用しています。このようなことは長い間起こり、今でも何度も起こりました。これがなぜ（または調べる方法）？
自動的に削除されない場合は、ブートパーティションのディスク容量が不足してアップグレードが失敗した場合は、少なくとも上記のコマンドを使用して古いカーネルイメージを削除する必要があると思います。
ベストアンサー1
いくつかのコメントで指摘したように、どのカーネルイメージが必要であるか、必要でないかを判断するのはDebianの仕事ではありません。 Debian は、新しいバージョンをインストールする際にカーネルイメージを保存するために正しいアクションを実行しているため、新しいバージョンに問題がある場合は、以前のバージョンから起動できます。 Frost Schutzが自分のコメントで指摘したように、Arch Linuxには新しいカーネルイメージをインストールするときに古いカーネルイメージを削除するという問題があります。これは私の経験では非常に望ましくない動作です。一般的にはかなりうまくいきますが、必ずしもそうではありません。特に新しいカーネルでの回帰です。
この動作は、システムで何をしようとしているのか、設定方法、aptの使い方、新しいカーネルのインストールに使用する方法によって異なりますが、私はいつもそのままにすることにしました。新しいカーネルが正しく機能していることを確認した後、システムメンテナンスの一環としてカーネルを明示的に削除するまで、以前にインストールしたカーネルを使用しました。
しかし、私はあなたが安定したDebianでカーネルメタパッケージを使用していると思いますが、これは少し異なります。そして、アップグレードされたカーネルをインストールするたびに、新しいエントリがgrubブートリストに追加されると思います（例：initrd.img-4.15.0-191 to to initrd.img-4.15.0-192）。したがって、カーネルは削除するまでインストールされ続けるパッケージです。 Debian は、システム管理者が長期的に作業を行うのに十分なパーティションがあることを確認し、パーティションのサイズが問題になったときにスケジュールされたクリーンアップを実行するなど、簡単なことを知りたいと安全に話すことができます。
しかし、これは、それぞれの新しい画像が設置後約150MiBを占めるという点から完全に外れているため、実際の問題は単に/が小さすぎるということです。または、別の/bootパーティションを使用している場合は小さすぎます。詳細を提供していない設定によって異なりますが、これは主な問題です。
通常、この機能を使用すると、廃止されたapt autoremove古いパッケージを削除できるため、最も簡単なソリューションになります。毎日または毎週実行するスクリプトを作成するだけです。
/boot、initrd.img、System.map、およびvmlinux-ファイルを確認すると、それぞれ約22MiBで、リモートサーバーのグループあたり3つのファイルは約55MiBでそれほど大きくなりません。これは/ bootが実際には小さすぎることを示します。ただし、これは/および/bootの外観とは別のパーティションかどうかによって異なります。
環境を制御できない場合や、長期的に便利にするためにパーティションのサイズを変更できない場合は、apt autoremove自動アップグレードが実行された後に夜に実行するのがおそらく最善の選択です。またはapt-get autoremoveDebianがより古い場合。
いくつかのリモートサーバーを見てみると、現在のカーネルと以前のカーネルの2つを使用する傾向があることがわかりましたが、クリーンアップ操作が何なのか、aptで実行できる設定や構成なのか、それともスクリプトで書かれたのかはわかりません。遅く実行されるソリューション。これは間違いなく手動では行われません。
私はまた、Frost Schutzが個々のパーティションが非常に小さいサイズを提案している場合、多くの場合、テラバイト級のストレージスペースがありますが、列がないときに/ bootのサイズ変更に関するオンラインガイドラインは意味がないことに同意します。システム仕様なので、これは推測だけです。通常、質問を投稿するときは、質問に関する情報を投稿する必要があります。それ以外の場合は、人々が推測する必要があります。
長時間システムを実行する予定の場合は、使用容量の少なくとも2倍/使用容量が必要になります。 /bootが分離されている場合、時間の経過とともに各反復が約10％増加すると仮定し、各コアが占める量を計算すると、アクティブに保つコアの数が分離されたときに使用されるコアの数が決まります。 /boot は大きくなければなりません。セキュリティ上の理由からオーバーヘッドが追加されます。
また、もちろん、すべての更新後にapt-get cleanを実行したい場合があります。それ以外の場合は、/var/cache/apt が古いパッケージでいっぱいになります。