dnf から dnf5 へ移行する本番環境の動作差分確認｜プラグイン互換・スクリプト修正・ロールバック判断

なぜ今、dnf5 への移行が問題になるのか

Fedora 41 以降で dnf5 がデフォルトのパッケージマネージャとなり、Rocky Linux 10・AlmaLinux 10 でも採用が見込まれています。長年 dnf（dnf4）を前提に組まれてきた本番環境では、パッケージ操作スクリプトや CI/CD パイプライン、Ansible Playbook の一部が予告なく動作しなくなるケースが現場で報告されています。

dnf5 は「dnf4 の互換ラッパー」ではなく、C++ で一から書き直された別実装です。コマンド体系は大部分が踏襲されていますが、プラグイン API・出力フォーマット・設定ファイルの置き場が変わっており、「コマンド名が同じだから大丈夫」という判断が落とし穴になります。移行前に差分を体系的に把握しておくことが、本番障害を防ぐ最短経路です。

移行前に確認すべき3つのリスク領域

まずリスクを整理します。本番への影響が出やすい順に並べると次の3領域です。

• dnf プラグイン：dnf4 向けの Python プラグインは dnf5 では動作しません。代表的なものに dnf-plugin-versionlock・dnf-automatic・subscription-manager のサブコマンド群があります。
• スクリプト・Playbook：dnf repoquery の出力カラム順・--queryformat の挙動、dnf history undo の戻り値など、細部が変わっています。
• 設定ファイルのパス：/etc/dnf/dnf.conf は引き続き読まれますが、プラグイン設定は /etc/dnf/plugins/ から /etc/dnf5/dnf5-plugins/ 以下に移動しています。

プラグイン互換性の事前調査

現在インストール済みの dnf プラグインを一覧するには、次のコマンドで確認できます。

rpm -qa 'dnf-plugin-*' 'python3-dnf-plugin-*'

この出力リストを dnf5 向けの対応パッケージと照合します。2026年9月時点では、dnf5-plugin-automatic・dnf5-plugin-versionlock が提供されていますが、subscription-manager の一部サブコマンドは RHEL 系では段階的な移行中です。パッケージ名が変わっているものは移行前に置き換え、対応版が存在しないものはその機能を Playbook 側で代替する設計変更が必要です。

スクリプト差分の洗い出し

運用スクリプトや Ansible タスク内で dnf を呼んでいる箇所を抽出し、出力をパースしている部分を重点的に見ます。

grep -rn 'dnf ' /etc/cron* /etc/ansible /opt/scripts/ 2>/dev/null

特に注意が必要なのは repoquery の出力フォーマットです。dnf4 では %{name}-%{version}-%{release}.%{arch} 形式で --queryformat が機能しましたが、dnf5 では同等の機能が dnf5 repoquery --qf に移行しており、フォーマット文字列の一部が変わっています。また、dnf history のトランザクション ID の体系も変わっており、ID を保存して後から参照するスクリプトは要確認です。

ステージング環境での動作差分確認手順

本番に適用する前に、ステージング環境で以下の順序で差分を確認します。

dnf5 の並行インストールによる比較

Fedora 系では dnf4 と dnf5 を並行して存在させ、コマンドを明示的に使い分けることができます（移行期間中）。ステージング環境でこの状態を再現し、同一操作を両方で実行して出力差分を取ります。

# dnf4 側で実行
dnf repoquery --installed --qf '%{name} %{version} %{arch}' 2>/dev/null > /tmp/dnf4_list.txt

# dnf5 側で実行
dnf5 repoquery --installed --qf '%{name} %{version} %{arch}' 2>/dev/null > /tmp/dnf5_list.txt

diff /tmp/dnf4_list.txt /tmp/dnf5_list.txt

パッケージリストそのものより、フォーマットや列の順序の差異に着目します。スクリプトが awk '{print $1}' などで特定列を切り出している場合、列順が変わると誤動作します。

versionlock の動作確認

versionlock はカーネルや特定ミドルウェアのバージョンを固定するために多用されます。dnf5 では設定ファイルのパスと形式が変わっています。

# dnf4 の versionlock 設定確認
cat /etc/dnf/plugins/versionlock.list

# dnf5 向けに移行
dnf5 versionlock list
# 設定は /etc/dnf/versionlock.toml に移行

dnf4 の versionlock.list の内容を手動または変換スクリプトで versionlock.toml 形式に移す必要があります。移行ツールは2026年時点でコミュニティ製のものがいくつか存在しますが、本番適用前に必ず変換後の内容を dnf5 versionlock list で目視確認してください。

