Ubuntu ServerのGAとHWE、どちらを選ぶ？

ポイントリリースで Ubuntu server に新しい kernel が導入されますか？

いいえ。Ubuntu server では、HWE kernel と GA kernel のどちらを使用するかは、インストールするパッケージによって決まります。ポイントリリースによって、HWE kernel が自動的に導入されることはありません。混乱の原因は、release notes で「enablement」という語が2つの異なる意味で使われていることです。Hardware enablement（HWE）は、新しい kernel の系列です。Upgrade enablement は、ある LTS から次の LTS への upgrade path が開く、別のタイミングを指します。すでに稼働していて、すでに GA を使用している server は、LTS の各ポイントリリースを通じて GA のままです。

GA と HWE のカーネルトラックとは

GA（general availability）は、Ubuntu LTS がリリース日に採用するカーネルです。リリースの標準サポート期間中は、上流のカーネルバージョンを維持します。セキュリティ修正とバグ修正はこのカーネルへバックポートされるため、uname -r の末尾の番号は数週間ごとに変わります。文字列の先頭にある上流バージョンは変わりません。

HWE（hardware enablement）はもう一方のトラックです。Canonical は、後続の各 interim release のカーネルを LTS にバックポートします。次の LTS のカーネルに到達すると、この更新を停止します。そのため、HWE カーネルは次の LTS のカーネルに到達するまで、約 6 か月ごとに新しい上流バージョンへ更新されます。Canonical はこれを rolling update model と呼んでいます。最終的な HWE カーネルは次の LTS の GA カーネルです。その後は LTS の残りの期間、その上流バージョンを維持し、GA と同じ方法で修正を取り込みます。Desktop image では、デフォルトで HWE カーネルがインストールされます。Server image と cloud image では、デフォルトで GA がインストールされ、HWE stack は opt-in package です。

違いは明確です。GA では、何年も変わらないカーネルバージョンを使用できます。HWE では、より新しいドライバーとカーネル機能を利用できます。ただし、トラックが rolling update の対象である間は、約 6 か月ごとにバージョン更新と再起動が必要です。

現在、どのカーネルトラックを使用していますか

uname -rにはhweという単語が含まれることはありません。どちらのトラックも-genericで終わるバージョンを表示するため、実行中のカーネル名だけでは判断できません。インストール済みのメタパッケージを確認すると、更新がどのトラックに従っているか分かります。これをuname -rと比較すると、実際に実行中のカーネルも確認できます。

uname -r
grep VERSION_ID /etc/os-release
apt-cache policy linux-generic linux-generic-hwe-24.04

24.04を、自分のマシンでVERSION_IDが表示する番号に置き換えてください。apt-cache policyは、指定した各パッケージについてInstalled:行を表示します。この行はパッケージがインストール済みであることを示すだけで、そのカーネルが実行中であることは示しません。-hwe-パッケージに対するInstalled: (none)とlinux-genericのバージョンが表示され、linux-virtual-hwe-24.04など別の enablement メタパッケージがインストールされていなければ、更新は GA トラックに従っています。後続のコマンドでその点を確認できます。逆の場合は、enablement トラックに従っています。両方にバージョンが表示される場合、両方のカーネルがディスク上に存在します。Ubuntu のデフォルトのGRUB_DEFAULT=0では、GRUB は新しい方を起動します。通常は enablement カーネルです。ただし、GRUB_DEFAULTが特定のエントリまたはsavedに設定されている場合は、GA カーネルが起動することもあります。実際に実行中のカーネルを示すのはuname -rだけです。

一部のプロバイダーイメージでは、linux-genericではなくlinux-image-virtualがインストールされています。これは仮想マシン向けに構成された、モジュール数の少ないカーネルで、独自の enablement バリアントがあります。名前を推測しないでください。どのカーネルパッケージが選択されたかをマシンに確認し、その後、使用中のリリースで利用可能な enablement パッケージをアーカイブに確認してください。

apt-mark showmanual | grep '^linux-'
apt-cache search linux-image | grep hwe
apt-cache depends linux-image-generic-hwe-24.04
dpkg -l 'linux-image-*' | grep '^ii'
ls /boot/vmlinuz-*

apt-cache dependsを実行すると、enablement メタパッケージが現在指しているカーネルイメージを確認できます。そのイメージのバージョンがuname -rと一致すれば、enablement カーネルを実行しています。ls /boot/vmlinuz-*では、実際にインストールされていて起動可能なカーネルを確認できます。想定より多く表示されることもあります。

