Linuxカーネルがパニックを起こすと、OS提供者として私たちも次にパニックに陥ることになります。それは、チームが他のすべてを放置して、即座に水の中に飛び込み、問題を修正しなければならないという自動的なトリガーです。修正が見つからなければ、災難が待っています。

オペレーティングシステムが起動しない場合、残された選択肢は限られています。コマンドを実行したり、診断ツールを実行したりするための稼働中のシステムがなく、ログを表示するための操作可能なコンソールも、リモートアクセスのためのインターネット接続もありません。このような場合にこそ、古典的なシリアルコンソールが役立ちます。高級サーバーでは、通常BMC/IPMIがあり、これがアウトオブバンドチャネルとして機能し、シリアル接続を介してターゲットマシンと対話できます。もしこれを持っていない場合、ネットワークアクセス可能なIP-VGAやD.I.Y.スタイルのコンソールサーバー（1対多数のRS232インターフェースを持つ）でも同じ目的を果たすことができます。最終手段として、KVMモニターの前で現場に出向き、クライアントが近くにいないことを祈りながら作業することになります。

私が遭遇したほとんどのカーネルパニックのケースでは、問題はドライバ、特にファイルシステム用のドライバに関連していました。Linuxのルート（/）フォルダおよびそのサブフォルダやファイルは、通常、ディスクドライブのフォーマットされたパーティションに存在するファイルシステムに格納されています。電源ボタンが押されると、BIOS/UEFIが起動し、そのブート順に基づいてOSの読み込みと実行を試みます。ファイルシステムを認識するためには、実行中のシステムが必要なドライバを読み込む必要があります。実行中のシステムは通常、initramfsであり、これはメモリに読み込むのに十分小さく、仮のオペレーティングシステムとして機能します。

initramfsが正常に実行できる場合、物事はそれほど悪くはありません。少なくとも、Linuxカーネルパラメータを追加または変更することで、ブートストラップのさまざまな段階に進むことができます。この方法は、Linuxのランレベルのように機能し、どのステップで問題が発生しているのかを調査するのに役立ちます。以下は私のチェックポイントです：

• ドライバが不足しているか？
• パスは正しいか？
• ドライバはロードされているか？
• ハードディスクは検出されているか？
• ファイルシステムは認識されているか？
• フォルダはマウントされ、内容が含まれているか？
• 必要な値を持つ環境変数は設定されているか？
• switchrootは成功しているか？

具体的な例を挙げて解説することもできますが、今日は上記のヒントがうまくいかないケースについて扱っています。

画像出典：Bigstack CubeCOS画像出典：Bigstack CubeCOS

initramfsが展開された直後に、カーネルがダウンしました。initramfsに組み込んだドライバーに一致するドライバーがリストされましたが、なぜパニックが発生したのかは分かりませんでした。少なくとも、私には理解できませんでした。

いくつかのLinuxブートパラメータ（initramfs_size、acpiなど）をいじりましたが、うまくいきませんでした。その後、メモリやドライブ、マザーボードの故障の可能性を排除しました。なぜなら、既存のOSはまだ動作していたからです。幸いにも、CI/CDパイプラインのおかげで、最新のファームウェアがまだ動作していることが確認できました。それで、最後の正常動作ビルドから今日までの変更セットの違いを確認しましたが、特に目立ったものは見つかりませんでした。最終的に、パッケージ化されたファームウェアを開けて比較したところ、カーネルのバージョンがわずかに異なることに気付きました：kernel-4.18.0-348とkernel-4.18.0-373。ビルドプロセスでは、rpmパッケージマネージャーを使用して、提供されたリポジトリに基づいて依存関係を解決し、パッケージをインストールします。これにはいくつかの利点があり、最新のパッケージに追いつくことができると同時に、ソースコードリポジトリのスペースや、独自のrpmリポジトリを維持する手間を省くことができます。その一方で、クライアントサイトに展開されたシステムにパッチやホットフィックス、修正パッケージを適用する際には、問題を引き起こすこともあります。新しいビルドは、潜在的に異なるものとなり、この場合は、わずかな差異がファームウェアインストール中にカーネルパニックを引き起こす原因となりました。

原因を突き止めた後、私は、管理が不安定な可能性がある重要なカーネルパッケージをロックすることに決めました。

    sh-4.4# dnf install -y 'dnf-command(versionlock)'
    sh-4.4# dnf -y install kernel-core-4.18.0-348.el8.x86_64 kernel-modules-4.18.0-348.el8.x86_64 kernel-headers-4.18.0-348.el8.x86_64 kernel-4.18.0-348.el8.x86_64 kernel-modules-extra-4.18.0-348.el8.x86_64

    sh-4.4# dnf list installed | grep kernel | tr -s ' '
    kernel.x86_64 4.18.0-348.el8 @baseos
    kernel-core.x86_64 4.18.0-348.el8 @baseos
    kernel-headers.x86_64 4.18.0-348.el8 @baseos
    kernel-modules.x86_64 4.18.0-348.el8 @baseos
    kernel-modules-extra.x86_64 4.18.0-348.el8 @baseos

次に、カーネルパッケージをロックリストに追加するために「dnf versionlock add」を使用します。

    sh-4.4# dnf versionlock list
    Last metadata expiration check: 0:28:02 ago on Thu 21 Apr 2022 06:06:00 PM CEST.
    kernel-0:4.18.0-348.el8.*
    kernel-core-0:4.18.0-348.el8.*
    kernel-modules-0:4.18.0-348.el8.*
    kernel-modules-extra-0:4.18.0-348.el8.*
    kernel-headers-0:4.18.0-348.el8.*

    ship$ sudo dd if=CUBE_2.2.4_20220421-1616_55765df7.img of=/dev/sda bs=4M
    1459+1 records in
    1459+1 records out
    6122962944 bytes (6.1 GB, 5.7 GiB) copied, 505.694 s, 12.1 MB/s

その後、デーモン、rados-ng/rados-kv、設定ファイルを提供する2つの主要なパッケージが登場します。

    sh-4.4# dnf -y install nfs-ganesha-ceph.x86_64 nfs-ganesha-rados-grace

次に、USBに保存された新しくビルドしたファームウェアを挿入し、NUCの電源を再起動してUSBドライブからブートします。これでパニックポイントを通過し、ブートプロセスを正常に完了することができました。

画像出典：Bigstack CubeCOS