この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
「leappやdo-release-upgradeを実行する前に、何を確認すればいいのかわからない」
こうした不安を抱えているエンジニアは、今も現場に多くいます。私がSEとして働いていた2001年～2006年の頃も同様で、OSのバージョンアップというのは「触れてはいけない聖域」のような存在でした。「動いているサーバーをいじるな」という暗黙のルールが現場には根付いていて、アップグレードなど提案しようものなら先輩から怪訝な顔をされたものです。
この記事では、20年以上Linuxサーバーを運用してきた経験から、OSアップグレードを怖がらなくなるまでの道筋と、今の現場でどう向き合えばいいかを解説します。
この記事のポイント
・OSアップグレードの恐怖の正体は「何が壊れるかわからない」という不確実性だ
・事前確認（依存パッケージ・カーネル互換性）で不確実性は8割削減できる
・検証環境でのリハーサルこそが本番での冷静さを生む
・leapp / dist-upgradeは「怖いもの」ではなく「段取りが全て」のツールだ
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
「動いているサーバーを触るな」という現場の空気
SE時代に所属していたチームには、古株のベテランエンジニアがいました。彼は技術力が高く、現場の信頼も厚い人でした。しかし、OS周りの話になると必ずこう言いました。「アップグレードは最終手段だ。動いているなら触るな。」
当時の私はその言葉を素直に受け入れていました。実際、Red Hat Linux 7系から8系への移行で依存関係が崩れてApacheが起動しなくなった事例を見ていたので、怖さには根拠があったのです。
ただ、今振り返れば、あの恐怖は「何が壊れるかわからない」という不確実性への恐怖であって、アップグレードという行為そのものへの恐怖ではなかったと気づきます。
「怖い」の正体を分解する
OSアップグレードが怖い理由を、私なりに分解してみます。1. 依存関係の破綻
自分でインストールしたパッケージや独自にビルドしたライブラリが、新しいOS上でそのまま動く保証はありません。特に古いRHEL系では、PHP・MySQL・Pythonのバージョンが大きく変わることがあり、Webアプリが軒並み動かなくなる事例を何度も見てきました。# RHEL8 -> RHEL9でPhpが変わる例（leapp確認時の出力） # Warning: Python 3.9 -> 3.11 upgrade may break dependencies # Warning: libmysqlclient.so.18 -> libmysqlclient.so.21 # 事前確認コマンド（leapp環境の場合） $ sudo leapp preupgrade --target 9.4 2>&1 | grep -E "Warning|Error" | head -20
2. カーネルの互換性
カーネルバージョンが大きく変わると、独自のカーネルモジュールや古いハードウェアドライバが動作しなくなることがあります。私が経験した中で印象的だったのは、SANストレージのドライバがカーネルアップグレードで認識されなくなり、ファイルシステムがマウントできなくなったケースです。これは本当に冷や汗ものでした。3. 設定ファイルの上書き
/etc/以下の設定ファイルが新しいデフォルト値で上書きされ、個別カスタマイズが消えてしまうことがあります。sudoの設定、sshdの設定、cronの内容。これらが全部デフォルトに戻ったら、手動で一から確認し直すことになります。転換点——「段取りが全て」に気づいた日
私がOSアップグレードを怖がらなくなった転換点は、2004年頃に参加したあるプロジェクトでのことです。そのプロジェクトでは、Red Hat Enterprise Linux 3からRHEL 4への移行を担当するエンジニアがいました。彼のやり方は私が見てきた他の人と全く違いました。
彼がやっていた4つのこと
・本番と同一構成の検証機を用意する：「同じOS・同じパッケージ・同じ設定ファイル」という3つの同一性を確保していました。スペックを完全一致させる必要はなく、ソフトウェア構成の同一性だけを徹底していました。・インストール済みパッケージの全量リストを作る：`rpm -qa` の出力をCSV化し、新環境で全て入れ直せる状態を作っていました。
・カスタマイズ箇所の「差分リスト」を作る：`diff /etc/default-backup /etc/current` を使い、デフォルトから何を変えたかを一覧化していました。
・ロールバック手順を先に書く：「アップグレードが失敗したらどう戻すか」を作業開始前に完成させていました。
これを見て「なるほど、怖さの正体は段取りの不足だった」と気づきました。
現代のツールでどう向き合うか
今は当時よりアップグレードを支援するツールが充実しています。1. leapp（RHEL系のin-placeアップグレード）
RHEL 7→8、RHEL 8→9のin-placeアップグレードに使います。本番適用前に `leapp preupgrade` を実行することで、互換性の問題を事前に洗い出せます。# 事前チェック（本番環境で実行OK、変更は加えない） $ sudo leapp preupgrade --target 9.4 # レポートを確認する $ sudo leapp report # ファイルに保存して読む $ cat /var/log/leapp/leapp-report.txt | less
2. dist-upgrade（Debian/Ubuntu系）
Ubuntu 22.04→24.04のアップグレードなら `do-release-upgrade` を使います。# 現在のリリースを確認 $ lsb_release -a # アップグレード可能か確認 $ sudo do-release-upgrade -c # tmuxかscreenの中で実行（SSH切断対策） $ tmux new -s upgrade $ sudo do-release-upgrade
「失敗から学んだ」と言える構造を作る
検証環境でのリハーサルは、単なる技術確認ではありません。「この手順で失敗した」「このエラーが出た時はこうする」という自分だけの知識を積み上げる場です。セミナーで3,100名以上を指導してきた中で、アップグレードが怖い人の共通点があります。それは「失敗を経験していない」ことです。検証環境でわざと失敗し、ロールバックを体験することで、本番での怖さは劇的に下がります。
私が初めてOSアップグレードを一人で担当した時、検証環境で3回失敗しました。3回目の失敗後にようやく「何が起きても対処できる」という確信が生まれ、本番では一発でうまくいきました。
アップグレード中によく起きるエラーと対処法
アップグレード作業では、予期しないエラーに遭遇することがあります。現場でよく見かけるパターンをまとめておきます。leapp: 「Inhibitor」が消えない場合
# inhibitorの詳細を確認する $ sudo cat /var/log/leapp/leapp-report.txt | grep -A 10 "inhibitor" # よくある原因1: 削除済みパッケージの残骸 # rpm -qa | grep "kernel-" で古いカーネルヘッダーが残っていないか確認 $ rpm -qa | grep kernel # よくある原因2: サードパーティのリポジトリが有効 $ yum repolist enabled | grep -v "rhel\|rhui" # サードパーティrepoは一時的に無効化する $ sudo yum-config-manager --disable <リポジトリID>
do-release-upgrade: 途中でエラー終了した場合
# ログを確認する（タイムスタンプ付きで詳細が出る） $ cat /var/log/dist-upgrade/main.log | tail -50 # パッケージロックが残っている場合 $ sudo rm /var/lib/dpkg/lock-frontend $ sudo dpkg --configure -a # upgradeを途中から再開する（再実行で続きから） $ sudo do-release-upgrade
まとめ
| 場面 | やること |
|---|---|
| 事前確認（RHEL系） | sudo leapp preupgrade --target 9.4 |
| inhibitor確認 | cat /var/log/leapp/leapp-report.txt |
| 事前確認（Ubuntu系） | sudo do-release-upgrade -c |
| SSH越しのアップグレード | tmux new -s upgrade内で実行 |
| インストール済みパッケージ確認 | rpm -qaまたはdpkg -lで一覧保存 |
| セッション切断後の復帰 | tmux attach -t upgrade |
関連記事として、以下もあわせてご参照ください。
・マウント・fstabの設定方法｜アップグレード後のディスク確認に
・本記事のパーマリンク
OSアップグレードも「型」で乗り切れる環境、準備できていますか？
アップグレードが怖い理由は、段取りと基礎知識の不足にある。まずは体系的にまとめられた教材で、Linuxサーバー運用の全体像を掴んでください。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxで初めてrootになった日の話｜手が震えた経験と20年後に伝えたいroot運用の3つの心得
- 前のページへ：Linuxの資格試験を受けに行った日の記憶｜現役講師が語るLPIC受験当日のリアルと合格後に気づいたことの差
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます