Ubuntuのバージョンをアップグレードする方法

Uncategorized

作成日 2026-11-03 最終更新日 2026-11-03

Ubuntu ServerのOSを次のリリースへ移行するには、sudo do-release-upgradeを使います。先に現在のリリースのパッケージをすべて更新し、対応するアップグレード経路と復元可能なバックアップを確認してから進めてください。

パッケージ更新とリリースアップグレードの違い

do-release-upgradeは、Ubuntuの基本パッケージ構成とシステム設定を次のリリースに合わせて移行するツールです。パッケージ一覧を更新するapt updateや、現在のリリース内でパッケージを更新するapt upgradeとは目的が異なります。通常の管理方法はUbuntu Serverのaptの使い方を参照してください。

長期サポート版のLTS（Long Term Support）は、直後のLTSへ順番にアップグレードします。例えば22.04 LTSから26.04 LTSへ移行するには、24.04 LTSを経由し、各段階で動作を確認する必要があります。リポジトリのコードネームを一括変更してリリースを飛ばさないでください。対応経路とサポート期間はUbuntuのリリースサイクルで確認できます。

新しいLTSが公開されても、すべての既存サーバーに直ちにアップグレードが提供されるわけではありません。LTS間のアップグレードは通常、最初のポイントリリース後に有効になります。実際の提供状況はツールで確認してください。サポート終了済みのリリースでは、この手順がそのまま使えると考えず、別途復旧・移行計画を立ててください。

バックアップと復旧用アクセスを準備する

サービス停止時間を確保し、管理者権限のあるアカウントで作業します。移行先Ubuntuのリリースノートとアプリケーションの対応条件も確認してください。Webサーバーが起動することと、PHP、データベース、拡張モジュールが正常に動作することは別の確認事項です。

バックアップ：サービスのデータ、データベース、/etc以下の設定、証明書、復旧に必要な機密情報を安全な別の場所に保管します。データベース製品に合った整合性を保つバックアップ方法を使い、復元可能か確認してください。稼働中の仮想マシンのスナップショットだけで、データベースの整合性が保証されるとは限りません。
復旧用アクセス：物理コンソール、リモート管理コンソール、クラウドのシリアルコンソールなど、SSH（Secure Shell）が切断されても使える経路を準備し、接続を試します。SSHで作業する場合も、復旧手段をSSHだけに依存しないでください。
クラウドの条件：事業者のイメージ、カーネル、起動方式、管理エージェントの対応条件を確認します。すべてのクラウドサーバーでインプレースアップグレードが禁止されているわけではありません。復元が難しい場合や、サービスの互換性を事前検証したい場合は、新規サーバーを構築してデータを移す方法も比較してください。

次のコマンドは現在のリリース、空き容量とinode、未完了のパッケージ処理、保留パッケージを確認します。アップグレードは開始しません。

cat /etc/os-release
uname -r
df -h / /boot
df -i / /boot
sudo dpkg --audit
apt-mark showhold

VERSION_IDを記録し、まず/と/bootの容量不足を解消します。必要な容量は構成と変更計画によって異なります。dpkg --auditで問題が表示されたら調査し、保留パッケージも理由を理解してから扱ってください。チェックを通すために保留を一括解除しないでください。

現在のリリースを更新し、通知方針を確認する

現在のリリースのパッケージ一覧を更新し、すべての更新を適用します。次はUbuntu Server公式アップグレード手順に示されている準備コマンドです。

sudo apt update
sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true

dist-upgradeは設定済みリポジトリで依存関係を調整し、パッケージを削除する場合もあります。変更予定を読み、重要なパッケージが予想外に削除される場合は進めないでください。このオプションは段階的配信中の更新も含めますが、コマンド自体はUbuntuのリリースを変更しません。両方のコマンドが成功し、未適用の更新がない状態にします。

/run/reboot-requiredが存在するか確認します。存在する場合は、現在の更新を完了するために再起動が必要です。

if [ -f /run/reboot-required ]; then
    cat /run/reboot-required
fi

再起動が必要なら、保守時間内にsudo rebootを実行します。再接続してサービスを確認してから次へ進んでください。ファイルが存在しないことは、アプリケーションの検証完了を意味しません。

do-release-upgradeがなければ、コマンドを提供するパッケージをインストールし、リリース通知の方針を確認します。

sudo apt install ubuntu-release-upgrader-core
cat /etc/update-manager/release-upgrades

