Ubuntu 26.04.1とは？ポイントリリースの仕組み

Ubuntu のポイントリリースとは

26.04.1 などの Ubuntu ポイントリリースは、すでに利用しているリリースに、公開開始以降に公開されたすべての更新を反映した新しいインストールメディアです。新しいバージョンではありません。インストール元の archive は変わらず、apt sources の suite 名も変わりません。そのため、インストール済みで更新も適用済みのサーバーでは、ポイントリリースの公開時にダウンロードするものはありません。

その日に公開されるものは 2 つあります。メディアが再構築されます。つまり、その週の時点の archive から新しい ISO ファイルと新しい cloud images が作成されます。また、バージョン文字列が変わります。lsb_release -a は、以前に 26.04 LTS と報告していた箇所で 26.04.1 LTS を報告するようになります。

それ以外は、すでに利用中のものです。Ubuntu は、1 つの suite の -security pocket と -updates pocket に修正を継続的に公開します。26.04 では resolute、24.04 では noble です。ポイントリリースは、その更新ストリームのスナップショットです。移行先となる別の宛先はありません。

パッチ適用済みのサーバーにダウンロード対象がない理由

ポイント番号は小さな1つのパッケージに含まれています。次を実行します。

lsb_release -a
dpkg -S /etc/lsb-release

dpkg -S は base-files: /etc/lsb-release に答えます。base-files パッケージにはバージョン文字列を保持するファイルが含まれているため、ポイントリリースが公開されると、新しい base-files が -updates ポケットに入り、次回の sudo apt upgrade でインストールされます。実行中のマシンに対するポイントリリースの目に見える変化は、この1つのパッケージだけです。それ以外の内容は、通常の更新として数週間前にインストール済みです。

遅れが生じる一般的な原因が1つあります。デフォルトの /etc/apt/apt.conf.d/50unattended-upgrades では、Allowed-Origins ブロック内の -security origin が有効になっている一方、-updates 行はコメントアウトされています。そのため、自動更新だけを使用するマシンはセキュリティ修正を取得し、それ以外の更新をスキップします。そのマシンが数か月にわたって古いポイント番号を報告し続けるのは、実際に該当パッケージを持っていないためであり、正常な動作です。ファイルを開き、どの行がコメントアウトされているかを確認してください。Ubuntu で unattended upgrades を構成する方法では、そのブロックを行ごとに説明しています。

次のポイントリリースが公開される時期

日付ではなく、リリース間隔を把握してください。LTS の最初のポイントリリースは、4月に公開された初回リリースから数か月後に提供されます。その後のポイントリリースは、各 interim release に合わせて、およそ6か月間隔で提供されます。日付は変わることがあります。Canonical は最初の 26.04 point release を 2026年8月初旬に予定していましたが、その後延期しました。これは通常のことであり、問題の兆候ではありません。日付は、この記事を含む記事ではなく、Ubuntu release cycle page または 26.04 LTS release notes で確認してください。

24.04 から 26.04 への案内が最初のポイントリリースまで表示されない理由

アップグレードの案内は待機するよう設定されており、その設定は自分のサーバーで確認できます。

cat /etc/update-manager/release-upgrades

[DEFAULT]
# never  - Never check for, or allow upgrading to, a new release.
# normal - Check to see if a new release is available.
# lts    - Check to see if a new LTS release is available.
Prompt=lts

配布されているファイルのコメントは、この抜粋より長く、全文を読む価値があります。LTS 環境では Prompt=lts がデフォルトで、2 つの役割を持ちます。LTS リリースだけを案内し、確認先を別のリストに切り替えます。

そのリストは 2 番目のファイルで指定されています。

cat /etc/update-manager/meta-release

URI は https://changelogs.ubuntu.com/meta-release を指し、URI_LTS は https://changelogs.ubuntu.com/meta-release-lts を指します。Prompt=lts により、アップグレードツールは LTS リストを読み込みます。このリストでは、新しい LTS は最初のポイントリリースが存在するまでアップグレード先として案内されません。リストを取得して、自分で確認できます。

curl -s https://changelogs.ubuntu.com/meta-release-lts | tail -40

各リリースは Dist:、Version:、Supported:、UpgradeTool: の各行で構成されるブロックです。アップグレード先を案内するには、アップグレードツールがこのブロックを必要とします。Canonical も 26.04 LTS のリリース発表 で同じルールを明記しています。24.04 LTS のユーザーには、26.04.1 のリリース時に自動アップグレードが案内されます。

そのため、ポイントリリース前の 24.04 サーバーでは、次の結果になります。

sudo do-release-upgrade -c

