第11章 既知の問題
ここでは、Red Hat Enterprise Linux 9.4 の既知の問題を説明します。
11.1. インストーラーおよびイメージの作成
キックスタートコマンドの auth および authconfig で AppStream リポジトリーが必要になる
インストール中に、キックスタートコマンドの auth および authconfig で authselect-compat パッケージが必要になります。auth または authconfig を使用したときに、このパッケージがないとインストールに失敗します。ただし、設計上、authselect-compat パッケージは AppStream リポジトリーでのみ使用可能です。
この問題を回避するには、BaseOS リポジトリーおよび AppStream リポジトリーがインストールプログラムで利用できることを確認するか、インストール中にキックスタートコマンドの authselect コマンドを使用します。
Bugzilla:1640697[1]
reboot --kexec コマンドおよび inst.kexec コマンドが、予測可能なシステム状態を提供しない
キックスタートコマンド reboot --kexec またはカーネル起動パラメーター inst.kexec で RHEL インストールを実行しても、システムの状態が完全な再起動と同じになるわけではありません。これにより、システムを再起動せずにインストール済みのシステムに切り替えると、予期しない結果が発生することがあります。
kexec 機能は非推奨になり、Red Hat Enterprise Linux の今後のリリースで削除されることに注意してください。
Bugzilla:1697896[1]
Anaconda がアプリケーションとして実行されているシステムでの予期しない SELinux ポリシー
Anaconda がすでにインストールされているシステムでアプリケーションとして実行されている場合 (たとえば、–image anaconda オプションを使用してイメージファイルに別のインストールを実行する場合)、システムはインストール中に SELinux のタイプと属性を変更することを禁止されていません。そのため、SELinux ポリシーの特定の要素は、Anaconda が実行されているシステムで変更される可能性があります。
この問題を回避するには、実稼働システムで Anaconda を実行しないでください。代わりに、一時的な仮想マシンで Anaconda を実行して、実稼働システムの SELinux ポリシーを変更しないようにします。boot.iso や dvd.iso からのインストールなど、システムインストールプロセスの一部として anaconda を実行しても、この問題の影響は受けません。
サードパーティーのツールを使用して作成した USB からインストールを起動する際に、Local Media のインストールソースが検出されない
サードパーティーのツールを使用して作成された USB から RHEL インストールを起動すると、インストールプログラムが Local Media インストールソースを検出できません (Red Hat CDN のみが検出されます)。
この問題は、デフォルトの起動オプション int.stage2= が iso9660 イメージ形式の検索を試みるためです。ただし、サードパーティーツールは、別の形式の ISO イメージを作成する可能性があります。
回避策として、以下のソリューションのいずれかを使用します。
-
インストールの起動時に
Tabキーをクリックしてカーネルコマンドラインを編集し、起動オプションinst.stage2=をinst.repo=に変更します。 - Windows で起動可能な USB デバイスを作成するには、Fedora Media Writer を使用します。
- Rufus などのサードパーティーツールを使用して起動可能な USB デバイスを作成する場合は、最初に Linux システムで RHEL ISO イメージを再生成し、サードパーティーのツールを使用して起動可能な USB デバイスを作成します。
指定の回避策を実行する手順の詳細は、Installation media is not auto-detected during the installation of RHEL 8.3 を参照してください。
Bugzilla:1877697[1]
USB CD-ROM ドライブが Anaconda のインストールソースとして利用できない
USB CD-ROM ドライブがソースで、キックスタート ignoredisk --only-use= コマンドを指定すると、インストールに失敗します。この場合、Anaconda はこのソースディスクを見つけ、使用できません。
この問題を回避するには、harddrive --partition=sdX --dir=/ コマンドを使用して USB CD-ROM ドライブからインストールします。その結果、インストールは失敗しなくなりました。
iso9660 ファイルシステムで、ハードドライブがパーティション分割されたインストールが失敗する
ハードドライブが iso9660 ファイルシステムでパーティションが設定されているシステムには、RHEL をインストールできません。これは、iso9660 ファイルシステムパーティションを含むハードディスクを無視するように設定されている、更新されたインストールコードが原因です。これは、RHEL が DVD を使用せずにインストールされている場合でも発生します。
この問題を回避するには、インストールの開始前に、キックスタートファイルに次のスクリプトを追加して、ディスクをフォーマットします。
メモ: 回避策を実行する前に、ディスクで利用可能なデータのバックアップを作成します。wipefs は、ディスク内の全データをフォーマットします。
%pre
wipefs -a /dev/sda
%endその結果、インストールでエラーが発生することなく、想定どおりに機能します。
Anaconda が管理者ユーザーアカウントの存在の確認に失敗する
グラフィカルユーザーインターフェイスを使用して RHEL をインストールしている場合に、管理者アカウントが作成されていると、Anaconda が確認に失敗します。その結果、管理者ユーザーアカウントがなくても、システムをインストールできてしまう可能性があります。
この問題を回避するには、管理者ユーザーアカウントを設定するか、root パスワードを設定して、root アカウントのロックを解除します。その結果、インストール済みシステムで管理タスクを実行できます。
新しい XFS 機能により、バージョン 5.10 よりも古いファームウェアを持つ PowerNV IBM POWER システムが起動しなくなる
PowerNV IBM POWER システムは、ファームウェアに Linux カーネルを使用し、GRUB の代わりに Petitboot を使用します。これにより、ファームウェアカーネルのマウント /boot が発生し、Petitboot が GRUB 設定を読み取り、RHEL を起動します。
RHEL 9 カーネルでは、XFS ファイルシステムに bigtime=1 機能および inobtcount=1 機能が導入されています。これは、バージョン 5.10 よりも古いファームウェアのカーネルが理解できません。
この問題を回避するには、/boot に別のファイルシステム (ext4 など) を使用できます。
Bugzilla:1997832[1]
rpm-ostree ペイロードをインストールすると、RHEL for Edge インストーラーイメージがマウントポイントの作成に失敗する
RHEL for Edge インストーラーイメージなどで使用される rpm-ostree ペイロードをデプロイする場合、インストールプログラムがカスタムパーティションの一部のマウントポイントを適切に作成しません。その結果、インストールは以下のエラーで中止されます。
The command 'mount --bind /mnt/sysimage/data /mnt/sysroot/data' exited with the code 32.
この問題を回避するには、以下を実行します。
- 自動パーティション設定スキームを使用し、手動でマウントポイントを追加しないでください。
-
マウントポイントは、
/varディレクトリー内のみに手動で割り当てます。たとえば、/var/my-mount-pointや、/、/boot、/varなどの標準ディレクトリーです。
その結果、インストールプロセスは正常に終了します。
ネットワークに接続されているが、DHCP または静的 IP アドレスが設定されていない場合、NetworkManager はインストール後に起動に失敗する
RHEL 9.0 以降、特定の ip= またはキックスタートネットワーク設定が設定されていない場合、Anaconda はネットワークデバイスを自動的にアクティブ化します。Anaconda は、イーサネットデバイスごとにデフォルトの永続的な設定ファイルを作成します。接続プロファイルには、ONBOOT と autoconnect の値が true に設定されています。その結果、インストールされたシステムの起動中に、RHEL がネットワークデバイスをアクティブ化し、networkManager-wait-online サービスが失敗します。
回避策として、以下のいずれかを実行します。
使用する 1 つの接続を除いて、
nmcliユーティリティーを使用してすべての接続を削除します。以下に例を示します。すべての接続プロファイルを一覧表示します。
# nmcli connection show
不要な接続プロファイルを削除します。
# nmcli connection delete <connection_name>
<connection_name> を、削除する接続の名前に置き換えます。
特定の
ip=またはキックスタートネットワーク設定が設定されていない場合は、Anaconda の自動接続ネットワーク機能を無効にします。- Anaconda GUI で、Network & Hostname に移動します。
- 無効にするネットワークデバイスを選択します。
- Configure をクリックします。
- General タブで、Connect automatically with priority チェックボックスをオフにします。
- Save をクリックします。
Bugzilla:2115783[1]
キックスタートインストールでネットワーク接続の設定に失敗する
Anaconda は、NetworkManager API を通じてのみキックスタートネットワーク設定を実行します。Anaconda は、%pre キックスタートセクションの後にネットワーク設定を処理します。その結果、キックスタート %pre セクションの一部のタスクがブロックされます。たとえば、%pre セクションからのパッケージのダウンロードは、ネットワーク設定が利用できないため失敗します。
この問題を回避するには、以下を実行します。
-
たとえば、
%preスクリプトの一部としてnmcliツールを使用して、ネットワークを設定します。 -
インストールプログラムのブートオプションを使用して、
%preスクリプトのネットワークを設定します。
その結果、%pre セクションのタスクにネットワークを使用できるようになり、キックスタートインストールプロセスが完了します。
RHEL Image Builder を使用して rpm-ostree イメージをビルドする場合、FIPS モードの有効化はサポート対象外
現在、RHEL Image Builder を使用して rpm-ostree イメージをビルドするときに FIPS モードを有効にすることはサポートされていません。
stig プロファイル修復でビルドされたイメージが FIPS エラーで起動に失敗する
FIPS モードは、RHEL Image Builder ではサポートされていません。xccdf_org.ssgproject.content_profile_stig プロファイル修復でカスタマイズされた RHEL Image Builder を使用すると、システムは次のエラーで起動に失敗します。
Warning: /boot//.vmlinuz-<kernel version>.x86_64.hmac does not exist FATAL: FIPS integrity test failed Refusing to continue
/boot ディレクトリーが別のパーティションにあるため、システムイメージのインストール後に fips-mode-setup --enable コマンドを使用して FIPS ポリシーを手動で有効にしても機能しません。FIPS が無効になっている場合、システムは正常に起動します。現在、使用可能な回避策はありません。
イメージのインストール後に、fips-mode-setup --enable コマンドを使用して、FIPS を手動で有効にすることができます。
ドライバーディスクメニューがコンソールでユーザー入力を表示できない
ドライバーディスクを使用して、カーネルコマンドラインで inst.dd オプションを使用して RHEL インストールを開始すると、コンソールにユーザー入力が表示されません。そのため、アプリケーションがユーザー入力に応答せず、応答を停止しているように見えますが、出力は表示されます。これはユーザーにはわかりにくい動作です。ただし、この動作は機能に影響を与えず、Enter を押すとユーザー入力が登録されます。
回避策として、予想される結果を確認するには、コンソールでユーザー入力が存在しないことを無視し、入力の追加が終了したら Enter を押します。
%packages セクションに systemd サービスファイルを含むパッケージがないため、キックスタートインストールが失敗する
キックスタートファイルで services --enabled=… ディレクティブを使用して systemd サービスを有効にし、指定したサービスファイルを含むパッケージが %packages セクションに含まれていない場合、RHEL のインストールプロセスは次のエラーで失敗します。
Error enabling service <name_of_the_service>
この問題を回避するには、キックスタートの %packages セクションに、サービスファイルを含むパッケージを追加します。こうすることで、インストール中に期待されるサービスが有効になり、RHEL のインストールが完了します。
Jira:RHEL-9633[1]
bootc-image-builder はプライベートレジストリーからのイメージの構築をサポートしていません
現在、bootc-image-builder を使用してプライベートレジストリーから取得されるベースディスクイメージを構築することはできません。この問題を回避するには、プライベートレジストリーをローカルホストにコピーし、次の引数を使用してイメージをビルドします。
-
--local -
localhost/<image name>:tagas the image
たとえば、イメージをビルドするには、次のようにします。
sudo podman run \ --rm \ -it \ --privileged \ --pull=newer \ --security-opt label=type:unconfined_t \ -v ./config.toml:/config.toml \ -v ./output:/output \ -v /var/lib/containers/storage:/var/lib/containers/storage \ registry.redhat.io/rhel9/bootc-image-builder:latest --type qcow2 \ --local \ quay.io/<namespace>/<image>:<tag>
古いネットワークリンク設定ファイルにより OS が起動できない
RHEL インストーラーは、インストール中に古い /etc/systemd/network/ リンク設定ファイルを作成します。このファイルは、インターフェイス名を MAC アドレスにマッピングするものであり、ネットワーク設定が変更されたときに問題発生の原因になります。具体的には、古いファイルは対象のネットワーク設定に干渉します。これにより、NVMe over TCP から起動する場合にシステムが起動できなくなります。この問題を回避するには、/etc/systemd/network/10-anaconda-ifname-nbft*.link ファイルを手動で削除し、dracut -f コマンドを実行して initramfs 一時ルートファイルシステムを再生成します。
Jira:RHELDOCS-18924
RHEL インストーラーは、iSCSI デバイスを aarch64 の起動デバイスとして自動的に検出または使用しません。
aarch64 で実行している RHEL インストーラーに iscsi_ibft カーネルモジュールがないと、ファームウェアで定義された iSCSI デバイスの自動検出ができなくなります。これらのデバイスはインストーラーに自動的に表示されず、GUI を使用して手動で追加した場合はブートデバイスとして選択できません。回避策として、インストーラーを起動するときにカーネルコマンドラインで "inst.nonibftiscsiboot" パラメーターを追加し、GUI 経由で iSCSI デバイスを手動で接続します。その結果、インストーラーは、接続されている iSCSI デバイスを起動可能として認識し、インストールを期待どおりに完了できます。
詳細は、KCS ソリューション を参照してください。
Jira:RHEL-56135