各ポイントリリースが各トラックに与える影響

GA トラックでは、ポイントリリースによって稼働中のサーバーが変更されることはありません。ポイントリリースは、更新済みのインストールイメージと、apt がすでに提供している更新をまとめたものです。新しく構築するマシンに何を導入するかを決めるものであり、既存のマシンで何が実行されるかを変えるものではありません。詳細は Ubuntu のポイントリリースで実際に変わるもの を参照してください。

enablement トラックでは、メタパッケージはポイントリリース当日ではなく、それに先立つ通常の kernel 更新サイクルで更新されます。Canonical は、最初の LTS ポイントリリースを除くすべての LTS ポイントリリースに先立って enablement kernel を更新します。2025-08-07 に公開された 24.04.3 では、6.11 から 6.14 への移行が 2025.06.16 の kernel SRU サイクルで予定されていました。linux-image-generic-hwe-24.04 は依存先を新しい kernel image に変更し、次回の通常の更新処理でその image がインストールされます。apt のマニュアルページには、通常の update 処理で十分な理由が明記されています。「依存関係を満たすために必要な場合は新しいパッケージがインストールされますが、既存のパッケージが削除されることはありません」。そのため apt upgrade が新しい kernel を取り込みます。実行中の kernel になるのは、次回の再起動後です。

24.04 では、rolling はすでに終了しています。2026-10-12 時点で、amd64 の linux-generic-hwe-24.04 は 7.0 kernel image に依存しています。これは 26.04 の GA kernel です。以後、このトラックで提供されるのは修正であり、upstream version のさらなる移行ではありません。

unattended job がこの処理を自動で行うかどうかは、利用環境の設定によって決まります。/etc/apt/apt.conf.d/50unattended-upgrades を読み、Allowed-Origins ブロックを確認してください。出荷時のデフォルト設定では release pocket と security pocket が有効で、updates pocket はコメントアウトされています。ただし、これによって enablement の移行が阻止されるわけではありません。Ubuntu は enablement の移行を含む kernel メタパッケージの更新も security pocket に公開するためです。2026-10-12 時点では、noble-security に linux-generic-hwe-24.04 version 7.0.0-38.38~24.04.4 が公開されています。したがって、enablement メタパッケージをインストールしたデフォルト設定では、unattended-upgrades が新しい enablement kernel を自動的にインストールします。実行中の kernel が切り替わるのは、再起動後だけです。どちらになるかを推測せず、ファイルを確認してください。

サポート期間も同じ仕組みから決まります。GA kernel は、利用者の操作なしで LTS リリースの標準サポート期間中サポートされます。各 enablement kernel は、次の enablement kernel に置き換えられるまでサポートされます。最後の enablement kernel だけは例外で、LTS の残りの期間中サポートされます。この最後の移行が完了するまでは、HWE はすべての移行を継続して適用する場合に限りサポート対象のトラックです。このトラックで 2 段階遅れると、修正が提供されなくなった kernel を実行することになり、apt にもその状態は表示されません。

この文書を含め、ブログ記事に記載された正確な日付をそのまま使用しないでください。Canonical は、Ubuntu kernel lifecycle page で各 kernel version の終了日を公開しています。また、Ubuntu release cycle page でリリース日とサポート日を公開しています。これらのページの情報を、サーバー上で uname -r と grep VERSION_ID /etc/os-release が出力する内容と比較してください。この 2 つの事実だけが、実際のマシンの状態を示します。

Enablement kernel が VPS で役立つことが少ない理由

HWE はハードウェア向けです。LTS kernel より新しい NIC（network interface card）、storage controller、または GPU を搭載した laptop や物理サーバーでは、新しい kernel が提供されるまで正常に動作しないことがあります。Enablement kernel はその問題を解決します。実機では、動作するマシンと起動不能なマシンを分けることもよくあります。

レンタル VPS では、その問題は通常発生しません。VPS からそれらのハードウェアは見えないためです。ゲストが認識するのは、意図的に古く限定された仮想デバイスのセットです。自分の環境を確認してください。

sudo apt install -y pciutils
lspci -nnk

