第9章 既知の問題


ここでは、Red Hat Enterprise Linux 9.5 の既知の問題を説明します。

9.1. インストーラーおよびイメージの作成

キックスタートコマンドの auth および authconfig で AppStream リポジトリーが必要になる

インストール中に、キックスタートコマンドの auth および authconfigauthselect-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.isodvd.iso からのインストールなど、システムインストールプロセスの一部として anaconda を実行しても、この問題の影響は受けません。

Bugzilla:2050140

サードパーティーのツールを使用して作成した 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 ドライブからインストールします。その結果、インストールは失敗しなくなりました。

Jira:RHEL-4707

iso9660 ファイルシステムで、ハードドライブがパーティション設定されたインストールが失敗する

ハードドライブが iso9660 ファイルシステムでパーティションが設定されているシステムには、RHEL をインストールできません。これは、iso9660 ファイルシステムパーティションを含むハードディスクを無視するように設定されている、更新されたインストールコードが原因です。これは、RHEL が DVD を使用せずにインストールされている場合でも発生します。

この問題を回避するには、インストールの開始前に、キックスタートファイルに次のスクリプトを追加して、ディスクをフォーマットします。

メモ: 回避策を実行する前に、ディスクで利用可能なデータのバックアップを作成します。wipefs は、ディスク内の全データをフォーマットします。

%pre
wipefs -a /dev/sda
%end

その結果、インストールでエラーが発生することなく、想定どおりに機能します。

Jira:RHEL-4711

Anaconda が管理者ユーザーアカウントの存在の確認に失敗する

グラフィカルユーザーインターフェイスを使用して RHEL をインストールしている場合に、管理者アカウントが作成されていると、Anaconda が確認に失敗します。その結果、管理者ユーザーアカウントがなくても、システムをインストールできてしまう可能性があります。

この問題を回避するには、管理者ユーザーアカウントを設定するか、ルートパスワードを設定して、ルートアカウントのロックを解除します。その結果、インストール済みシステムで管理タスクを実行できます。

Bugzilla:2047713

新しい 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 などの標準ディレクトリーです。

その結果、インストールプロセスは正常に終了します。

Jira:RHEL-4741

ネットワークに接続されているが、DHCP または静的 IP アドレスが設定されていない場合、NetworkManager はインストール後に起動に失敗する

RHEL 9.0 以降、特定の ip= またはキックスタートネットワーク設定が設定されていない場合、Anaconda はネットワークデバイスを自動的にアクティブ化します。Anaconda は、イーサネットデバイスごとにデフォルトの永続的な設定ファイルを作成します。接続プロファイルには、ONBOOTautoconnect の値が true に設定されています。その結果、インストールされたシステムの起動中に、RHEL がネットワークデバイスをアクティブ化し、networkManager-wait-online サービスが失敗します。

回避策として、以下のいずれかを実行します。

  • 使用する 1 つの接続を除いて、nmcli ユーティリティーを使用してすべての接続を削除します。以下に例を示します。

    1. すべての接続プロファイルを一覧表示します。

      # nmcli connection show
    2. 不要な接続プロファイルを削除します。

      # nmcli connection delete <connection_name>

      <connection_name> を、削除する接続の名前に置き換えます。

  • 特定の ip= またはキックスタートネットワーク設定が設定されていない場合は、Anaconda の自動接続ネットワーク機能を無効にします。

    1. Anaconda GUI で、Network & Host Name に移動します。
    2. 無効にするネットワークデバイスを選択します。
    3. Configure をクリックします。
    4. General タブで、Connect automatically with priority チェックボックスをオフにします。
    5. Save をクリックします。

Bugzilla:2115783[1]

キックスタートインストールでネットワーク接続の設定に失敗する

Anaconda は、NetworkManager API を通じてのみキックスタートネットワーク設定を実行します。Anaconda は、%pre キックスタートセクションの後にネットワーク設定を処理します。その結果、キックスタート %pre セクションの一部のタスクがブロックされます。たとえば、%pre セクションからのパッケージのダウンロードは、ネットワーク設定が利用できないため失敗します。