Checking for a new Ubuntu release
No new release found.

これは正常な結果であり、故障を示すものではありません。アップグレード経路が開くと、同じコマンドでリリース名が表示され、ログインバナーにも同じメッセージが表示されます。

New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

表示されるバージョンを確認してください。26.04 にアップグレードしてから、再度 26.04.1 にアップグレードするわけではありません。1 回のアップグレードで、26.04 のその時点の状態になります。

この確認結果が空になる原因は、ほかにも 2 つあります。1 つは一部のプロバイダーイメージが設定する Prompt=never です。もう 1 つは、changelogs.ubuntu.com に接続できないプロキシまたはミラーです。別のメッセージである Please install all available updates for your release before upgrading は、確認に成功し、アップグレードツールが完全に更新された状態を開始点として要求していることを示します。残りの原因については、do-release-upgrade で新しいリリースが見つからない場合で確認できます。アップグレード経路が開き、準備が整ったら、24.04 から 26.04 へのアップグレード自体を別の作業として実施します。専用の準備が必要です。

-d フラグを指定すると、同じ確認先を開発版リストに変更できます。これが、アップグレード経路が開く前に移行する方法です。待機期間が設けられているのには理由があります。先行して移行したユーザーから報告されたアップグレード障害を修正するための期間です。借りて運用し、依存しているサーバーでは、この待機期間を活用するのが適切です。

VPS における hardware enablement kernel の意味

LTS では、サポート期間を通じて使用する GA（general availability）kernel が 1 つ提供されます。また、HWE（hardware enablement）という、更新が続く別のトラックも用意されています。HWE トラックは point release を通じて提供されます。point release の中で、既存の内容を再パッケージしたものではなく、実際に新しいコードを含むのは主にこの部分です。

24.04 を例にします。24.04 は kernel 6.8 でリリースされ、標準サポートの5年間は GA トラックで 6.8 を使い続けます。HWE トラックは2回目の point release から始まりました。24.04.2 では Ubuntu 24.10 の kernel 6.11 が提供され、24.04.3 では Ubuntu 25.04 の 6.14 が提供されました。2026年8月時点ではこのパターンが定着しており、26.04 も同じ構成になります。

使用しているトラックはパッケージ名で確認できます。

uname -r
apt list --installed 2>/dev/null | grep -E '^linux-(generic|virtual|image|kvm)'

linux-generic は GA トラックです。linux-generic-hwe-24.04 は更新が続くトラックです。Desktop のインストールでは HWE がデフォルトで、server のインストールでは GA がデフォルトです。一方、VPS の provider image では、linux-virtual や cloud 固有の linux-kvm など、さらに限定されたものが使われることがあります。image を作成した provider によってデフォルトが異なるため、推測せずに確認してください。

レンタルした仮想ハードウェアでは、hardware enablement はほとんど必要ありません。サーバーから見えるのは virtio デバイスと、hypervisor が提供する準仮想化されたネットワークおよびディスクのインターフェースです。これらのドライバーは10年以上にわたって kernel で安定しています。新しい laptop では HWE が必要になることがありますが、VPS ではほぼ必要ありません。ここで新しい kernel によって得られるのは、主に kernel の機能です。たとえば、新しい io_uring や eBPF の機能、または明確な目的がある filesystem の修正などです。Linux kernel 7.1 の新機能 を確認すると、それらのために更新に伴う変更を受け入れる価値があるか判断できます。

代償は再起動とリスクです。HWE meta package はおよそ6か月ごとに新しい upstream kernel を取り込むため、その周期で kernel の更新と再起動が発生します。DKMS でビルドする out of tree module は、新しいバージョンに対してビルドできないことがあります。特に ZFS で起きやすく、起動時に初めて判明する場合があります。各 kernel は直前の kernel も残すため、小容量の /boot が満杯になることがあります。必要になってからではなく、事前に 満杯になった /boot から古い kernel を削除する方法 と VPS の起動に使用する kernel を選ぶ方法 を確認してください。

HWE トラックへの移行は、1つのコマンドと再起動で行えます。

sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

再起動後に uname -r を実行すると、新しいバージョンが表示されるはずです。新しい kernel で起動し、サービスを確認するまでは、以前の kernel をインストールしたままにしてください。起動できない kernel から復旧するには、boot menu で古いエントリを選択します。そのエントリが残っていなければなりません。残っていない場合は、kernel の更新後に起動しなくなった VPS を復旧する方法 の状況になります。

HWE package には、point release より先の kernel を取り込む -edge variant もあります。これはテスト用です。サーバーでは使用しないでください。

