この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
RHEL 8の通常サポートは2029年5月まで続きますが、現場で「9に上げておきたい」という話はもう普通に出てきます。新しいパッケージ、新しいカーネル、コンテナ周りの改善。理由はいくらでもあります。そして、RHELには8から9へクリーンインストールせずに上げるin-place upgradeの仕組み、Leappが用意されています。
私自身、20年以上Linuxサーバーを触ってきて、メジャーバージョンのアップグレードは何度も「やる・やらない」で悩む場面に立ち会ってきました。クリーンインストールして移し替えるのが一番確実なのは間違いありません。ただ、台数が多い、止められない、設定が複雑、という現場ほどin-place upgradeの価値が出てきます。
この記事では、Leappを使ったRHEL 8から9へのin-place upgradeを、実際のコマンドの流れに沿って手を動かす目線で書いていきます。leapp preupgradeでレポートをどう読むか、leapp upgradeを流すとサーバーで何が起きるか、そしてリポジトリ・カーネル・SELinux・残存パッケージといった「つまずきポイント」をどうさばくか。延命するかどうかという経営判断ではなく、現場の手順書として読んでもらえればと思います。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Leappによるin-place upgradeの全体像と前提条件
まず全体像です。Leappは、稼働中のRHEL 8を再インストールせずにRHEL 9へ移行するためのRed Hat公式ツールです。流れはシンプルで、事前チェック（preupgrade）→問題の解消→本番アップグレード（upgrade）→再起動→後始末という5段階になります。
手を動かす前に、前提条件を押さえておきます。一次情報（Red Hat公式ドキュメント）で確認できる範囲では、押さえるべきは次の点です。
- ソースは最新マイナーバージョン（RHEL 8.10）であることが基本。古いマイナーのままだと事前チェックで弾かれます
- ターゲットのRHEL 9マイナーバージョンを指定できる（例: 9.4、9.6など、サポートされる移行パスを確認する）
- 有効なサブスクリプションとリポジトリへのアクセスが必要
- ファイルシステムに十分な空き容量が必要（パッケージをまるごと入れ替えるため、特に
/varと/boot）
そして大前提として、必ずバックアップかスナップショットを取ってから始めること。これは強調しすぎることがないくらい重要です。in-place upgradeは「失敗したら戻れる状態」を作ってから踏み込むものです。仮想環境ならスナップショット、物理サーバーなら少なくとも設定ファイルとデータのフルバックアップを確保してから着手します。私は検証環境でもまずスナップショットを取る癖をつけています。
もう一点、最初の検証は本番ではなく本番とできるだけ同じ構成の検証機で回すのが鉄則です。同じパッケージ構成、同じリポジトリ、同じカスタム設定。本番でいきなりleapp preupgradeを打って、出てきたレポートを本番で初めて読む、という進め方は事故のもとです。
leapp preupgradeを実行してレポートを読む
では実際の手順に入ります。最初に、システムを最新のRHEL 8.10へ更新し、Leappツールを導入します。
# まず最新のRHEL 8.10へ
sudo dnf update -y
sudo reboot
# Leappツール一式を導入
sudo dnf install -y leapp-upgradeleapp-upgradeパッケージを入れると、leappコマンドと、移行に必要なデータファイル群が展開されます。続いて、本番アップグレードの前に必ず通すのが事前チェックです。
# ターゲットバージョンを指定して事前チェック
sudo leapp preupgrade --target 9.4このコマンドはシステムをスキャンするだけで、何も変更しません。終わると、レポートが2つのファイルに書き出されます。
/var/log/leapp/leapp-report.txt... 人が読むためのテキスト版/var/log/leapp/leapp-report.json... 機械処理用のJSON版
このleapp-report.txtを読むのが、Leapp作業のいちばん大事なところです。ここを雑に流すと、本番アップグレードで足をすくわれます。レポートの各項目にはリスクレベルが付いており、Red Hat公式では次のように定義されています。
| レベル | 意味 |
|---|---|
| Inhibitor（阻害要因） | 解消しない限りアップグレードを実行できないブロッカー |
| High | システム状態が悪化する可能性が高い |
| Medium | システムとアプリケーションの両方に影響しうる |
| Low | システムへの影響は小さいがアプリには影響しうる |
| Info | 情報提供のみ。影響は想定されない |
このうち、Inhibitorが出ている間はleapp upgradeを実行してもアップグレードは始まりません。まずInhibitorをゼロにすることが当面のゴールになります。High以下は「内容を理解した上で進める」判断ができますが、Inhibitorだけは問答無用で止められます。
多くのInhibitorには、レポート内にRemediation（対処の指示）がセットで書かれています。「この設定を変えろ」「このパッケージを消せ」という具体的な指示があれば、それに従って一つずつ潰していきます。レポートを上から順に読み、Remediationを実施し、再度leapp preupgradeを回してInhibitorが消えたか確認する。この往復が事前準備の本体です。
PR
バージョン8&9両対応! Red Hat Enterprise Linux完全ガイド
RHEL 8と9の差分を1冊で押さえられる国内では希少な解説書です。Leappのレポートに出てくる「9で変わった仕様」を理解する土台になるので、in-place upgradeを任される立場なら手元に置いておくと判断が速くなります。
典型的なInhibitorと現場での対処
preupgradeのレポートに出てくるInhibitorは現場ごとに違いますが、よく当たるパターンはある程度決まっています。代表的なものと、私が現場でどう対処しているかを並べておきます。
1. サードパーティ・野良パッケージ
Red Hat以外のベンダーが提供するパッケージや、独自に入れたRPMは、9側に対応物がないとレポートに挙がります。まず何が入っているかを棚卸しします。
# Red Hat以外のベンダー由来パッケージを洗い出す
rpm -qa --qf '%{NAME} %{VENDOR}\n' | grep -v 'Red Hat'不要なものは事前に削除し、業務上必要なものはベンダーのRHEL 9対応版に置き換える計画を立てます。「あとで入れ直す」と割り切れるものは、アップグレード前にいったん外すのが安全です。
2. リポジトリ設定の問題
無効化されていない外部リポジトリや、9で参照できないリポジトリがあると引っかかります。問題のあるリポジトリは事前に無効化しておきます。
# 問題のあるリポジトリを無効化
sudo dnf config-manager --set-disabled 問題のリポジトリID3. カーネル・ドライバ関連
RHEL 9で削除・非対応になったカーネルモジュールがロードされていると、Inhibitorになることがあります。レポートに該当モジュール名が出るので、その機能が本当に必要かを確認し、不要ならアンロードと自動ロード設定の解除を行います。ここは業務影響に直結するので、外す前に何のためのモジュールかを必ず確認します。
4. 確認待ち（answerfile）
Leappは、人間に判断を委ねたい項目を「質問」として保留します。たとえばPAMやリモートログインの扱いなど、勝手に決めてはいけない項目です。これらはleapp answerで明示的に回答します。
# レポートで案内された質問に回答する例
sudo leapp answer --section 質問ID.confirm=True回答内容は/var/log/leapp/answerfileに記録されます。どの質問にどう答えたかは作業ログとして残しておくと、後で振り返るときに役立ちます。
これらを潰して、再度leapp preupgradeを実行したときにInhibitorがゼロになれば、ようやく本番アップグレードに進める状態です。ここまでが全工程の8割と言っても言い過ぎではありません。焦らず、レポートと向き合う時間を惜しまないことが結果的に一番速い進め方になります。
leapp upgradeの実行と再起動時の挙動
Inhibitorがゼロになったら、本番アップグレードを実行します。コマンド自体は拍子抜けするほど短いです。
# 本番アップグレード（ターゲットを明示）
sudo leapp upgrade --target 9.4このコマンドは、RHEL 9のパッケージをダウンロードし、再起動後に適用するための準備を整えます。ここでもまだ実システムは8のままです。準備が完了したら、再起動します。
sudo rebootここからがin-place upgradeの本番です。再起動すると、システムは通常のRHEL 8ではなく、アップグレード専用の特別な環境（initramfs）で起動します。この中で、RHEL 8のパッケージがRHEL 9のパッケージへ次々と置き換えられていきます。サーバーのスペックやパッケージ数にもよりますが、ここはそれなりに時間がかかる工程です。
大事なのは、この間は絶対に電源を切らない・割り込まないこと。コンソールに進行状況が流れますが、途中で止めると中途半端な状態になり、復旧が一気に難しくなります。物理サーバーやクラウドのコンソール越しに作業しているなら、セッションが切れないように気を配ります。置き換えが完了すると、システムはもう一度自動で再起動し、今度はRHEL 9として立ち上がってきます。
つまり管理者から見える再起動は、leapp upgrade後に自分で実行する1回と、置き換え完了後の自動再起動の、合わせて2回というイメージになります。ログインプロンプトが返ってきたら、まずは無事に上がってきたことを確認します。
アップグレード後の確認と後始末
RHEL 9として起動してきたら、終わりではありません。むしろここからの確認と後始末が、運用品質を左右します。順番に見ていきます。
1. バージョンの確認
cat /etc/redhat-release
cat /etc/os-release
uname -rリリース表記が9系になっていること、カーネルが9系（el9）に切り替わっていることを確認します。
2. SELinuxを enforcing に戻す
ここは見落としやすい重要ポイントです。Leappはアップグレード中、トラブルを避けるためにSELinuxをpermissiveモードに落とします。RHEL 9になった後、必要なリラベル（ファイルのコンテキスト付け直し）を済ませてから、ポリシーに沿ってenforcingへ戻します。リラベルは/.autorelabelを作って再起動すると全体に対して実行されます。
# 現在のモードを確認
getenforce
# 全体リラベルを予約して再起動（規模により時間がかかる）
sudo touch /.autorelabel
sudo reboot
# リラベル後、enforcing に戻す（設定ファイルも合わせて更新）
sudo setenforce 1permissiveのまま放置すると、本来ブロックされるべきアクセスが素通りしてしまいます。「上がったから終わり」ではなく、SELinuxの状態まで戻して初めてアップグレード完了、という意識でいたほうがいいです。
3. 残存したRHEL 8パッケージの掃除
in-place upgradeでは、置き換えきれずにel8のまま残るパッケージが出ることがあります。残骸を洗い出して、不要なら整理します。
# el8 のまま残っているパッケージを確認
rpm -qa | grep el8
# Leapp関連の依存パッケージなど、不要な残骸を削除
sudo dnf remove leapp-deps-el9 leapp-repository-deps-el9残存パッケージは一律に消すのではなく、何が残っているかを目で見て、業務に必要なものとそうでないものを切り分けます。判断に迷うものは、いったん残してログに記録しておき、後日整理するくらいの慎重さでちょうどいいです。
4. サービスとシステムの健全性チェック
# 起動に失敗したユニットがないか
systemctl --failed
# パッケージ依存関係の整合性
sudo dnf checkfailedなユニットが出ていたら、ログ（journalctl -xeや各サービスのログ）を追って原因を切り分けます。アプリケーションが乗っているサーバーなら、当然そのアプリの動作確認まで通して、はじめて「アップグレードできた」と言えます。OSが9になっただけで安心しないことが、現場では一番大事です。
PR
Red Hat Enterprise Linux 9 対応 SELinux 入門
in-place upgrade後にいちばん躓きやすいのがSELinux周りです。permissiveから戻したらアプリがdenyされて慌てる、というのは典型例。リラベルやポリシー調整の勘どころを押さえておくと、アップグレード後の切り分けが格段に楽になります。
in-place upgradeを安全に回すために大切なこと
ここまでLeappの手順を一通り追ってきました。最後に、20年以上サーバーを触ってきた立場から、in-place upgradeを安全に回すための勘どころをまとめておきます。
まず、検証機での予行演習を省かないこと。本番と同じ構成でLeappを最後まで通しておけば、Inhibitorも、つまずきポイントも、おおよそ事前に把握できます。本番で初めて出会う問題を減らすことが、ダウンタイムを縮める一番の近道です。
次に、戻れる状態を必ず作ること。スナップショットやバックアップは保険ではなく前提です。in-place upgradeは「やり直しがきく」状態でこそ踏み込めるものだと考えています。
そして、Leappが万能ではないことも頭の片隅に置いておきます。構成が複雑なサーバー、特殊なカスタマイズが多いサーバーでは、クリーンインストールして移し替えたほうが結果的に速くて確実、というケースもあります。「Leappで上げられるか」と「Leappで上げるべきか」は別の問いです。台数・止められなさ・構成の複雑さを天秤にかけて、毎回フラットに判断する姿勢が、現場の管理者には求められます。
RHEL 8から9へのin-place upgradeは、手順そのものは決して難しくありません。難しいのは、preupgradeのレポートを丁寧に読み、自分のサーバーの事情に合わせて一つずつ問題を潰していく地味な作業です。逆に言えば、そこさえ手を抜かなければ、Leappは現役管理者にとって十分に頼れる道具になります。次にメジャーアップグレードを任されたときは、まず検証機でleapp preupgradeを一発打ってみるところから始めてみてください。
アップグレードの判断、自信を持って設計できますか？
Leappのレポートを読み、Inhibitorを潰し、SELinuxを戻す。一つひとつは地味でも、その判断の土台になるのは「Linuxサーバーをどう安全に構築・運用するか」という基礎の積み重ねです。
ネットの切れ端の情報をつなぎ合わせるのではなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：OpenZFS 2.4.3リリース｜暗号化・ブロッククローン修正が現役Linux管理者に持つ実務的な意味
- 前のページへ：Amazon Linux 2サポート終了2026年6月30日｜AL2023移行手順と残存確認の実務
- この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます