Ubuntu Server 22.04 LTS から 24.04 LTS へインプレースアップグレードすることは可能です。標準的には do-release-upgrade を使用します。ただし、サーバー管理の観点では、私はこの方法を基本的には推奨しません。
書籍
Ubuntu Server の運用項目を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
結論: 基本的にはクリーンインストール推奨
サーバー用途では、22.04 から 24.04 へそのまま更新するより、24.04 をクリーンインストールし、設定とデータを移行する方が運用として適切だと考えます。
- リリースアップグレードは非常に時間がかかる。
- 内部的に不要なパッケージ、古い設定、過去の依存関係が残りやすい。
- 更新中の判断が多く、設定ファイル差分の扱いを誤るとサービスに影響する。
- サーバー管理としては、OS の状態を明確に作り直す方が監査しやすい。
- Ansible などで構成を管理している場合、クリーンインストールして再適用する方が再現性が高い。
インプレースアップグレードが向いていない理由
デスクトップ環境であれば、利用者の設定やアプリケーションを維持したまま更新したいという理由があります。しかし、サーバーは本来、構成、設定、データ、役割を分離して管理するべきです。OS 本体を長期間継ぎ足して使うほど、状態は読みづらくなります。
| 観点 | インプレースアップグレードの問題 |
| 時間 | パッケージ数や環境により長時間かかる |
| 状態管理 | 過去のパッケージや設定が残りやすい |
| 再現性 | 同じ結果を別ホストで再現しにくい |
| 障害時対応 | 途中失敗時の復旧判断が難しい |
| 構成管理 | Ansible などの正本と実機状態がずれやすい |
推奨する進め方
基本方針は、既存サーバーをそのまま 24.04 へ上げるのではなく、24.04 の新規環境を作り、必要な設定とデータだけを移行することです。
- Ubuntu Server 24.04 LTS をクリーンインストールする。
- ネットワーク、ユーザー、SSH、NTP、firewall などの基本設定を構成管理で適用する。
- アプリケーションを新規に構築する。
- データ、証明書、必要な設定ファイルだけを移行する。
- 新旧環境で動作確認してから切り替える。
- 旧環境は一定期間保持し、問題なければ廃止する。
それでも do-release-upgrade を使う場合
検証環境、停止許容のある小規模環境、またはクリーンインストールが現実的でない環境では、do-release-upgrade を使うこともあります。その場合も、これは推奨手順というより、例外的な更新手段として扱います。
実施する場合は、バックアップまたはスナップショットを取得し、SSH 断対策を行い、外部リポジトリや追加パッケージを確認してから進めます。
事前確認
lsb_release -a
uname -r
apt-mark showhold
sudo apt update
sudo apt upgrade
sudo apt full-upgrade
sudo apt autoremove --purge外部リポジトリと追加パッケージ
PPA、ベンダー独自リポジトリ、手動導入した .deb、DKMS、外部カーネルモジュールは、リリースアップグレード時の失敗要因になりやすいです。
grep -R "^deb " /etc/apt/sources.list /etc/apt/sources.list.d/ || true
apt list --installed | grep -E 'dkms|linux-modules|nvidia|zfs' || true直前の再起動と状態確認
sudo rebootsystemctl --failed
sudo dpkg --configure -a
sudo apt --fix-broken install
sudo apt updateSSH 経由で実施する場合
SSH 経由で実施する場合は、tmux や screen を使用します。ただし、可能であれば仮想基盤コンソール、IPMI、iDRAC、iLO などの別経路を確保します。
sudo apt install -y tmux
tmux new -s ubuntu-upgradeリリースアップグレード
標準経路で実施する場合は do-release-upgrade を使用します。-d を付けた開発版経路や、meta-release の書き換えによる迂回は通常の運用では使いません。
sudo do-release-upgrade更新中の判断ポイント
- 設定ファイルを保持するか、配布元の設定へ置き換えるか。
- 削除されるパッケージがサーバー役割に影響しないか。
- サードパーティパッケージが無効化または削除されるか。
- サービス再起動を許容できるか。
特に /etc 配下を手動変更しているサーバーでは、設定ファイル差分の確認が最重要です。SSH、ネットワーク、ファイアウォール、名前解決、時刻同期、監視、バックアップ関連の設定は不用意に上書きしないようにします。
更新後の確認
sudo rebootlsb_release -a
uname -r
systemctl --failed
sudo apt update
sudo apt autoremove --purge
ip addr
ip route
resolvectl status
findmnt
ss -lntup確認すべきサービス
| 項目 | 確認内容 |
| ネットワーク | IP アドレス、ルーティング、DNS、外部疎通 |
| SSH | 管理ユーザーでログインできるか |
| 時刻同期 | systemd-timesyncd、chrony、NTP の状態 |
| ファイアウォール | ufw、iptables、nftables、外部公開ポート |
| ストレージ | fstab、NFS、LVM、マウント状態 |
| サービス | Web、DB、監視、バックアップ、メールなど |
| コンテナ | Docker、Podman、Kubernetes、MicroK8s など |
| ログ | journalctl、syslog、アプリケーションログ |
推奨しない進め方
- バックアップなしで本番環境を更新する。
- 通常更新を残したままリリースアップグレードする。
- PPA や外部リポジトリの影響を確認しない。
-dオプションで通常経路ではない更新を行う。- SSH だけで作業し、切断時の復旧経路を用意しない。
- 構成管理で再構築できる環境なのに、惰性でインプレース更新する。
まとめ
Ubuntu Server 22.04 LTS から 24.04 LTS へのインプレースアップグレードは可能です。しかし、サーバー管理としては基本的にクリーンインストールを推奨します。リリースアップグレードは時間がかかり、古い状態や不要な依存関係が残りやすく、結果として OS の状態が読みづらくなります。
特に Ansible などで構成を管理している場合、OS は新規に作り、構成を再適用し、データだけを移行する方が健全です。do-release-upgrade は標準経路ではありますが、運用設計として常に最善とは限りません。
Related posts:
Ubuntu 22.04 isc-dhcp-server DHCP サーバー構築
Ubuntu 22.04 389 Directory Server #1 – インスタンス作成と suffix 設計
Ubuntu 22.04 389 Directory Server #2 – TLS 有効化と LDAPS 設定
Ubuntu 22.04 389 Directory Server #3 – ベースエントリーの登録
Ubuntu 22.04 389 Directory Server #4 – BIND ユーザーとアクセス制御
Ubuntu 22.04 389 Directory Server #5 – グループとユーザーの登録
Ubuntu 26.04 SSH client/server 設定
netplan apply で ovsdb-server.service is not running と表示される原因 – Open vSwitch を使わない環境での考え方
Ubuntu 22.04 CentOS と Ubuntu の違い
Ubuntu 22.04 USB-SSD の利用
Ubuntu 26.04 サーバー管理ガイド
Ubuntu 26.04 複数 NIC の基本設定