Ubuntu Server 22.04 LTS から 24.04 LTS への更新手順

以下、Ubuntu Server 22.04 LTS → 24.04 LTS 更新手順として、技術文書調で整理します。22.04 LTS から 24.04 LTS への直接更新は、LTS 間アップグレードとして do-release-upgrade を用いるのが公式経路です。24.04 系の変更点は 22.10 / 23.04 / 23.10 の差分も含んで取り込まれます。

1. 目的

本手順は、Ubuntu Server 22.04 LTS（Jammy Jellyfish）を、インプレースで Ubuntu Server 24.04 LTS（Noble Numbat）へ更新するための標準手順を示すものです。対象は サーバー用途 に限定し、更新操作はコマンドラインで実施します。Ubuntu Server の公式手順では、Server Edition のリリースアップグレードに do-release-upgrade を使用します。

2. 適用条件

更新元は Ubuntu 22.04 LTS 系、更新先は Ubuntu 24.04 LTS 系です。LTS から次の LTS への更新は、新しい LTS の初回ポイントリリース後に一般提供される運用であり、22.04 から 24.04 への直接更新経路はその条件で有効化されています。

3. 前提条件

実施前に以下を満たしてください。

1. 対象ホストの完全バックアップまたはスナップショットを取得済みであること。
2. すべての既存パッケージ更新が完了していること。
3. 保留パッケージ、壊れた依存関係、未完了の dpkg 処理が存在しないこと。
4. 外部 PPA や非公式リポジトリの影響を把握していること。
5. コンソール、IPMI、iDRAC、ILO、仮想基盤コンソール等、SSH 断対策済みの管理経路があること。Server 系は CLI 更新が基本であり、SSH 経由実行時は接続断や端末断の考慮が必要です。

4. 事前確認

現在の OS バージョン、保留パッケージ、更新残を確認します。

lsb_release -a
uname -r
apt-mark showhold
sudo apt update
sudo apt upgrade
sudo apt full-upgrade
sudo apt autoremove --purge

apt upgrade および apt full-upgrade が正常終了し、apt-mark showhold の結果が空であることを確認してください。アップグレード計算時の失敗要因として、未解決依存や外部リポジトリ競合が実際に問題になります。

5. リポジトリ・追加パッケージの確認

以下に該当する場合は、更新前に整理してください。

• PPA
• ベンダ独自リポジトリ
• 手動導入した .deb 群
• カーネル外部モジュール
• DKMS 利用パッケージ
• 旧版 Python や旧版ライブラリ依存アプリケーション

LTS 間アップグレードでは、これらが依存解決失敗や設定ファイル競合の主因になります。24.04 系では 22.04 からの差分に加え、中間リリース分の変更もまとめて反映されるため、周辺コンポーネントの互換性確認が必要です。

6. 再起動

直前の通常更新適用後に再起動を実施します。

sudo reboot

再起動後、サービス状態とパッケージ状態を確認します。

systemctl --failed
sudo dpkg --configure -a
sudo apt --fix-broken install

失敗サービスや未完了パッケージ処理がある状態では、リリースアップグレードに進めない構成としてください。これは運用上の安全条件です。

7. リリースアップグレードの実行

更新開始コマンドは以下です。

sudo do-release-upgrade

Ubuntu Server の公式更新方法は do-release-upgrade です。対話形式で進行し、必要に応じてリリースノート参照、不要パッケージ削除、設定ファイルの差し替え確認が表示されます。

8. 実行中の代表的な確認ポイント

更新中は主に以下の確認が発生します。

• 廃止パッケージの削除可否
• ローカル変更済み設定ファイルを保持するか、配布元へ置換するか
• サードパーティパッケージの扱い
• サービス再起動可否

特に /etc 配下を手動管理しているサーバでは、設定ファイル差分の確認が最重要です。SSH、ネットワーク、ファイアウォール、時刻同期、監視、仮想化関連の設定を不用意に上書きしないようにしてください。

9. SSH 経由で実施する場合

SSH 越しに実施すること自体は可能ですが、セッション断対策が必要です。更新中に SSH デーモンやネットワークスタックが再起動される可能性があるため、tmux または screen の使用、もしくはコンソール接続の確保を推奨します。Ubuntu 系解説でも、SSH 実施時は端末維持策を取ることが勧められています。

実施例:

tmux new -s upgrade
sudo do-release-upgrade

10. 更新完了後の再起動

アップグレード完了後、必ず再起動します。

sudo reboot

再起動後、以下を確認します。

lsb_release -a
uname -r
systemctl --failed
sudo apt update
sudo apt autoremove --purge

24.04 LTS へ更新済みであること、異常サービスがないこと、不要パッケージ整理が完了していることを確認してください。24.04 のリリースノートも、更新後に変更点確認を行う前提で参照するのが適切です。

11. 更新後の重点確認項目

サーバ用途では、最低限以下を確認対象としてください。

• ネットワーク疎通
• SSH 接続可否
• DNS 名前解決
• NTP 同期
• ファイアウォール設定
• 監視エージェント
• ハイパーバイザ / 仮想化機能
• コンテナ実行環境
• ストレージマウント
• 自動起動サービス
• ログ出力異常の有無

24.04 系ではカーネル、ライブラリ、ユーザ空間ツールが更新されるため、サーバ役割に応じた機能確認が必要です。

12. 推奨しない進め方

以下は標準手順としては推奨しません。

• 22.04 → 23.10 → 24.04 の手動中間更新
• -d オプションを使った非通常経路更新
• meta-release を書き換える迂回更新
• バックアップなしでの本番実施

これらは一般提供前の回避策として使われた例がありますが、現在の LTS 標準運用では不要です。正式経路は do-release-upgrade です。

13. 実施用コマンド一覧

最小手順のみ抜き出すと以下です。

sudo apt update
sudo apt upgrade
sudo apt full-upgrade
sudo apt autoremove --purge
sudo reboot
sudo do-release-upgrade
sudo reboot

14. 運用上の補足

構成管理済みサーバ、特にミドルウェアや仮想化機能を多数持つノードでは、インプレース更新よりも 24.04 ベースでの再構築・再デプロイ の方が整合性を保ちやすい場合があります。一方で、単機能サーバや一時用途サーバでは do-release-upgrade による更新が合理的です。これは Ubuntu の一般的な Server 更新方針と、24.04 への正式アップグレード経路の両方に整合します。

必要であれば次に、これをそのまま使える形で 「作業手順書」形式、または 「Ansible 管理サーバ向けの更新前後チェックリスト」形式 に展開します。

Related posts:

Ubuntu 24.04 LTS リリース Ubuntu 22.04 isc-dhcp-server DHCP サーバー構築 Ubuntu 22.04 389 Directory Server LDAP サーバー構築 #1 インスタンスの作成 Ubuntu 22.04 389 Directory Server LDAP サーバー構築 #2 TLS 有効化 Ubuntu 22.04 389 Directory Server LDAP サーバー構築 #3 ベースエントリーの登録 Ubuntu 22.04 389 Directory Server LDAP サーバー構築 #4 アクセス制御 Ubuntu 22.04 389 Directory Server LDAP サーバー構築 #5 グループとユーザーの登録 CentOS 8 389 Directory Server 構築 #1 導入 CentOS 8 389 Directory Server 構築 #2 初期データ登録 CentOS 8 389 Directory Server 構築 #3 BIND ユーザーとアクセス制御 CentOS 8 389 Directory Server LDAP サーバーと Samba の連携 CentOS 8 389 Directory Server Postfix とメールエイリアスの連携