SLESブートモジュールのロード失敗：ドライバを見つけて修正する

SLES の起動時に「カーネルモジュールのロード開始に失敗しました」というエラーが表示された場合は、まずsystemd-modules-load.serviceログを調べて失敗したモジュールを特定してください。そのモジュールが廃止されたオプションのエントリである場合は、設定からその要求を削除してください。必須のモジュールである場合は、サービスを無効にするのではなく、ドライバまたはカーネルの不一致を修復してください。

この手順は、SUSE Linux Enterprise Server (SLES) 15 に適用され、SLES 15 SP7 の管理ドキュメントを参照します。コマンドは、ローカルコンソールまたはsudoアクセス権限のある動作中の SSH セッションから実行する必要があります。

変更を加える前に、メッセージの意味を理解しましょう

カーネルモジュールとは、個別にロードできるドライバまたはカーネル機能のことです。起動時に、ファイルsystemd-modules-load.serviceで定義されているものを含め、特定のモジュールをロードする要求を処理しますmodules-load.d。要求が失敗すると、サーバーの他の部分が動作を続けていても、そのサービスが停止する可能性があります。

SUSEによると、ほとんどのドライバはハードウェアが検出されると自動的にロードされます。通常、手動でモジュールリストを作成する必要はありません。そのため、古いエントリが存在する可能性は十分にありますが、ブートメッセージだけではそれを証明することはできません。コンソールへのアクセスを維持し、可能であればシステムのスナップショットまたは構成のバックアップを取得し、警告を消すためだけにストレージ、ネットワーク、またはクラスタドライバをアンロードしないでください。サポートされているモデルについては、 SUSEのカーネルモジュール管理ガイドを参照してください。

ステップ1：サービスの状態と起動ログを確認する

まず、systemd のステータスを確認してください。systemd は、systemdサービスを開始し、その状態を報告する役割を担うサービスマネージャです。

sudo systemctl status systemd-modules-load.service --no-pager
sudo journalctl -b -u systemd-modules-load.service --no-pager

この-bフラグはjournalctl現在の起動に限定し、-uこのサービスを選択します。「Failed with result」行の最後に、「Failed to find module」、無効なオプション、権限エラーまたは署名エラーなどのメッセージがないか確認してください。正確なモジュール名とエラーテキストを記録してください。以下の例で示されているモジュールがサーバー上に存在するとは限りません。

サービスログに決定的な情報が得られない場合は、カーネルメッセージを確認して詳細を確認してください。

sudo journalctl -k -b --no-pager

コンピュータが使用可能なログイン画面に到達できない場合は、GRUB から利用可能な古いインストール済みカーネルを起動するか、SLES レスキュー メディアを使用してください。テストされていないリモート専用セッションから起動に不可欠なモジュールを編集しないでください。SUSE のjournalctl 管理の章でジャーナル フィルタについて説明しています。

ステップ2：それを要求している起動構成を見つける

ジャーナル名が であると仮定しますexample_driver。そのプレースホルダーを実際のモジュール名に置き換えてから、モジュールリストを検索します。

sudo grep -Rns --include='*.conf' 'example_driver' \
  /etc/modules-load.d /run/modules-load.d \
  /usr/lib/modules-load.d 2>/dev/null

一致する各行は、起動時にそのモジュールを要求するファイルを示しています。管理者のローカル設定は通常 にありますが/etc/modules-load.d/、パッケージは の下にファイルを提供する場合があります。SUSE のsystemd 設定ガイド/usr/lib/modules-load.d/に記載されているように、同じベース名のローカルファイルはベンダーファイルよりも優先されます。検索で何も見つからない場合は、起動時のモジュール要求も調べ、エラー名が正しくコピーされていることを確認してください。cat /proc/cmdline

該当するファイルを開き、そのエントリがハードウェアまたはアプリケーションでまだ必要かどうかを確認します。古い、または削除されたデバイス用に要求されたモジュールは、ストレージコントローラドライバやクラスタウォッチドッグとは異なります。

