本番カーネルバージョン段階更新｜回帰検証・起動失敗検出・旧バージョン復旧の一貫フロー

なぜ本番カーネルの段階更新が必要か

月次のCVEパッチサイクルにおいて、カーネルアップデートは避けて通れない作業です。しかし、カーネルの差し替えはユーザーランドのパッケージ更新とは根本的に性質が異なります。ドライバーの互換性、カーネルパラメーターの挙動変化、あるいはセキュリティ機能の強化に伴うシステムコール制限など、更新後に初めて顕在化する問題が存在します。

実際、よくあるつまずきとして挙げられるのが「ステージング環境では問題なく動いていたのに、本番適用後に特定サービスが起動しなかった」というケースです。ハードウェア構成やカーネルモジュールの組み合わせが本番固有であることが多く、ステージングでの検証だけでは網羅しきれない部分が残ります。

そのため、本番環境でも段階的に展開し、各フェーズで回帰を検証しながら進める運用フローが標準的なアプローチとなっています。本記事では、GRUB2ブートローダーとsystemdを前提とした現行ディストリビューション（RHEL 9系・Ubuntu 22.04/24.04・Debian 12系）での手順を軸に解説します。

更新前の準備：カーネルエントリ管理と起動構成の確認

段階更新を安全に行うには、まず現在の起動構成を正確に把握しておく必要があります。GRUB2環境では、インストール済みのカーネルエントリは grubby --info=ALL（RHEL系）または grep -E "^menuentry" /boot/grub/grub.cfg（Debian/Ubuntu系）で確認できます。

現在のデフォルトカーネルは以下で確認します。

# RHEL/CentOS/AlmaLinux/Rocky Linux
grubby --default-kernel

# Debian/Ubuntu
grep GRUB_DEFAULT /etc/default/grub

新カーネルを適用する前に、現在の起動しているカーネルバージョンを必ず記録しておきます。

uname -r

また、サードパーティ製カーネルモジュール（NVIDIAドライバー、DKMS管理のモジュール等）がある場合は、新カーネル向けにビルドが完了しているかを事前に確認します。DKMSであれば dkms status で状態を把握できます。ここで未ビルドのモジュールが存在すると、更新後に起動はできても対象デバイスが認識されない問題につながります。

段階展開の手順：1台での検証から順次拡大へ

段階更新の基本は「1台で起動と機能を確認 → 同一役割のグループに展開 → 全体に適用」という流れです。以下は想定例として、Webサーバー10台構成の場合を示します。

想定例： Webサーバー10台にカーネルパッチを適用する場合、1台目に新カーネルをインストールし再起動、問題なければ同一役割の残り9台に展開するという流れを取ります。

新カーネルのインストール自体はパッケージマネージャーで行います。

# RHEL系（dnf）
dnf install kernel-6.x.x-xxx.el9.x86_64 --setopt=install_weak_deps=False

# Debian/Ubuntu系（apt）
apt install linux-image-6.x.x-xx-generic

インストール後、即座に再起動せず、次回起動時のデフォルトカーネルを新バージョンに設定します。RHEL系では grubby で明示的に指定できます。

# RHEL系：次回起動デフォルトを新カーネルに設定
grubby --set-default /boot/vmlinuz-6.x.x-xxx.el9.x86_64

# 設定の確認
grubby --default-kernel

Debian/Ubuntu系ではGRUBメニューのエントリ番号を /etc/default/grub の GRUB_DEFAULT で指定する方法が一般的ですが、エントリ番号はカーネル追加のたびに変わるため、サブメニューパス形式（例："Advanced options for Ubuntu>Ubuntu, with Linux 6.x.x"）の使用が推奨されます。変更後は update-grub を実行します。

起動後の回帰検証：自動チェックと手動確認の組み合わせ

再起動後、まず起動したカーネルバージョンを確認します。

uname -r

想定したバージョンで起動していることを確認したら、次の項目を順に検証します。

• systemdサービスの起動状態： systemctl --failed でfailedなユニットがないか確認します。
• カーネルログの異常： dmesg -l err,crit,alert,emerg でエラーレベル以上のメッセージが新たに出ていないか確認します。
• ネットワーク疎通： NICドライバーの互換性問題による疎通断が起きていないか確認します。
• アプリケーション動作： 対象サーバーが担うサービス（HTTPレスポンス、DBクエリ、ジョブキュー処理等）が正常に機能しているか確認します。
• DKMSモジュール： dkms status で全モジュールが新カーネル向けにビルド・インストール済みであるか確認します。