コマンドが既にあればインストールは省略できます。LTSサーバーを次のLTSへ移行する方針なら、設定ファイルでPrompt=ltsを使います。Prompt=normalは中間リリースも確認する方針で、リリースを飛ばす設定ではありません。変更する場合は元ファイルを別名でバックアップし、sudoedit /etc/update-manager/release-upgradesで該当項目だけを編集してください。違いはUbuntuのLTSと中間リリースの切り替え案内に説明されています。

移行先を確認してアップグレードを開始する

まずアップグレード可能なリリースの有無を確認します。-cは確認して終了するオプションで、アップグレードは開始しません。アプリケーションの互換性を試す機能でもありません。

sudo do-release-upgrade -c

移行先が表示されない場合は、現在のバージョン、対応経路、Prompt、未適用の更新、ネットワーク、提供状況を確認します。do-release-upgradeのマニュアルの-dは開発版を確認するオプションで、最初のポイントリリース前に新しいLTSを評価する用途にも使われます。本番サーバーで「新しいリリースがない」という表示を回避するために、むやみに付けないでください。

バックアップと復旧経路を準備し、提示された移行先が計画どおりなら、次のコマンドで開始します。自動承認オプションは付けず、質問に応答できる状態で作業してください。

sudo do-release-upgrade

変更概要：移行先、削除・追加パッケージ、ダウンロード量、必要容量を確認します。重要なサービスの削除など計画と異なる変更があれば、承認前に中止して原因を解消してください。パッケージのインストール開始後は、プロセスを強制終了したり電源を切ったりしないでください。
設定ファイルの質問：既存設定とパッケージ提供設定の差分を見て判断します。差分表示、保持、置換は実際の画面の説明に従ってください。すべて保持、またはすべて置換すると、既存サービスの設定や新バージョンに必要な変更を失う場合があります。
外部リポジトリと接続：PPA（Personal Package Archive）やサードパーティーのリポジトリはアップグレード中に無効になります。復旧用SSHポートが案内された場合は、その表示に合わせてファイアウォールとクラウドの通信規則を確認し、管理者だけにアクセスを制限します。ファイアウォール全体を停止したり、不要なポートを常時開放したりしないでください。

不要になったパッケージの削除も、一覧を確認して判断します。完了後に再起動を求められたら保守時間内に再起動し、事後確認が終わるまでコンソールを維持してください。

再起動後にバージョンとサービスを確認する

再接続して移行先リリースになったか、失敗したサービスがないか確認します。カーネルは作業前の記録や移行先のパッケージ情報と比較し、パッケージ一覧も再取得します。

cat /etc/os-release
uname -r
systemctl --failed
sudo apt update
apt list --upgradable

VERSION_IDが目的の値か確認し、systemctl --failedの各失敗項目を調査します。失敗項目がなくても、Web応答、データベースの読み書き、定期実行、監視、バックアップを実際のサービス要件に沿って確認してください。新しいSSHセッションで接続できることも試してから復旧コンソールを閉じます。

外部リポジトリは、新しいUbuntuへの対応とパッケージの互換性を確認し、必要なものだけ再設定します。古いコードネームのリポジトリを一括で有効にしないでください。追加の整理はサービスが安定してから、削除予定のパッケージを確認して進めます。

エラーや接続切断に対応する

エラー時は最後のメッセージと/var/log/dist-upgrade/のログを保存します。Ubuntuのアップグレード不具合報告案内でも、このディレクトリのログを資料として挙げています。まずファイル一覧を確認し、存在するログを読んで、失敗した段階やパッケージ関連の原因を絞り込みます。

sudo ls -lah /var/log/dist-upgrade/
sudo less /var/log/dist-upgrade/main.log

SSHが切断されたら、復旧コンソールで既存のアップグレードプロセスと進行状況を先に確認します。切断だけを理由に再実行したり、APTのロックファイルを削除したりしないでください。パッケージ処理中の中断は、ログと現在の状態に応じた復旧が必要です。

リリースアップグレードを取り消し、以前のUbuntuへ戻す一般的な単一コマンドはありません。復元が必要なら、検証済みのサーバーとデータベースのバックアップを整合する時点へ戻すか、準備した旧サーバーに切り替えます。バックアップ後の書き込みをどう保全するかも判断してください。Promptの設定だけを戻しても、変更済みのOSは復元されません。

Uncategorized