ステップ3：モジュールをテストし、対応する修復を適用する

実行中のカーネルと、そのカーネルに対応するドライバが利用可能かどうかを確認します。modprobeカーネルモジュールをロードし、依存関係を解決します。-nオプションを指定すると、カーネルを挿入せずにドライランを実行します。

uname -r
modinfo example_driver
sudo modprobe -n -v example_driver

再度、 を置き換えてくださいexample_driver。ドライランは、検索または構成の問題を特定するのに役立ちますが、ドライバがハードウェアで正常に初期化されることや、セキュアブート署名チェックに合格することを証明するものではありませんmodprobe。SUSE は、直接ロードするのではなくを使用することを推奨しています。insmodドライランフラグの詳細は、modprobe マニュアルに記載されています。

廃止されたオプションのエントリが、存在しないモジュールを指している場合

特定のローカルファイルをバックアップし、不要になった行のみをコメントアウトします。たとえば、/etc/modules-load.d/example.conf確認済みのソースが次のようになっている場合：

sudo cp -a /etc/modules-load.d/example.conf \
  /etc/modules-load.d/example.conf.bak
sudoedit /etc/modules-load.d/example.conf

単一のexample_driverエントリを に変更して# example_driver保存し、他のモジュール要求はそのままにしておきます。ソースが の下にあるパッケージ ファイルの場合は、そのパッケージ ファイルを直接編集しないでください。適切にレビューされたローカル オーバーライドを使用するか、パッケージの設定を修正してください。対応するデバイスが必要な場合に がモジュール要求が見つからないと報告した/usr/libという理由だけで、モジュール要求を削除しないでください。modinfo

必要なモジュールが見つからないか、互換性がない場合

コメントアウトしないでください。ドライバパッケージが、uname -rおよびインストールされているSLESサービスパックの出力をサポートしていることを確認してください。「モジュールが見つかりません」というメッセージは、一致するドライバがインストールされていないか、カーネル更新後に再構築されていないことを示している可能性があります。「無効なモジュール形式」というメッセージは、互換性の問題を示唆しています。カーネルログ行を確認することで、さらに絞り込むことができます。SUSEまたはハードウェアベンダーの指示に従って、サポートされている一致するドライバを復元または再インストールしてください。.ko別のカーネルから任意のファイルをコピーしないでください。

モジュールは存在するものの、その依存関係インデックスが明らかに古い場合は、現在のカーネル用にそのインデックスを再構築し、ドライランを再試行します。

sudo depmod -a "$(uname -r)"
sudo modprobe -n -v example_driver

この手順では、不足しているドライバはインストールされません。セキュアブートシステムで「必要なキーが利用できません」またはモジュール署名が拒否された場合は、SUSEの信頼済みキー登録およびドライバ署名ワークフローに従ってください。一般的な回避策としてセキュアブートを無効にしないでください。SUSEは、セキュアブート展開ガイドでサードパーティ製ドライバの制限について説明しています。

ステップ4：次の起動が正常であることを確認する

設定を修正するかドライバを復元した後、ローダーを再試行してその状態を確認してください。これは、残りのエントリがすべて適切であることを確認した後にのみ実行してください。再起動すると、設定されたロードが再度試行されます。

sudo systemctl restart systemd-modules-load.service
sudo systemctl status systemd-modules-load.service --no-pager
sudo journalctl -b -u systemd-modules-load.service --no-pager

ユニットが正常に動作した場合は、コンソールアクセス付きの制御された再起動をスケジュールし、ステータスコマンドとジャーナルコマンドを再度実行してください。新しい起動時にサービスが失敗しなくなり、モジュールに依存する必要なハードウェアまたはソフトウェアが正常に動作すれば、修正が成功したと判断できます。エラーが再発する場合は、新しいログと古いログを比較してください。リストされている別のモジュールにも障害が発生している可能性があります。このチェックが完了するまでバックアップを保持してください。systemd-modules-load.service起動メッセージを抑制するためだけにマスクしないでください。