この問題を回避するには、以下を実行します。

  • たとえば、%pre スクリプトの一部として nmcli ツールを使用して、ネットワークを設定します。
  • インストーラーの起動オプションを使用して、%pre スクリプト用にネットワークを設定します。

その結果、%pre セクションのタスクにネットワークを使用できるようになり、キックスタートインストールプロセスが完了します。

Bugzilla:2173992

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 を手動で有効にすることができます。

Jira:RHEL-4649

ドライバーディスクメニューがコンソールでユーザー入力を表示できない

ドライバーディスクを使用して、カーネルコマンドラインで inst.dd オプションを使用して RHEL インストールを開始すると、コンソールにユーザー入力が表示されません。そのため、アプリケーションがユーザー入力に応答せず、応答を停止しているように見えますが、出力は表示されます。これはユーザーにはわかりにくい動作です。ただし、この動作は機能に影響を与えず、Enter を押すとユーザー入力が登録されます。

回避策として、予想される結果を確認するには、コンソールでユーザー入力が存在しないことを無視し、入力の追加が終了したら Enter を押します。

Jira:RHEL-4737

%packages セクションに systemd サービスファイルを含むパッケージがないため、キックスタートインストールが失敗する

キックスタートファイルで services --enabled=… ディレクティブを使用して systemd サービスを有効にし、指定したサービスファイルを含むパッケージが %packages セクションに含まれていない場合、RHEL のインストールプロセスは次のエラーで失敗します。

Error enabling service <name_of_the_service>

この問題を回避するには、キックスタートの %packages セクションに、サービスファイルを含む各パッケージを追加します。こうすることで、インストール中に期待されるサービスが有効になり、RHEL のインストールが完了します。

Jira:RHEL-9633[1]

署名されたコンテナーから ISO を構築できません

GPG または単純な署名付きコンテナーから ISO ディスクイメージをビルドしようとすると、次のようなエラーが発生します。

manifest - failed
Failed
Error: cannot run osbuild: running osbuild failed: exit status 1
2024/04/23 10:56:48 error: cannot run osbuild: running osbuild failed: exit status 1

これは、システムがイメージソース署名を取得できないために発生します。この問題を回避するには、コンテナーイメージから署名を削除するか、派生コンテナーイメージを構築します。たとえば、署名を削除するには、次のコマンドを実行します。

 $ sudo skopeo copy --remove-signatures containers-storage:registry.redhat.io/rhel9-beta/rhel-bootc:9.4 containers-storage:registry.redhat.io/rhel9-beta/rhel-bootc:9.4
$ sudo podman run \
       --rm \
       -it \
       --privileged \
       --pull=newer \
       --security-opt label=type:unconfined_t \
       -v /var/lib/containers/storage:/var/lib/containers/storage \
       -v ~/images/iso:/output \
       quay.io/centos-bootc/bootc-image-builder \
       --type iso --local \
       registry.redhat.io/rhel9-beta/rhel-bootc:9.4

派生コンテナーイメージを構築し、それに単純な GPG 署名を追加しないようにするには、コンテナーイメージの署名 の製品ドキュメントを参照してください。

Jira:RHEL-34807

bootc-image-builder はプライベートレジストリーからのイメージの構築をサポートしていません

現在、bootc-image-builder を使用してプライベートレジストリーから取得されるベースディスクイメージを構築することはできません。この問題を回避するには、プライベートレジストリーをローカルホストにコピーし、次の引数を使用してイメージをビルドします。

  • --local
  • localhost/<image name>:tag as 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>

Jira:RHELDOCS-18720[1]

レスキューモードでの SELinux の自動再ラベル付けにより、再起動ループが発生する可能性がある

rescue モードでファイルシステムにアクセスすると、次回の起動時に SELinux によってファイルシステムの自動再ラベル付けがトリガーされ、これは SELinux が permissive モードで実行されるまで継続されます。その結果、システムは /.autorelabel ファイルを削除できないため、rescue モードを終了した後に再起動の無限ループに陥る可能性があります。

回避策として、次回の起動時にカーネルコマンドラインに enforcing=0 を追加して、permissive モードに切り替えます。システムは予防措置として、rescue モードでファイルシステムにアクセスする際に、この問題が発生する可能性を知らせる警告メッセージを表示します。

Jira:RHEL-14005

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.