lspci -nnk は各デバイスと、それに割り当てられた kernel driver をデバイスの下に表示します。多くの VPS では、一覧は短くなります。ネットワークには virtio_net、ディスクには virtio_blk または virtio_scsi が使われます。これらの driver は、何年も前から mainline kernel に含まれています。仮想デバイスが安定したインターフェースになっているのは意図的です。provider が別の物理ハードウェアへ移行しても、ゲストが動作し続ける必要があるためです。そのため、レンタルサーバーでは Enablement kernel を導入する主な理由がほとんど存在しません。

ただし、コストは発生します。Enablement の各段階では新しい kernel binary が導入され、セキュリティ kernel のために必要な再起動に加えて、固有の再起動が必要です。フェイルオーバー先のない単一の VPS では、再起動によってダウンタイムが発生するため、時間を決めて監視しながら実施する必要があります。Live kernel patching により、一部のセキュリティ更新に伴う再起動は省けます。ただし、version bump に伴う再起動は省けません。これは patch 適用済みの kernel ではなく、別の kernel への切り替えだからです。

enablement kernel へ移行すべき場合

答えが明確に「はい」となるケースは4つあります。

• ハイパーバイザーが、現在の kernel では制御できないデバイスを提供している場合。症状は明確です。lspci -nnk にデバイスが存在する一方で、ip -brief link にインターフェースが表示されない、または lsblk にディスクが表示されず、その配下に Kernel driver in use: の行もありません。
• 使用するソフトウェアが、現在の kernel より新しい最低 kernel バージョンを要件として明記している場合。Container runtime、データベース、eBPF tooling ではこのような要件があります。ベンダーが示す最低バージョンを uname -r と比較し、ベンダーの要件を優先してください。
• GA version の後に upstream で修正されたものの、backport されていないバグに遭遇した場合。切り替える前に、その修正が enablement version に実際に含まれていることを確認してください。確認しないと、再起動だけが増え、バグは残ります。
• GA version の後に追加された filesystem または networking の機能が必要で、その機能がサーバーの存在理由になっている場合。

これらのいずれにも該当しないサーバーであれば、適切な選択は GA です。そのままにしておくことは、放置ではなく意図的な判断です。

切り替え方法と再起動後の確認項目

最初に空き容量を確認します。/boot が小容量の独立したパーティションの場合、2 つ目の kernel の行を追加すると容量を使い切ることがあります。その場合、apt は No space left on device の状態で設定を完了できず停止します。

df -h /boot
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
ls /boot/vmlinuz-*
sudo reboot

サーバーが復旧したら、何が変わり、何が変わっていないかを確認します。

uname -r
ip -brief link
lsblk
journalctl -k -b 0 -p err --no-pager

uname -r は、指定された image apt-cache depends linux-image-generic-hwe-24.04 と一致しているはずです。現在の 24.04 では、以前より高い upstream version、つまり 6.8 ではなく 7.0 になっていることを意味します。enablement track がまだ移行していない release では、upstream version が同じ場合もあります。2026-10-12 時点では、26.04 の linux-generic と linux-generic-hwe-26.04 はどちらも 7.0.0-38.38 に依存しています。ネットワークとディスクの一覧は、同じ仮想デバイスが存在するため、以前と完全に同じ状態になるはずです。ここで interface が欠落している場合は、唯一、重大な障害です。通常、provider の console からしかサーバーに接続できなくなるためです。journalctl -k -b 0 -p err は、この boot の kernel メッセージのうち error priority 以上（err、crit、alert、emerg）を出力します。正常な VPS では、出力は空か、ほとんどありません。VPS で kernel log を読むでは、ノイズの多い行の意味を説明しています。同じ日に古い kernel を削除しないでください。古い kernel が復旧手段になります。

新しいカーネルに問題がある場合の戻し方

古いカーネルは引き続きインストールされており、GRUB メニューにも残っています。プロバイダーのコンソールを開いて再起動し、「Advanced options for Ubuntu」で1つ前のカーネルを選択します。これを1回行えば、古いカーネルで起動できることを確認できます。再起動後もこの選択を維持する方法は別の作業であり、VPS で起動するカーネルを固定する方法で説明しています。マシンが復帰せず、コンソールに GRUB プロンプトや kernel panic が表示される場合は、カーネル更新後に起動しない VPS の復旧方法で復旧手順を確認してください。

正常に動作するカーネルで起動したら、パッケージを元に戻します。