dnf-automatic から dnf5-plugin-automatic への移行

自動アップデートを dnf-automatic で運用している環境では、systemd ユニット名が変わります。

# 旧: dnf-automatic.timer
systemctl status dnf-automatic.timer

# dnf5 移行後: dnf5-automatic.timer
systemctl status dnf5-automatic.timer

監視ツールや Ansible の service モジュールでユニット名をハードコードしている場合は修正が必要です。また設定ファイルも /etc/dnf/automatic.conf から /etc/dnf5/automatic.conf に移動しているため、既存設定の移植も忘れずに行います。

ロールバック判断とリスク管理

dnf5 への移行後に問題が発生した場合、ロールバックの選択肢はディストリビューションと移行方法によって異なります。

Fedora での考え方

Fedora 41 以降では dnf5 がデフォルトですが、dnf4 コマンドは当面の間提供が続く見込みです。スクリプトが壊れた際の緊急回避として dnf4 を明示的に呼ぶ方法が使えますが、これはあくまで移行猶予期間中の措置です。Fedora のライフサイクル上、dnf4 の削除タイムラインを追跡しておく必要があります。

RHEL 系（Rocky Linux・AlmaLinux）での考え方

Rocky Linux 9・AlmaLinux 9 は2026年現在も dnf4 ベースです。RHEL 10 系列（Rocky 10・AlmaLinux 10）で dnf5 が採用されます。したがって RHEL 9 系から 10 系へのメジャーアップグレードが dnf5 移行のタイミングと一致します。この場合、OS のロールバックは スナップショット（仮想環境）や Leapp のロールバック機能が選択肢になります。

ロールバック判断の基準として現場では次の指標が参考にされています。

• パッケージ操作の失敗・ハングアップが移行後24時間以内に複数回発生した場合
• versionlock の設定が意図通り機能していないことが確認された場合（意図しないカーネルアップデートが発生する等）
• 監視・自動化ツールとの連携が失われ、手動対処コストが許容水準を超えた場合

逆に、コマンドの出力フォーマットの軽微な差異だけであればスクリプト側の修正で吸収できることが多く、OS ロールバックは不要です。影響範囲を切り分けてから判断することが重要です。

2026年時点の各ディストリビューション別状況

移行の緊急度はディストリビューションによって大きく異なります。2026年9月時点での状況を整理します。

• Fedora 41〜43：dnf5 がデフォルト。dnf4 コマンドは引き続き提供されているが、将来的に削除予定。新規構築は dnf5 前提での設計が推奨されます。
• RHEL 9 / Rocky Linux 9 / AlmaLinux 9：dnf4 のまま。EOL（2027年頃）まで変更なし。現時点での移行対応は不要ですが、10系への移行計画に dnf5 対応を組み込む必要があります。
• RHEL 10 / Rocky Linux 10 / AlmaLinux 10：dnf5 が標準。2026年後半から各コミュニティ版の一般提供が進む段階であり、早期採用環境では本記事の確認手順が直接必要になります。
• openSUSE / Arch：独自のパッケージマネージャを使用しており、dnf5 移行の直接的な影響はありません。

特にコンテナイメージを自社ビルドしている環境では、ベースイメージの更新タイミングで dnf5 が混入するケースがあります。FROM rockylinux:10 などのタグを指定した Dockerfile は、CI でのビルド時に dnf5 が使われているかを明示的に確認することが求められます。

移行を安全に進めるためのチェックポイント

まとめると、dnf から dnf5 への移行で本番影響を最小化するためのポイントは次のとおりです。

• インストール済みプラグインのリストを事前に取得し、dnf5 対応版の有無を確認する
• repoquery・history・versionlock など出力をパースしているスクリプトを洗い出し、ステージングで差分テストを実施する
• systemd ユニット名・設定ファイルパスの変更を監視ツールと Ansible 両面で反映する
• ロールバック判断の基準をあらかじめチームで合意しておき、移行後24〜48時間は主要なパッケージ操作を人手でモニタリングする
• コンテナイメージのベースタグをピン止めし、dnf5 が混入するタイミングを制御する

dnf5 はパフォーマンスと依存解決の精度において dnf4 を上回る設計になっており、長期的には運用コストの低減が期待できます。ただし移行コストは確実に存在するため、OS のメジャーアップグレードと同様に計画的なフェーズを設けて対応することが、現場での安定運用につながります。