レンタルサーバーのデフォルトの選択は GA kernel です。5年間にわたって1つの kernel バージョンを使い、期間中は security fix が backport され、予定されたバージョン更新はありません。必要な機能を具体的に説明できる場合に限り、HWE に移行してください。

本日新規インストールした環境が先月の環境と異なる理由

イメージはポイントリリースよりも頻繁に再ビルドされます。Ubuntu はシリアル番号が付いた cloud image を公開しており、各プロバイダーは独自のスケジュールで Ubuntu のテンプレートを更新します。そのため、同じメニュー項目から 6 か月間隔で作成した 2 台のサーバーでも、異なる kernel バージョンで起動し、異なる package バージョンで開始する場合があります。どちらも間違いではありません。

これは見た目以上に重要です。インストール後に 5 つのコマンドを実行すると記載した runbook は、現在では成立しない初期状態を暗黙に前提としている可能性があります。クリックしたラベルを信頼せず、各サーバーで lsb_release -a と uname -r を確認してください。そのうえで、コードで最終状態を定義し、初期状態に依存しないようにします。VPS 用の最初の Ansible playbookは、そのための最小限で実用的な構成です。

ポイントリリースで移行するべきか、それとも待つべきか

• すでに 26.04 を使用している場合、移行先はありません。更新を適用し続ければ、ポイント番号は自動的に追随します。
• 24.04 を使用している場合、標準サポートは 2029 年 4 月まで続くため、待っても問題ありません。最初のポイントリリースは移行の開始時期であり、期限ではありません。
• まずコピー環境でアップグレードします。サーバーのスナップショットを作成するか、使い捨ての VPS に同じ構成を再構築し、そこでアップグレードを実行して所要時間を計測します。
• 必要なのが新しいリリースではなく新しいカーネルであれば、LTS のアップグレードを行わずに 24.04 で HWE トラックを利用できます。

どのリリースを基盤にするかという、より広い問題については、サーバーでは LTS と interim release のどちらを選ぶかで説明しています。

自分のサーバーで確認すること

lsb_release -a
uname -r
grep -v '^#' /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

正常な結果では、lsb_release -a に現在のポイントリリースを含むリリース情報が表示され、uname -r は使用する予定のカーネルトラックと一致し、Prompt=lts が存在します。また、チェック結果に何も表示されないか、提供されるリリース名が表示されます。それ以外の結果は、アップグレード中ではなく、事前に確認しておく必要があります。

FAQ

26.04.1 のようなポイントリリースが公開されたら、何かする必要がありますか？

いいえ。サーバーがすでにそのリリースを使用しており、更新を適用しているなら必要ありません。ポイントリリースでは、公開済みの更新を新しいインストールメディアにまとめます。稼働中のマシンには、更新が公開されると同じ内容が apt upgrade 経由で適用されます。また、base-files パッケージが更新されると、lsb_release -a のバージョン文字列が変わります。移行先となる別のリリースはなく、再インストールも必要ありません。

apt upgrade 後も、サーバーが古いポイント番号を報告するのはなぜですか？

通常は、自動更新がセキュリティ修正に限定されているためです。デフォルトの /etc/apt/apt.conf.d/50unattended-upgrades は -security origin を有効にし、-updates 行をコメントアウトしたままにします。バージョン文字列を保持する base-files パッケージは -updates 経由で提供されます。手動で sudo apt update && sudo apt full-upgrade を実行し、base-files が一覧に表示されるか確認してください。一覧にあり、保留中として扱われている場合は、pin または hold が設定されています。

24.04 のサーバーに 26.04 が提示されないのはなぜですか？

LTS では /etc/update-manager/release-upgrades の Prompt=lts がデフォルトであり、https://changelogs.ubuntu.com/meta-release-lts で LTS の一覧を確認するためです。新しい LTS は、最初のポイントリリースが公開されるまでアップグレード対象として提示されません。それまでは sudo do-release-upgrade -c が No new release found. を出力しますが、これは正しい動作です。この待機期間は意図的に設けられています。早期に移行したユーザーが見つけたアップグレードの問題を修正する期間です。

VPS に HWE kernel をインストールすべきですか？

通常は必要ありません。Hardware Enablement は、リリースより新しいハードウェアをサポートするためのものです。VPS では virtio デバイスが提供されますが、そのドライバーは数年前から kernel に組み込まれています。GA kernel は LTS のサポート期間中、1つのバージョンに固定され、修正がバックポートされます。必要な kernel 機能を具体的に説明できる場合に HWE kernel を使用してください。その場合は、kernel の大きな更新と、およそ6か月ごとの再起動を受け入れる必要があります。