sudo apt install linux-generic
sudo apt remove linux-generic-hwe-24.04 linux-image-generic-hwe-24.04 linux-headers-generic-hwe-24.04
sudo reboot

meta-package を削除すると、次回の enablement 手順で新しいカーネルが導入されなくなります。すでにインストールされているカーネルイメージは削除されないため、稼働中のシステムには影響しません。再起動後、uname -r で再び GA バージョンが表示されることを確認します。sudo apt autoremove --purge では古いイメージの一部が削除されますが、直前まで使用していたものが必ず削除されるとは限りません。APT は常に、実行中のカーネルとインストール済みの最新カーネルを保持します。enablement イメージは通常、最新のカーネルです。uname -r でそのカーネルを実行していないことを確認したら、dpkg -l 'linux-image-*' に表示されたバージョンを使い、そのバージョンの linux-image-、linux-modules-、linux-modules-extra- パッケージを名前で削除します。ここまで進む前に /boot が満杯になった場合など、より難しいケースについては、/boot の古いカーネルを整理する方法を参照してください。

最後に、トラックの選択について知っておくべき点があります。次の LTS に移行すると、次の LTS の GA カーネルが導入されます。これは現在使用している GA カーネルより新しく、サポート期間も改めて始まります。移行を予定していてポイントリリースが気になっている場合は、24.04 から 26.04 へのアップグレードで手順を確認してください。それまでは GA に留まることも、レンタルサーバーでは通常の妥当な選択です。

FAQ

ポイントリリースで、すでにインストール済みのサーバーの kernel は変更されますか？

GA track では変更されません。ポイントリリースは主にインストールイメージを更新するもので、新しく構築するマシンに適用される内容を決めます。既存のサーバーでは、インストールされている meta-package の名前が使用する track を決めます。linux-...-hwe-... package がインストールされている場合、enablement の適用は通常の kernel update として提供されます。これは対応するポイントリリースより前に公開され、次回の apt upgrade でインストールされます。新しい kernel が実行されるのは、apt の処理完了時ではなく、次回の再起動後です。

HWE kernel と GA kernel のどちらを実行しているか確認するにはどうすればよいですか？

apt-cache policy linux-generic linux-generic-hwe-24.04 を実行します。24.04 には使用している release number を指定します。Installed: 行に実際の version が表示される package が、更新で使用される track です。これは実行中の kernel を示すものではないため、uname -r と image apt-cache depends linux-image-generic-hwe-24.04 の名前を比較してください。uname -r だけから track を判断しないでください。どちらの track でも、実行中の kernel 名は末尾が -generic になり、hwe を含まないためです。どちらの package もインストールされていない場合は、apt-mark showmanual | grep '^linux-' を実行してください。一部の provider image では linux-image-virtual family が使用されます。

HWE kernel は GA kernel より安定性が低いですか？

各 enablement kernel はサポート対象の Ubuntu kernel です。そのため、これは品質の問題ではありません。変更量の問題です。GA kernel は数年間、1 つの upstream version を維持するため、テストしたときの動作が変わりません。enablement kernel は、次の LTS の kernel に到達するまで、およそ 6 か月ごとに新しい upstream version へ移行します。そのたびに、ワークロードによっては driver のデフォルトや sysctl が変わる可能性があります。あまり変更しないサーバーでは、新しい driver よりも、変動要素が少ないことのほうが重要です。

VPS では HWE kernel を使用すべきですか？

通常は使用しません。仮想マシンから見える仮想デバイスは固定されており、その大半は virtio です。これらの driver は何年も前から kernel に含まれているため、enablement track が提供するハードウェア対応のメリットは VPS にはありません。追加の再起動は必要です。現在の kernel では対応できないデバイスがある場合や、実行するソフトウェアに documented minimum kernel version がある場合など、明確な理由があるときだけ切り替えてください。

enablement kernel をインストールした後、再起動しなかった場合はどうなりますか？

新しい kernel image は /boot に書き込まれ、GRUB menu に追加されます。ただし、サーバーは古い kernel のまま動作します。実行中の kernel を確認するには uname -r を使用します。package list では判断できません。インストール済みの package が反映に再起動を必要とする場合、Ubuntu は /var/run/reboot-required を作成します。そのため、再起動が保留中かどうかは ls -l /var/run/reboot-required で確認できます。再起動するまで、新しい kernel が使用するディスク容量だけが増え、修正内容は適用されません。