SLES起動時の「カーネルモジュールのロード開始に失敗しました」エラーを修正する

SLESの起動メッセージ「カーネルモジュールのロードに失敗しました」は、通常systemd-modules-load.service、少なくとも1つのカーネルモジュールのロードを試みたものの、1つの要求が失敗したことを意味します。重要なのは、赤い起動メッセージを隠すことだけではありません。適切な修復を行うことで、サービスを正常な状態に保ち、不要なモジュール要求を削除し、マシンが実際に必要とするドライバを保持し、次回の再起動後も正常に動作するようにする必要があります。

このガイドは SUSE Linux Enterprise Server 15 向けに作成されており、最新の SLES 15 SP7 管理ガイドに準拠しています。SUSE のドキュメントでは、systemd-modules-load.serviceに指定されたモジュールがロードされる/etc/modules-load.d/*.conf一方、ほとんどの最新のハードウェア モジュールは、デバイスが検出されると通常自動的にロードされると説明されています。この違いは重要です。古い静的エントリが存在しないモジュールを指している場合、古いドライバをシステムに強制的に戻すよりも、そのエントリを削除または修正する方が安全な場合が多いです。SLES 15 SP7 の SUSE のカーネル モジュールの管理に関するドキュメントを参照してください。

成功した修復とはどのようなものか

変更を加える前に、希望する結果を明確に定義してください。修理後：

• systemctl status systemd-modules-load.service失敗結果を報告すべきではない。
• 新規起動時には、ジャーナルに同じモジュール読み込みエラーが表示されなくなるはずです。
• そのモジュールが本当に必要な場合、modprobe MODULE_NAME正常にインストールされ、関連するハードウェアまたは機能が正常に動作するはずです。
• モジュールが廃止されている場合は、無関係なモジュールに置き換えるのではなく、古いリクエストを削除する必要があります。
• 問題が起動初期段階に関係している場合は、initramfsを再構築すれば、マシンは正常に再起動を完了するはずです。

これらのチェック項目がすべてお客様の状況に当てはまらない場合は、障害が発生しているコンポーネントに一致する項目を使用してください。たとえば、オプションモジュールが故障していても、サーバーが正常に起動する場合があります。それでもクリーンアップする価値はありますが、ルートファイルシステムが表示されない原因となっているストレージドライバの欠落とは異なります。

ステップ1：故障したユニットを確認し、正確なモジュールエラーを取得します。

スプラッシュスクリーンのメッセージから推測するのではなく、サービス自体から始めてください。

sudo systemctl status systemd-modules-load.service --no-pager

モジュール名と、、、などのエラーメッセージ、またはサポートされていないモジュールが拒否されたことを示すメッセージを探してくださいModule ... not found。No such device表示Operation not permittedされる正確な文言によって、次に取るべき行動が決まります。

ステータス出力が途中で途切れている場合は、まだ設定を変更しないでください。まず完全なブートログを取得してください。

ステップ2：モジュールファイルを変更する前にブートジャーナルを読み込む

現在の起動時に、このサービスのみを照会します。

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

モジュールの読み込みに関するカーネルメッセージを調べることもできます。

sudo journalctl -b -k --no-pager | grep -iE 'module|modprobe|firmware|taint'

最初のコマンドは、どの静的ロード要求が失敗したかを示します。カーネルログには、検出されたデバイスを拒否するドライバ、ファームウェアの依存関係、署名の問題、またはその他の低レベルのエラーなど、コンテキストが追加されます。

のような結果はModule foo not found in directory /lib/modules/...通常、古い構成、カーネル/パッケージの不一致、またはアクティブなカーネル用に再ビルドされていないサードパーティドライバを示しています。No such deviceは異なります。モジュールファイルは存在するかもしれませんが、現在のハードウェアまたは仮想デバイスがドライバの想定と一致しない可能性があります。

ステップ3：SLESにそのモジュールをロードするように要求しているユーザーを特定する

通常の静的ロード場所とmodprobe構成を検索します。

grep -Rns --color=auto 'MODULE_NAME'   /etc/modules-load.d /run/modules-load.d /usr/lib/modules-load.d   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

MODULE_NAMEジャーナルに記載されている名前に置き換えてください。SLES 15 SP7 では、ローカルエントリは/etc/modules-load.d/、起動時にロードする必要のあるモジュールの標準的な管理者管理場所であり、パッケージ化されたエントリは の下に存在できます/usr/lib/modules-load.d/。SUSE は、ほとんどのモジュールは、modules-load.d エントリを手動で作成する必要がないと述べています。

次に、アクティブなカーネルに実際にモジュールが含まれているかどうかを確認します。

uname -r
sudo modinfo MODULE_NAME
sudo modprobe MODULE_NAME

モジュールが廃止された場合

要求元のローカルファイルを削除または無効化してください。/usr/libエラーを解消するためだけにベンダーファイルを削除しないでください。パッケージの更新によって復元される可能性があります。ローカル/etc/modules-load.d/*.confファイルが廃止されたハードウェアまたは古いソフトウェア用に作成されたものであることが判明した場合は、そのローカルエントリを削除して再テストしてください。

モジュールが存在するはずなのに、modinfo で見つからない場合

実行中のカーネルがインストールされているモジュールツリーと一致しているか確認してください。

uname -r
ls -ld /lib/modules/$(uname -r)
rpm -q kernel-default

一般的な品質チェックは簡単です。/lib/modules/$(uname -r)実際に実行中のカーネルのモジュールが存在し、含まれている必要があります。サードパーティ製ドライバが古いカーネル用にコンパイルされている場合は、ベンダーがサポートする手順に従って、現在のSLESカーネルに対してドライバを再インストールまたは再構築してください。何かを見つける.koためだけに、別のカーネルバージョンからファイルをコピーすることは避けてくださいmodprobe。カーネルのABIや署名の違いにより、安全でなかったり、効果がなかったりする可能性があります。

モジュールがブラックリストに登録されている場合

ブラックリストを検索するか、オーバーライドをインストールしてください。

grep -Rns --color=auto -E '^[[:space:]]*(blacklist|install)[[:space:]]+MODULE_NAME'   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

ブラックリストを削除する際は、追加された理由を必ず確認してください。ブラックリストは、競合するドライバからシステムを保護するために設定されている場合があります。SUSEのモジュールガイドには、永続的なブラックリストとGRUB実行時の一時的なブラックリストの両方が記載されているため、ブラックリストを削除するのではなく、静的ロード要求を削除する方が適切な場合もあります。

SLESがサポートされていないモジュールを報告する場合

サポートされていないモジュールのロードを自動的に有効にしないでください。SLES はカーネルモジュールをサポートステータスとしてマークするため、サポートされていないモジュールを強制的にロードすると、サポートに影響が出る可能性があります。SUSE は、テストやベンダーのホットフィックスシナリオにおける例外メカニズムについて、管理ガイドで説明しています。サポートへの影響を理解し、正当なドライバ要件がある場合にのみ使用してください。最新の SUSE ガイドは、SLES 15 SP7 管理ガイドで入手​​できます。

ステップ4：初期ブートに影響する変更の場合のみinitramfsを再構築する

障害が発生したモジュールがinitramfs内で必要な場合、またはそこに反映させる必要のあるブートに不可欠なドライバやブラックリストの設定を変更した場合は、イメージを再生成してください。

sudo dracut -f

SUSE は、ブートに影響するドライバの変更後に initramfs を再構築する手順を具体的に文書化しています。現在のブート プロセス ガイドでは、ドライバを initramfs に追加する必要があるタイミングと、dracutそれを再生成するために使用する方法について説明しています。SLES 15 SP7 のブート プロセスの概要を参照してください。

オプションモジュールのエラーが発生するたびに、この手順をルーチンとして実行しないでくださいdracut -f。通常の起動後モジュールが単に にリストされている場合は/etc/modules-load.d、そのファイルを修正するだけで十分な場合があります。initramfs の再構築が最も重要なのは、不正な設定がブートイメージに組み込まれている場合、または実際のルートファイルシステムが完全にマウントされる前に必要なドライバが利用可能である必要がある場合です。

インシデントを解決済みとみなす前に、修理状況を確認してください。

安全が確保できる場合は、再起動せずに最初のテストを実施してください。

sudo systemctl restart systemd-modules-load.service
systemctl status systemd-modules-load.service --no-pager
systemctl is-failed systemd-modules-load.service

必要なモジュールをロードする必要がある場合は、確認してください。

lsmod | grep -w MODULE_NAME

その後、適切なメンテナンス期間中に再起動し、新しい起動状態を確認してください。

sudo reboot

ログイン後：

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

最も確実な成功の兆候は、コンソールメッセージが一度消えたことではありません。重要なのは、再起動後に同じモジュールエラーが再発せず、そのモジュールに依存するハードウェアまたはサブシステムが正常に動作することです。

アプローチを変えるタイミング

この修正の限界

「カーネルモジュールのロード開始に失敗しました」というメッセージは、単一の不具合ではなく、症状の一つです。この手順は、静的モジュール要求、モジュールの欠落または不一致、ブラックリスト、およびinitramfsの同期によって発生する障害に対処するものです。ハードウェア診断、サードパーティ製ドライバのサポート、セキュアブートの署名作業、またはルートデバイス自体が利用できない場合のストレージ復旧に代わるものではありません。

本番環境のSLESシステムでは、サポート性を維持するために、SLESカーネルに付属のモジュールを優先的に使用し、サードパーティ製ドライバはベンダーのサポートマトリックスに準拠させ、サービス障害を解消するためだけにチェックをバイパスするのではなく、SUSEのドキュメントに記載されているメカニズムを使用してください。サービスの状態、ブートジャーナル、および依存するハードウェアがすべて問題が解決したと判断した時点で、修復は完了です。