第8章 アップグレード後のタスクの実行

1. snactor パッケージを含む、/etc/dnf/dnf.conf 設定ファイルの exclude リストから残りの Leapp パッケージを削除します。インプレースアップグレード中に、Leapp ユーティリティーでインストールされた Leapp パッケージが exclude リストに自動的に追加され、重要なファイルが削除または更新されないようにします。インプレースアップグレードの後、これらの Leapp パッケージをシステムから削除する前に、除外リストから削除する必要があります。

   • exclude リストからパッケージを手動で削除するには、/etc/dnf/dnf.conf 設定ファイルを編集し、除外 リストから必要な Leapp パッケージを削除します。

   • 除外 リストからすべてのパッケージを削除するには、次のコマンドを実行します。

     # yum config-manager --save --setopt exclude=''

2. 残りの Leapp パッケージを含む残りの RHEL 7 パッケージを削除します。

   1. 以前のカーネルバージョンを確認します。

      # cd /lib/modules && ls -d *.el7*

   2. 以前のカーネルから弱いモジュールを削除します。以前のカーネルが複数ある場合は、カーネルごとに次の手順を繰り返します。

      # [ -x /usr/sbin/weak-modules ] && /usr/sbin/weak-modules --remove-kernel <version>

      <version> を、前の手順で確認したカーネルバージョンに置き換えます。以下に例を示します。

      #  [ -x /usr/sbin/weak-modules ] && /usr/sbin/weak-modules --remove-kernel 3.10.0-1160.25.1.el7.x86_64

      注記

      以下のエラーメッセージは無視してください。これは、カーネルパッケージが過去に削除されている場合に生成されます。

      /usr/sbin/weak-modules: line 1081: cd: /lib/modules/<version>/weak-updates: No such file or directory

   3. 古いカーネルをブートローダーエントリーから削除します。以前のカーネルが複数ある場合は、カーネルごとにこの手順を繰り返します。

      # /bin/kernel-install remove <version> /lib/modules/<version>/vmlinuz

      version を、前の手順で確認したカーネルバージョンに置き換えます。以下に例を示します。

      # /bin/kernel-install remove 3.10.0-1160.25.1.el7.x86_64 /lib/modules/3.10.0-1160.25.1.el7.x86_64/vmlinuz

   4. 残りの RHEL 7 パッケージを見つけます。

      # rpm -qa | grep -e '\.el[67]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort

   5. RHEL 8 システムから、古いカーネルパッケージなど、残りの RHEL 7 パッケージと kernel-workaround パッケージを削除します。RPM の依存関係が維持されるようにするには、これらのアクションを実行するときに YUM または DNF を 使用します。受け入れる前にトランザクションを確認して、パッケージが誤って削除されないようにしてください。

      以下に例を示します。

      # yum remove kernel-workaround $(rpm -qa | grep \.el7 | grep -vE 'gpg-pubkey|libmodulemd|katello-ca-consumer')

   6. 残りの Leapp 依存関係パッケージを削除します。

      # yum remove leapp-deps-el8 leapp-repository-deps-el8

   7. 残っている古いディレクトリーを削除します。

      # rm -r /lib/modules/*el7*

3. ホストメータリングエージェントを通じて RHEL 7 ELS 課金を使用した場合は、ELS 証明書を削除します。

   # rm -f /etc/pki/product/204.pem

4. オプション: 残っているすべてのアップグレード関連データをシステムから削除します。

   # rm -rf /var/log/leapp /root/tmp_leapp_py3 /var/lib/leapp

   重要

   このデータを削除すると、Red Hat サポートによるアップグレード後の問題の調査とトラブルシューティングが制限される可能性があります。

5. RHEL 8 でパッケージをインストールまたは使用できない YUM リポジトリーを無効にします。RHSM によって管理されるリポジトリーは自動的に処理されます。これらのリポジトリーを無効にするには、以下を実行します。

   # yum config-manager --set-disabled <repository_id>

   <repository_id> はリポジトリー ID に置き換えます。

6. 古いレスキューカーネルと初期 RAM ディスクを現在のカーネルとディスクに置き換えます。

   1. 既存のレスキューカーネルと初期 RAM ディスクを削除します。

      # rm /boot/vmlinuz-*rescue* /boot/initramfs-*rescue* 

   2. レスキューカーネルと関連する初期 RAM ディスクを再インストールします。

      # /usr/lib/kernel/install.d/51-dracut-rescue.install add "$(uname -r)" /boot "/boot/vmlinuz-$(uname -r)"

      注記

      リアルタイムシステムなど、システムのカーネルパッケージの名前が異なる場合は、kernel-core を正しいパッケージ名に置き換えます。

   3. システムが IBM Z アーキテクチャーを使用している場合は、zipl ブートローダーを更新します。

      # zipl

7. オプション: rpmnew、rpmsave、leappsave ファイルを確認し、修正してから削除します。rpmsave と leappsave は同等であり、同様に処理できることに注意してください。詳細は、What are rpmnew & rpmsave files? を参照してください。
8. セキュリティーポリシーを再評価して再適用します。具体的には、SELinux モードを Enforcing に変更します。詳細は、セキュリティーポリシーの適用 を参照してください。

検証

1. 古いカーネルがブートローダーエントリーから削除されたことを確認します。

   # grubby --info=ALL | grep "\.el7" || echo "Old kernels are not present in the boot loader."

2. 以前に削除したレスキューカーネルとレスキュー初期 RAM ディスクファイルが現在のカーネル用に作成されていることを確認します。

   # ls /boot/vmlinuz-*rescue* /boot/initramfs-*rescue* 
   # lsinitrd /boot/initramfs-*rescue*.img | grep -qm1 "$(uname -r)/kernel/" && echo "OK" || echo "FAIL"

3. レスキューブートエントリーが既存のレスキューファイルを参照していることを確認します。grubby の出力を参照してください。

   # grubby --info $(ls /boot/vmlinuz-*rescue*)

4. すべての RHEL 7 パッケージが削除されたことを確認します。

   # rpm -qa | grep -e '\.el[67]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort

   注記

   このコマンドではサードパーティーのパッケージもリストされる場合があります。

5. ホストメータリングエージェントを介して RHEL 7 ELS 課金を使用した場合は、ELS アドオンがインストールされておらず、関連する証明書がシステムに存在しないことを確認します。

   # subscription-manager list --installed
   # ls /etc/pki/product/204.pem && echo "The ELS certificate is still present."

   インストールされている製品のエンジニアリング製品 ID が 204 であるか、証明書が存在する場合は、ELS がシステム上でまだアクティブになっている可能性があり、引き続き課金される可能性があります。