これらのチェックをスクリプト化しておくと、複数台への展開時に手順のブレを防げます。確認項目をexitコードで返す簡易ヘルスチェックスクリプトを用意し、Ansibleや任意の構成管理ツールから呼び出す構成が運用上は扱いやすいです。

一般的には、再起動直後のdmesgに kernel BUG や Call Trace が出力されている場合、カーネルパニックの予兆である可能性があります。この段階でエラーが確認できた場合は、次のフェーズ（他サーバーへの展開）に進まず、直ちに切り戻しを検討します。

起動失敗・回帰検出時の旧バージョン復旧手順

新カーネルで起動できない、あるいは起動後に重大な回帰が検出された場合の復旧フローを解説します。

GRUBメニューからの手動起動

物理コンソールまたはIPMI/iDRAC/iLO等のリモートコンソールにアクセスできる場合、GRUB起動画面で旧カーネルエントリを選択して起動できます。GRUBメニューが自動スキップされる環境では、起動時に Shift（BIOS）または Esc（UEFI）を押すことでメニューを表示できます。

デフォルトカーネルを旧バージョンに戻す

旧カーネルで正常起動を確認したあと、デフォルトを旧カーネルに戻します。

# RHEL系
grubby --set-default /boot/vmlinuz-（旧バージョン）

# Debian/Ubuntu系
# /etc/default/grub の GRUB_DEFAULT を旧カーネルのエントリパスに変更後
update-grub

この設定変更は永続的なため、次回以降の再起動も旧カーネルで起動します。

問題のある新カーネルの除去

切り戻し後、問題のある新カーネルをアンインストールしてGRUBエントリを整理します。

# RHEL系
dnf remove kernel-6.x.x-xxx.el9.x86_64

# Debian/Ubuntu系
apt purge linux-image-6.x.x-xx-generic
update-grub

アンインストール後は grubby --info=ALL または update-grub の出力でエントリが削除されたことを確認します。

完全にコンソールアクセスができない場合

クラウド環境や一部の仮想化環境では、シリアルコンソールやプラットフォーム側のレスキュー機能を利用します。AWS EC2であればEC2シリアルコンソール、GCPであればシリアルポートアクセス、Azureであればシリアルコンソール機能がそれぞれ提供されています。これらを事前に有効化しておくことが、本番カーネル更新の前提条件となります。

2026年現行環境での注意点と補足

2026年時点での主要ディストリビューションでは、いくつかの環境差分を踏まえておく必要があります。

RHEL 9系・AlmaLinux/Rocky Linux 9系： GRUB2の設定ファイルがUEFI環境では /boot/efi/EFI/redhat/grub.cfg または /boot/efi/EFI/almalinux/grub.cfg に配置されます。grubby コマンドがこれを自動で扱うため、通常はパスを意識する必要はありませんが、手動でファイルを参照する際には注意が必要です。

Ubuntu 24.04（Noble Numbat）： linux-image-generic-hwe-24.04 パッケージを使用している環境では、HWEカーネルのトラッキングが自動で行われます。特定バージョンに固定したい場合は、メタパッケージではなく個別のバージョンパッケージを直接指定する必要があります。

Secure Boot環境： Secure Bootが有効な環境では、カーネルイメージにディストリビューションの署名鍵による署名が必要です。ディストリビューション公式リポジトリのカーネルパッケージは署名済みですが、自前でビルドしたカーネルやサードパーティのパッチ済みカーネルを使用する場合は、MOK（Machine Owner Key）の登録が必要になります。mokutil --sb-state でSecure Bootの有効状態を確認できます。

コンテナワークロードとcgroupsv2： Linuxカーネル 5.x以降でcgroupsv2がデフォルトになっているディストリビューションが増えています。カーネル更新に伴ってcgroupsのデフォルト設定が変わる場合があり、Docker/containerd等のコンテナランタイムの挙動に影響することがあります。更新後の動作確認にはコンテナの起動・停止テストも含めることを推奨します。

kpatch / livepatch： RHEL系のkpatchやUbuntuのLivepatchを利用している場合、カーネル全体の差し替えとライブパッチは独立した仕組みです。ライブパッチ適用中のカーネルをバージョンアップする際は、ライブパッチのサポート対象バージョンを事前に確認します。新カーネルでライブパッチが未対応の場合、適用済みのパッチが引き継がれない点に注意が必要です。

月次CVE対応におけるカーネル更新は、スピードと安全性のバランスを取ることが運用上の課題です。段階展開・回帰検証・切り戻し手順の3点をセットで整備しておくことで、緊急パッチへの対応速度を維持しながらリスクを管理できる体制が整います。