ファイルを含む残りのカーネルディレクトリ

ファイルを含む残りのカーネルディレクトリ

カーネル残留があるのはなぜですか?自動的に消去できますか?


数ヶ月が過ぎると、カーネルディレクトリが多すぎて迷惑になりました。

ディレクトリをもう一度確認し/usr/lib/modules、以前のカーネルディレクトリの1つだけを削除し、実際の内容を確認しました。

# \ls -lhkF 5.15.0-76-generic

total 28K
drwxr-xr-x 2 root root 4.0K Aug 24 06:36 misc/
-rw-r--r-- 1 root root   45 Aug 24 06:36 modules.alias
-rw-r--r-- 1 root root   12 Aug 24 06:36 modules.alias.bin
-rw-r--r-- 1 root root    0 Aug 24 06:36 modules.builtin.alias.bin
-rw-r--r-- 1 root root    0 Aug 24 06:36 modules.builtin.bin
-rw-r--r-- 1 root root    0 Aug 24 06:36 modules.dep
-rw-r--r-- 1 root root   12 Aug 24 06:36 modules.dep.bin
-rw-r--r-- 1 root root    0 Aug 24 06:36 modules.devname
-rw-r--r-- 1 root root   55 Aug 24 06:36 modules.softdep
-rw-r--r-- 1 root root   49 Aug 24 06:36 modules.symbols
-rw-r--r-- 1 root root   12 Aug 24 06:36 modules.symbols.bin

残りのファイルを確認すると、そのファイルが空であるか役に立たないことがわかります。

# for file in *; do [ -f $file ] && echo "$file": && cat --show-nonprinting $file && echo && echo; done

modules.alias:
# Aliases extracted from modules themselves.


modules.alias.bin:
M-0^GM-tW^@^B^@^A^@^@^@^L

modules.builtin.alias.bin:


modules.builtin.bin:


modules.dep:


modules.dep.bin:
M-0^GM-tW^@^B^@^A^@^@^@^L

modules.devname:


modules.softdep:
# Soft dependencies extracted from modules themselves.


modules.symbols:
# Aliases for symbols, used by symbol_request().


modules.symbols.bin:
M-0^GM-tW^@^B^@^A^@^@^@^L

今私の質問はなぜこれらのファイルが削除されないのですかapt-get --purge autoremove

ベストアンサー1

このmisc/ディレクトリは、管理システムがカーネルバージョンのインストールと削除を完全に統合できない一部のサードパーティモジュール(VirtualBoxなど)に使用できます。

/lib/modules/$(uname -r)/misc問題のあるモジュールを特定するには、現在実行中のカーネルのディレクトリを確認してください。

これらのmodules.*ファイルは、コマンドによって生成されたさまざまなモジュールのエイリアス、依存関係、およびシンボルマップファイルですdepmod

カーネルパッケージが削除されると、パッケージマネージャはカーネルパッケージ(場所)と共にパッケージ化されたモジュールを自動的に削除しますが、サードパーティのモジュールインストーラ/lib/modules/<kernel version>/kernel/(たとえば、あなたのもの)によってmisc/作成されたモジュールとモジュールディレクトリには触れません。 DKMSが管理するサードパーティ製モジュールを使用している場合は、通常これらのモジュール/lib/modules/<kernel version>/updates/dkms/そのカーネルパッケージが削除されると、自動的に削除されます。

サードパーティのモジュール管理は少し簡単なようです。起動時に実行され、既存のディレクトリ/lib/modules/<kernel version>/misc/サブディレクトリとサードパーティモジュールを確認し、欠落しているものがある場合は自動的にサードパーティモジュールのバージョンをビルドして実行します。depmod <kernel version>サードパーティモジュールの依存関係が正しく処理されていることを確認してください。ただし、モジュールが削除されるセクションとmisc/カーネルパッケージが削除されるサブディレクトリは、実装されていないか欠落しているようです。

実際のカーネルパッケージの内容が削除されてもディレクトリに生成されたファイルが更新されるように見えるため、サードパーティのモジュールdepmod管理スクリプトは既存のディレクトリを/lib/modules/<kernel version>繰り返しながらdepmod各ディレクトリで実行され続けるようです。その結果、空またはほぼ空の出力depmodファイルが生成されます。

/etc/kernel/postrm.d/この問題を自動的に削除するには、次のスクリプトを追加できます(zz-remove-miscmod例:呼び出し)。

#!/bin/sh -e

version="$1"

# passing the kernel version is required
if [ -z "${version}" ]; then
    echo >&2 "W: zz-remove-miscmod: ${DPKG_MAINTSCRIPT_PACKAGE:-kernel package} did not pass a version number"
    exit 0
fi

if [ -d "/lib/modules/$version/misc" ]; then
    rm -rf "/lib/modules/$version/misc"

    # uncomment to remove the modules.* files too, if necessary
    #rm -f "/lib/modules/$version/modules.*" 2>/dev/null || /bin/true

    # attempt to remove the kernel version module directory too,
    # in case it just became empty; if not, ignore the error
    rmdir "/lib/modules/$version" 2>/dev/null || /bin/true
fi

このスクリプトはカーネルパッケージが削除された後に自動的に実行され、削除されたバージョンのカーネルを持つサブディレクトリがあることを確認して削除しますmisc。生成されたファイルは、次回の起動時に(再び)生成されると仮定しますdepmod。私が間違っている場合は、そのrm -f ...行のコメントを外すこともできます。

おすすめ記事