6.7. 既知の問題
このパートでは Red Hat Enterprise Linux 8 の既知の問題を説明します。
6.7.1. インストーラーおよびイメージの作成
キックスタートコマンドの auth
および authconfig
で AppStream リポジトリーが必要になる
インストール中に、キックスタートコマンドの auth
および authconfig
で authselect-compat
パッケージが必要になります。auth
または authconfig
を使用したときに、このパッケージがないとインストールに失敗します。ただし、設計上、authselect-compat
パッケージは AppStream リポジトリーでのみ使用可能です。
この問題を回避するには、BaseOS リポジトリーおよび AppStream リポジトリーがインストーラーで利用できることを確認するか、インストール中にキックスタートコマンドの authselect
コマンドを使用します。
(BZ#1640697)
reboot --kexec
コマンドおよび inst.kexec
コマンドが、予測可能なシステム状態を提供しない
キックスタートコマンド reboot --kexec
またはカーネル起動パラメーター inst.kexec
で RHEL インストールを実行しても、システムの状態が完全な再起動と同じになるわけではありません。これにより、システムを再起動せずにインストール済みのシステムに切り替えると、予期しない結果が発生することがあります。
kexec
機能は非推奨になり、Red Hat Enterprise Linux の今後のリリースで削除されることに注意してください。
(BZ#1697896)
Anaconda インストールに、最小リソース設定要件の低い制限が含まれています。
Anaconda は最小限のリソース設定を必要とするシステムでインストールを開始し、インストールを成功させるのに必要なリソースに関する以前のメッセージ警告を提供しません。その結果、インストールが失敗し、出力エラーでデバッグや復元の可能性を明確に示すメッセージが提供されない場合があります。この問題を回避するには、システムに、インストールに必要な最小リソース設定 (PPC64 (LE) の場合は 2GB メモリー、x86_64 の場合は 1GB) があることを確認します。これにより、インストールを成功できます。
(BZ#1696609)
reboot --kexec
コマンドを使用するとインストールが失敗します。
reboot --kexec
コマンドを含むキックスタートファイルを使用すると、RHEL 8 のインストールに失敗します。この問題を回避するには、キックスタートファイルで reboot --kexec
の代わりに reboot
コマンドを使用します。
インストーラーにおける s390x のセキュアなシステム起動のサポート
RHEL 8.1 は、セキュアブートの使用を強制する IBM Z 環境で使用するためにブートディスクの準備をサポートします。インストール時に使用されるサーバーおよびハイパーバイザーの機能により、そのオンディスクフォーマットにセキュアなブートサポートが含まれるかどうかを判断します。インストール時にオンディスク形式に影響を与える方法はありません。
したがって、セキュアブートに対応している環境で RHEL 8.1 をインストールすると、セキュアブートサポートのない環境に移行すると、一部のフェイルオーバーシナリオで起動できても、システムを起動することはできません。
この問題を回避するには、オンディスクブートフォーマットを制御する zipl
ツールを設定する必要があります。zipl
を実行する環境がセキュアブートをサポートしている場合でも、以前のオンディスクフォーマットを書き込むように zipl を設定できます。RHEL 8.1 のインストールが完了したら、root ユーザーで以下の手動の手順を実行します。
-
設定ファイル
/etc/zipl.conf
を編集します。 "secure=0" を含む行をセクションラベル "defaultboot" に追加します。
Example contents of the `zipl.conf` file after the change:
[defaultboot] defaultauto prompt=1 timeout=5 target=/boot secure=0
-
パラメーターなしで
zipl
ツールを実行します。
これらの手順を実行すると、RHEL 8.1 ブートディスクのオンディスク形式に、セキュアブートサポートが含まれなくなります。その結果、セキュアブートサポートが欠けている環境でもインストールを起動できます。
(BZ#1659400)
SSH から RHEL 8 初期セットアップを実行できません。
現在、SSH を使用してシステムにログインする際に、RHEL 8 の初期セットアップインターフェイスは表示されません。これにより、SSH を介して管理される RHEL 8 マシンの初期設定を実行できません。この問題を回避するには、メインのシステムコンソール (ttyS0) で初期設定を行ってから、SSH を使用してログインします。
(BZ#1676439)
secure=
起動オプションのデフォルト値は auto に設定されていません。
現在、secure=
起動オプションのデフォルト値は auto に設定されていません。このため、現在のデフォルトが無効であるため、セキュアなブート機能は利用できません。この問題を回避するには、/etc/zipl.conf
ファイルの [defaultboot]
セクションに secure=auto
を手動で設定します。その結果、セキュアなブート機能が利用できるようになります。詳細は、zipl.conf
の man ページを参照してください。
(BZ#1750326)
Binary DVD.iso
ファイルの内容をパーティションにコピーしても、.treeinfo
ファイルおよび .discinfo
ファイルがコピーされません。
ローカルインストールで、RHEL 8 Binary DVD.iso イメージファイルの内容をパーティションにコピーする際に、cp <path>/\* <mounted partition>/dir
コマンドの *
で、.treeinfo
ファイルおよび .discinfo
ファイルがコピーされません。インストールを成功させるには、このファイルが必要です。これにより、BaseOS リポジトリーおよび AppStream のリポジトリーが読み込まれず、anaconda.log
ファイルのデバッグ関連のログメッセージでしか問題を確認できません。
この問題を回避するには、不足している .treeinfo
ファイルおよび .discinfo
ファイルをパーティションにコピーします。
(BZ#1687747)
Kickstart インストールでは、自己署名 HTTPS サーバーを使用できません。
現在では、インストールソースが Kickstart ファイルで指定され、--noverifyssl
オプションが指定されると、インストーラーは自己署名の https サーバーからのインストールに失敗します。
url --url=https://SERVER/PATH --noverifyssl
この問題を回避するには、Kickstart インストールの開始時に、inst.noverifyssl
パラメーターをカーネルコマンドラインに追加します。
以下に例を示します。
inst.ks=<URL> inst.noverifyssl
(BZ#1745064)
6.7.2. ソフトウェア管理
yum repolist
が、skip_if_unavailable=false で利用できないリポジトリーで終了します。
リポジトリー設定オプション skip_if_unavailable
はデフォルトで以下のように設定されます。
skip_if_unavailable=false
この設定により、エラーと終了ステータス 1 が付いた最初の利用できないリポジトリーで yum repolist
コマンドを強制的に終了します。したがって、yum repolist
は、利用可能なリポジトリーのリスト表示を続行しません。
各リポジトリーの *.repo
ファイルでこの設定をオーバーライドすることができることに注意してください。
ただし、デフォルトの設定を維持する場合は、以下のオプションを付けて yum repolist
を使用して問題を回避することができます。
--setopt=*.skip_if_unavailable=True
(BZ#1697472)
6.7.3. サブスクリプションの管理
syspurpose addons
は subscription-manager attach --auto
出力に影響しません。
Red Hat Enterprise Linux 8 では、syspurpose
コマンドラインツールの 4 つの属性 (role
、usage
、service_level_agreement
、および addons
) が追加されました。現在、role
、usage
、および service_level_agreement
のみが、subscription-manager attach --auto
コマンドの実行の出力に影響します。addons
引数に値を設定しても、自動登録されたサブスクリプションには影響がありません。
(BZ#1687900)
6.7.4. シェルおよびコマンドラインツール
Wayland
プロトコルを使用するアプリケーションは、リモートのディスプレイサーバーに転送できません。
Red Hat Enterprise Linux 8.1 では、ほとんどのアプリケーションは、X11 プロトコルの代わりに、デフォルトで Wayland プロトコルを使用します。したがって、ssh サーバーは、Wayland プロトコルを使用するアプリケーションを転送できませんが、X11 プロトコルを使用するアプリケーションをリモートディスプレイサーバーに転送することは可能です。
この問題を回避するには、アプリケーションを起動する前に環境変数 gdk_BACKEND=x11
を設定します。その結果、アプリケーションはリモートディスプレイサーバーへ転送できます。
systemd-resolved.service
がシステム起動時の起動に失敗します。
systemd-resolved
サービスが起動時に起動できない場合があります。この場合は、以下のコマンドを実行して、システムの起動完了後に手動でサービスを再起動します。
# systemctl start systemd-resolved
ただし、システムの起動時に systemd-resolved
が失敗しても、その他のサービスは影響を受けません。
(BZ#1640802)
6.7.5. インフラストラクチャーサービス
dnsmasq での DNSSEC のサポート
dnsmasq
パッケージには、root サーバーから受け取ったホスト名情報を確認するための Domain Name System Security Extensions (DNSSEC) サポートが導入されました。
dnsmasq の DNSSEC 検証は、FIPS 140-2 に準拠していないことに注意してください。連邦情報処理標準 (FIPS) システム上の dnsmasq では DNSSEC を有効化せず、ローカルホスト上のフォワーダーとして適切なリゾルバーを使用します。
(BZ#1549507)
6.7.6. Security
redhat-support-tool
が FUTURE
暗号化ポリシーを使用すると機能しない
カスタマーポータル API の証明書が使用する暗号化キーは FUTURE
のシステム全体の暗号化ポリシーが定義する要件を満たさないので、現時点で redhat-support-tool
ユーティリティーは、このポリシーレベルでは機能しません。この問題を回避するには、カスタマーポータル API への接続中に DEFAULT
暗号化ポリシーを使用します。
/etc/selinux/config
の SELINUX=disabled
が正常に動作しません。
/etc/selinux/config
で SELINUX=disabled
オプションを使用して SELinux を無効にすると、カーネルが SELinux を有効にして起動し、その後のブートプロセスで無効化モードに切り替わります。これにより、メモリーリークや競合状態が発生し、その結果、カーネルパニックが発生する可能性があります。この問題を回避するには、SELinux を完全に無効にする必要がある場合に SELinux の使用 の システムの起動時に SELinux モードの変更 で説明されているように、selinux=0
パラメーターをカーネルコマンドラインに追加して SELinux を無効にすることが推奨されます。
(JIRA:RHELPLAN-34199)
libselinux-python
は、そのモジュールからのみ利用可能
libselinux-python
パッケージには、SELinux アプリケーション開発用の Python 2 バインディングのみが含まれ、後方互換性に使用されます。このため、libselinux-python
コマンドを使用して、デフォルトの RHEL 8 リポジトリーで dnf install libselinux-python
コマンドが利用できなくなりました。
この問題を回避するには、libselinux-python
モジュールおよび python27
モジュールの両方を有効にし、以下のコマンドで libselinux-python
パッケージとその依存関係をインストールします。
# dnf module enable libselinux-python # dnf install libselinux-python
または、1 つのコマンドでインストールプロファイルを使用して libselinux-python
をインストールします。
# dnf module install libselinux-python:2.8/common
これにより、各モジュールを使用して libselinux-python
をインストールできます。
(BZ#1666328)
udica
は、--env container=podman
で開始したときにのみ UBI 8 コンテナーを処理します。
Red Hat Universal Base Image 8 (UBI 8) コンテナーは、podman
の値ではなく、コンテナー
環境変数を oci
値に設定します。これにより、udica
ツールがコンテナー JavaScript Object Notation (JSON) ファイルを分析しなくなります。
この問題を回避するには、--env container=podman
パラメーターを指定して、podman
コマンドで UBI 8 コンテナーを起動します。そのため、udica
は、上記の回避策を使用している場合に限り、UBI 8 コンテナーの SELinux ポリシーを生成することができます。
rpm-plugin-selinux
パッケージを削除すると、システムからすべての selinux-policy
パッケージが削除されます。
rpm-plugin-selinux
パッケージを削除すると、マシン上で SELinux が無効になります。また、システムからすべての selinux-policy
パッケージも削除されます。rpm-plugin-selinux
パッケージを繰り返しインストールしてから、selinux-policy-targeted
ポリシーが以前に存在していても、selinux-policy-minimum
SELinux ポリシーをインストールします。ただし、繰り返しインストールしても、ポリシーの変更のために SELinux 設定ファイルが更新されることはありません。このため、rpm-plugin-selinux
パッケージを再インストールしても、SELinux が無効になります。
この問題を回避するには、以下を実行します。
-
umount /sys/fs/selinux/
コマンドを実行します。 -
足りない
selinux-policy-targeted
パッケージを手動でインストールします。 -
ポリシーが
SELINUX=enforcing
と同等になるように/etc/selinux/config
ファイルを編集します。 -
コマンド
load_policy -i
を実行します。
これにより、SELinux が有効になり、以前と同じポリシーが実行されている状態になります。
(BZ#1641631)
SELinux により、systemd-journal-gatewayd corosync
が、corosync
によって作成される共有メモリーファイル上で newfstatat()
を呼び出さなくなります。
SELinux ポリシーには、systemd-journal-gatewayd
が corosync
サービスによって作成されるファイルにアクセスできるルールが含まれません。その結果、SELinux は、systemd-journal-gatewayd
による、corosync
で作成された共有メモリーファイルの newfstatat()
関数を呼び出しを拒否します。
この問題を回避するには、このシナリオを実現する許可ルールでローカルポリシーモジュールを作成します。SELinux ポリシーの allow
および dontaudit ルールの生成の詳細は、man ページの audit2allow(1) を参照してください。以前の回避策により、systemd-journal-gatewayd
は、Enforcing モードで SELinux により corosync
で作成した共有メモリーファイルの関数を呼び出すことができます。
(BZ#1746398)
デフォルトのロギング設定がパフォーマンスに与える悪影響。
デフォルトのログ環境設定は、メモリーを 4 GB 以上使用する可能性があり、rsyslog
で systemd-journald
を実行している場合は、速度制限値の調整が複雑になります。
詳細は、ナレッジベースの記事 Negative effects of the RHEL default logging setup on performance and their mitigations を参照してください。
(JIRA:RHELPLAN-10431)
config.enabled
による rsyslog
出力の Parameter not known
エラー。
rsyslog
の出力では、config.enabled
ディレクティブを使用すると、設定処理エラーで予期しないバグが発生します。これにより、include()
ステートメントを除き、config.enabled
ディレクティブを使用すると、parameter not known
エラーが表示されます。
この問題を回避するには、config.enabled=on
を設定するか、include()
ステートメントを使用します。
(BZ#1659383)
特定の rsyslog
優先度の文字列が正常に動作しません。
imtcp
に GnuTLS 優先度文字列を設定して、完成していない暗号化をきめ細かく制御できるようになりました。したがって、rsyslog
では、以下の優先文字列が正常に動作しません。
NONE:+VERS-ALL:-VERS-TLS1.3:+MAC-ALL:+DHE-RSA:+AES-256-GCM:+SIGN-RSA-SHA384:+COMP-ALL:+GROUP-ALL
この問題を回避するには、正しく機能する優先度文字列のみを使用します。
NONE:+VERS-ALL:-VERS-TLS1.3:+MAC-ALL:+ECDHE-RSA:+AES-128-CBC:+SIGN-RSA-SHA1:+COMP-ALL:+GROUP-ALL
したがって、現在の設定は、正しく機能する文字列に限定する必要があります。
SHA-1 署名を使用するサーバーへの接続が GnuTLS で動作しません。
証明書の SHA-1 署名は、GnuTLS セキュアな通信ライブラリーにより、セキュアでないものとして拒否されます。したがって、TLS のバックエンドとして GnuTLS を使用するアプリケーションは、このような証明書を提供するピアへの TLS 接続を確立することができません。この動作は、その他のシステム暗号化ライブラリーと一貫性がありません。この問題を回避するには、サーバーをアップグレードして、SHA-256 または強力なハッシュを使用して署名した証明書を使用するか、LEGACY ポリシーに切り替えます。
(BZ#1628553)
TLS 1.3 は、FIPS モードの NSS で動作しません。
TLS 1.3 は、FIPS モードで動作しているシステムでは対応していません。その結果、相互運用性に TLS 1.3 を必要とする接続が、FIPS モードで動作しているシステムで機能しません。
その接続を有効にするには、システムの FIPS モードを無効にするか、ピアで TLS 1.2 のサポートを有効にします。
OpenSSL
が、生の RSA または RSA-PSS の署名に対応していない PKCS #11 トークンを誤って処理します。
OpenSSL
ライブラリーは、PKCS #11 トークンの鍵関連の機能を検出しません。したがって、生の RSA または RSA-PSS の署名に対応しないトークンで署名が作成されると、TLS 接続の確立に失敗します。
この問題を回避するには、/etc/pki/tls/openssl.cnf
ファイルの crypto_policy
セクションの末尾にある .include
行の後に、以下の行を追加します。
SignatureAlgorithms = RSA+SHA256:RSA+SHA512:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA512:ECDSA+SHA384 MaxProtocol = TLSv1.2
これにより、このシナリオで TLS 接続を確立できます。
OpenSSL TLS
ライブラリーは、PKCS#11
トークンが、生の RSA
署名または RSA-PSS
署名の作成に対応しているかどうかを検出しません。
TLS-1.3
プロトコルでは、RSA-PSS
署名の対応が必要です。PKCS#11
トークンが、生の RSA
署名または RSA-PSS
署名に対応していない場合、OpenSSL
TLS
ライブラリーを使用するサーバーアプリケーションは、PKCS#11
トークンが保持していると、RSA
鍵を使用した作業に失敗します。これにより、TLS
通信が失敗します。
この問題を回避するには、利用可能な最大の TLS
プロトコルバージョンとして TLS-1.2
バージョンを使用するように、サーバーまたはクライアントを設定します。
openSSL は、TLS 1.3 の CertificateRequest
メッセージ に、不正な status_request
拡張を生成します。
OpenSSL サーバーは、status_request
拡張とクライアント証明書ベースの認証サポートが有効な場合に、CertificateRequest
メッセージに正しくない status_request
拡張を送信します。この場合、OpenSSL は RFC 8446
プロトコルに準拠する実装と同時に動作しません。その結果、CertificateRequest メッセージの拡張を適切に検証するクライアントは OpenSSL サーバーとの接続を中止します。この問題を回避するには、接続のいずれかで TLS 1.3 プロトコルのサポートを無効にするか、OpenSSL サーバーの status_request
のサポートを無効にします。これにより、サーバーが不正なメッセージを送信しなくなります。
ssh-keyscan
が、FIPS モードでサーバーの RSA 鍵を取得できません。
FIPS モードで RSA 署名の SHA-1
アルゴリズムが無効になっています。これにより、ssh-keyscan
ユーティリティーがそのモードで稼働しているサーバーの RSA 鍵を取得できなくなります。
この問題を回避するには、代わりに ECDSA 鍵を使用するか、サーバーの /etc/ssh/ssh_host_rsa_key.pub
ファイルから鍵をローカルに取得します。
Audit ルールの scap-security-guide
PCI-DSS 修復が適切に動作しません。
scap-security-guide
パッケージには、修正の組み合わせと、以下のいずれかのシナリオで生じるチェックが含まれます。
- 監査ルールの誤った修正
- 渡されたルールが失敗とマークされた誤検出を含むスキャン評価
これにより、RHEL 8.1 インストールプロセス時に、インストール済みシステムのスキャンが、失敗またはエラーとして Audit ルールを報告します。
この問題を回避するには、ナレッジベースの記事 RHEL-8.1 workaround for remediating and scanning with the scap-security-guide PCI-DSS profile の手順に従ってください。
SSG における完全依存ルールの特定のセットが失敗する可能性があります。
ルールとその依存関係の順序付けを定義しないため、ベンチマークの SCAP Security Guide
(SSG) ルールの修正が失敗する可能性があります。たとえば、特定の順番で複数のルールを実行する必要がある場合、あるルールがコンポーネントをインストールし、別のルールが同じコンポーネントを設定した場合すると、それらは正しくない順序で実行される可能性があり、修正によってエラーが報告されます。この問題を回避するには、修正を回実行して、番目の実行で依存ルールを修正します。
コンテナーのセキュリティーおよびコンプライアンススキャンを行うユーティリティーが利用できません。
Red Hat Enterprise Linux 7 では、Atomic テクノロジーに基づいた Docker コンテナーのスキャンに、oscap-docker
ユーティリティーを使用できました。Red Hat Enterprise Linux 8 では、Docker 関連、および Atomic 関連の OpenSCAP コマンドが利用できません。
この問題に対処するには、カスタマーポータルの記事 Using OpenSCAP for scanning containers in RHEL 8 を参照してください。したがって、現在、RHEL 8 のコンテナーのセキュリティーおよびコンプライアンススキャンには、未対応の方法と制限のある方法のみを使用できます。
(BZ#1642373)
OpenSCAP
が、仮想マシンおよびコンテナーのオフラインスキャンを提供しません。
OpenSCAP
のコードベースをリファクターリングすると、特定の RPM プローブがオフラインモードで仮想マシンおよびコンテナーのファイルシステムをスキャンするのに失敗していました。このため、以下のツールは、openscap-utils
パッケージである oscap-vm
および oscap-chroot
から削除されました。また、openscap-containers
パッケージも完全に削除されました。
(BZ#1618489)
OpenSCAP の rpmverifypackage
が正常に動作しません。
rpmverifypackage
プローブにより、システムコール chdir
および chroot
が 2 回呼び出されます。これにより、カスタムの OVAL (Open Vulnerability and Assessment Language) コンテンツを使用した OpenSCAP をスキャンする際にこのプルーブを使用していると、エラーが発生します。
この問題を回避するには、コンテンツで OVAL テスト rpmverifypackage_test
を使用しないようにするか、rpmverifypackage_test
が使用されていない scap-security-guide
パッケージのコンテンツのみを使用します。
(BZ#1646197)
SCAP Workbench が、カスタムプロファイルから結果ベースの修正を生成できない
SCAP Workbench ツールを使用してカスタムプロファイルから結果ベースの修正ロールを生成しようとすると、次のエラーが発生します。
Error generating remediation role .../remediation.sh: Exit code of oscap was 1: [output truncated]
この問題を回避するには、oscap
コマンドを、--tailoring-file
オプションとともに使用します。
(BZ#1640715)
OSCAP Anaconda Addon
がすべてのパッケージをテキストモードでインストールしません。
OSCAP Anaconda Addon
プラグインは、インストールがテキストモードで実行している場合、システムインストーラーによってインストールに選択されているパッケージのリストを変更することはできません。これにより、キックスタートを使用してセキュリティーポリシープロファイルが指定され、インストールがテキストモードで実行している場合に、インストール中にセキュリティーポリシーに必要な追加パッケージがインストールされません。
この問題を回避するには、グラフィカルモードでインストールを実行するか、キックスタートファイルの %packages
セクションにあるセキュリティーポリシーで、セキュリティーポリシープロファイルに必要なパッケージをすべて指定します。
これにより、セキュリティーポリシープロファイルで必要となるパッケージは、上記の回避策のいずれかを行わなければ RHEL インストールインストール時にインストールされません。また、インストール後のシステムは、指定のセキュリティーポリシープロファイルと互換性がありません。
oscap Anaconda Addon
がカスタムプロファイルを正しく処理しません。
OSCAP Anaconda Addon
プラグインは、個別のファイルでカスタマイズを使用したセキュリティープロファイルを適切に処理しません。これにより、対応する Kickstart セクションで適切に指定しても、RHEL グラフィカルインストールでカスタマイズしたプロファイルは利用できません。
この問題を回避するには、ナレッジベースの記事 Creating a single SCAP data stream from an original DS and a tailoring file を参照してください。この回避策により、RHEL グラフィカルインストールでカスタマイズした SCAP プロファイルを使用できます。
(BZ#1691305)
6.7.7. ネットワーク
arptables
の詳細出力のフォーマットが、RHEL 7 のユーティリティーのフォーマットに一致するようになりました。
RHEL 8 では、iptables-arptables
パッケージが arptables
ユーティリティーの代わりに nftables
を提供します。以前では、arptables
の詳細な出力は、コンマでのみカウンター値を区切っていました。一方、RHEL 7 の arptables
は、スペースとコンマの両方で出力を区切っていました。これにより、arptables -v -L
コマンドの出力を分析した RHEL 7 で作成されたスクリプトを使用した場合は、このスクリプトを調整する必要がありました。この非互換性が修正されました。これにより、RHEL 8.1 の arptables
が、スペースとコンマの両方でカウンター値を分けるようになりました。
(BZ#1676968)
nftables
が多次元の IP セットタイプに対応しません。
nftables
パケットフィルタリングフレームワークは、連結と区間を持つセット型に対応しません。これにより、hash:net,port
などの多次元 IP セットタイプを、nftables
と共に使用することができません。
この問題を回避するには、多次元 IP セットタイプが必要な場合に、iptables
フレームワークを ipset
ツールと共に使用してください。
(BZ#1593711)
GRO が無効になっていると IPsec オフロード中に IPsec ネットワークトラフィックが失敗します。
デバイスで汎用受信オフロード (GRO) が無効になっていると、IPSec オフロードは機能しません。IPsec オフロードがネットワークインターフェイスで設定され、GRO がそのデバイスで無効になっていると、IPsec ネットワークトラフィックに失敗します。
この問題を回避するには、デバイスで GRO を有効にしたままにします。
(BZ#1649647)
6.7.8. カーネル
i40iw モジュールがシステムの起動時に自動的に読み込まれない
多くの i40e NIC で iWarp に対応しておらず、i40iw モジュールがサスペンド/レジュームに完全に対応していないため、このモジュールがデフォルトで自動的に読み込まれず、サスペンド/レジューム正しく機能させることができません。この問題を回避するには、/lib/udev/rules.d/90-rdma-hw-modules.rules
ファイルを手動で編集して、i40iw の自動読み込みを有効にします。
また、同じマシンにある i40e デバイスに、別の RDMA デバイスがインストールされている場合に、i40e 以外の RDMA デバイスで、i40iw モジュールを含む、有効なすべての RDMA スタックモジュールを読み込む rdma サービスが起動します。
(BZ#1623712)
fadump
を使用すると、ネットワークインターフェイスの名前が kdump-<interface-name>
に変更されます。
ファームウェアアシストダンプ (fadump
) を使用して vmcore をキャプチャーし、SSH または NFS プロトコルでリモートマシンに保存する場合は、<interface-name>
がジェネリックであれば (*eth# や net#)、ネットワークインターフェイスは kdump- <interface-name>
に名前が変更されます。この問題は、初期 RAM ディスク (initrd
) の vmcore 取得スクリプトが、ネットワークインターフェイス名に接尾辞 kdump- を追加して、永続的な名前付けを保護するために発生します。同じ initrd
が通常の起動にも使用されるため、実稼働環境のカーネルのインターフェイス名も変更されます。
(BZ#1745507)
永続メモリーの量が多くなると、システムの起動プロセス時に遅延が発生します。
メモリーの初期化がシリアル化されるため、永続メモリーのサイズが大きいシステムは起動に時間がかかります。したがって、/etc/fstab
ファイルに永続メモリーのファイルシステムがあると、デバイスが利用できるようになるまで待つ際に、システムがタイムアウトする場合があります。この問題を回避するには、/etc/systemd/system.conf
ファイルの DefaultTimeoutStartSec
オプションを十分に大きな値に設定します。
(BZ#1666538)
KSM が、NUMA メモリーポリシーを無視することがあります。
merge_across_nodes=1
パラメーターで、カーネル共有メモリー (KSM) 機能を有効にすると、KSM は、mbind() 関数が設定したメモリーポリシーを無視し、一部のメモリーから、ポリシーに一致しない NUMA (Non-Uniform Memory Access) ノードにページをマージできない場合があります。
この問題を回避するには、KSM を無効にするか、QEMU で NUMA メモリーバインディングを使用する場合は merge_across_nodes
パラメーターを 0
に設定します。これにより、KVM 仮想マシンに設定した NUMA メモリーポリシーが期待どおりに機能します。
(BZ#1153521)
fadump
が有効な場合は、システムが起動時に緊急モードに切り替わります。
fadump
(kdump
) または dracut
squash モジュールが initramfs
スキームで有効化されると、システムが緊急モードに切り替わります。これは、systemd
マネージャーがマウント情報の取得とマウントする LV パーティションの設定に失敗するためです。この問題を回避するには、以下のカーネルコマンドラインパラメーター rd.lvm.lv=<vg>/<LV>
を追加し、失敗した LV パーティションを適切に検出してマウントします。これにより、上述のシナリオでシステムが正常に起動するようになります。
(BZ#1750278)
kdump カーネルコマンドライン で irqpoll
を使用すると vmcore 生成に失敗します。
AWS (Amazon Web Services) クラウドプラットフォームで実行している 64 ビット ARM アーキテクチャー上には nvme
ドライバーの既存の根本的な問題があります。この問題により、irqpoll
kdump コマンドライン引数が最初のカーネルにある場合、vmcore 生成は失敗します。したがって、カーネルクラッシュ後に vmcore が /var/crash/ ディレクトリーにダンプされません。この問題を回避するには、以下を実行します。
-
/etc/sysconfig/kdump ファイルの
KDUMP_COMMANDLINE_REMOVE
キーにirqpoll
を追加します。 -
systemctl restart kdump
コマンドを実行して、kdump
サービスを再起動します。
その結果、最初のカーネルが正常に起動し、カーネルクラッシュ時に vmcore がキャプチャーされることが予想されます。
(BZ#1654962)
RHEL 8 で、デバッグカーネルがクラッシュキャプチャー環境で起動に失敗します。
デバッグカーネルのメモリー要求の性質により、デバッグカーネルが使用中で、カーネルパニックが発生すると、問題が発生します。その結果、デバッグカーネルはキャプチャーカーネルとして起動できず、代わりにスタックトレースが生成されます。この問題を回避するには、クラッシュカーネルメモリーを適宜増やします。これにより、デバッグカーネルが、クラッシュキャプチャー環境で正常に起動します。
(BZ#1659609)
softirq
の変更により、負荷が大きい場合に localhost インターフェイスが UDP パケットをドロップできるようになります
Linux カーネルのソフトウェア割り込み (softirq
) 処理の変更を行い、サービス拒否 (DOS) の影響を軽減します。その結果、これにより、localhost インターフェイスが負荷が大きいときに localhost インターフェイスが UDP (User Datagram Protocol) パケットをドロップする状況が生じます。
この問題を回避するには、ネットワークデバイスのバックログバッファーのサイズを 6000: の値に増やします。
echo 6000 > /proc/sys/net/core/netdev_max_backlog
Red Hat テストでは、パケットロスを防ぐために十分な値でした。より負荷の高いシステムには、より大きなバックログ値が必要になる場合があります。バックログが増えると、ローカルホストインターフェイスのレイテンシーが増加する可能性があります。
その結果、バッファーを増やし、より多くのパケットを処理まで待機できるため、ローカルホストパケットをドロップする可能性を減らすことができます。
(BZ#1779337)
6.7.9. ハードウェアの有効化
HP NMI ウォッチドッグがクラッシュダンプを生成しない場合があります。
HP NMI ウォッチドッグの hpwdt
ドライバーは、マスク不可割り込み (NMI) が perfmon
ドライバーにより使用されたため、HPE ウォッチドッグタイマーが生成した NMI を要求できない場合があります。したがって、hpwdt
は、クラッシュダンプを生成するためにパニックを呼び出さない場合があります。
(BZ#1602962)
QL41000 カードで設定したテストシステムに RHEL 8.1 をインストールするとカーネルパニックが発生します。
QL41000
カードで設定したテストシステム上に RHEL 8.1 をインストールすると、システムは 000000000000003c
カードでカーネル NULL ポインターの逆参照を処理できません。これにより、カーネルパニックのエラーが発生します。この問題に対する回避策はありません。
(BZ#1743456)
cxgb4
ドライバーにより kdump カーネルでクラッシュします。
vmcore
ファイルに情報を保存しようとすると、kdump
カーネルがクラッシュします。そのため、cxgb4
ドライバーにより、kdump
カーネルが、後で分析するためにコアを保存できなくなります。この問題を回避するには、kdump カーネルコマンドラインに "novmcoredd" パラメーターを追加して、コアファイルを保存できるようにします。
(BZ#1708456)
6.7.10. ファイルシステムおよびストレージ
特定の SCSI ドライバーが過剰な量のメモリーを使用することがあります。
SCSI ドライバーの中には、RHEL 7 よりも大容量のメモリーを使用しているものがあります。ファイバーチャネルホストバスアダプター (HBA) での vPort 作成など、特定のケースでは、システム設定によってはメモリー使用量が過剰になる可能性があります。
メモリー使用量の増加は、ブロックレイヤーでメモリーの事前割り当てにより発生します。RHEL 8 の各 I/O リクエストに対して、マルチキューブロックデバイススケジューリング (BLK-MQ) とマルチキューの SCSI スタック (SCSI-MQ) の両方がメモリーを事前に割り当てているため、メモリー使用量が増えます。
(BZ#1698297)
UDS が再構築が終了するまで VDO は一時停止できません。
VDO (Virtual Data Optimizer) ボリュームが不完全なシステムのシャットダウン後に起動すると、Universal Deduplication Service (UDS) インデックスが再構築されます。UDS インデックスが再構築されても、dmsetup suspend
コマンドを使用して VDO ボリュームを一時停止しようとすると、suspend コマンドが応答しなくなることがあります。このコマンドは、再構築が完了した後にのみ終了します。
UDS インデックスが大きい VDO ボリュームでは、応答の遅延が明白になります。このため、再構築に時間がかかります。
NFS 4.0 パッチは、オープンの高ワークロードでパフォーマンスが低下する可能性があります。
以前、場合によっては NFS のオープン操作で、サーバー上のファイルが削除されたり、名前が変更されたりするという事実を見落とすというバグが修正されています。ただし、この修正により、多くのオープンな操作が必要とるするワークロードのパフォーマンスが遅くなる可能性があります。この問題を回避するには、NFS バージョン 4.1 以降を使用します。これは、多くの場合においてクライアントに委譲を付与するように改善されています。このため、クライアントがローカルに素早く安全にオープン操作を実行できます。
(BZ#1748451)
6.7.11. 動的プログラミング言語、Web サーバー、およびデータベースサーバー
nginx
がハードウェアセキュリティートークンからサーバー証明書をロードできません。
nginx
の Web サーバーは、PKCS#11 モジュールを利用してハードウェアセキュリティートークンから直接 TLS 秘密鍵を読み込むようになりました。ただし、現在では、PKCS#11 URI を使用してハードウェアのセキュリティートークンからサーバー証明書を読み込むことはできません。この問題を回避するには、ファイルシステム上にサーバー証明書を保存します。
php-opcache
が PHP 7.2 とともにインストールされると、PHP 7.2 で php-fpm
により、SELinux AVC 拒否が発生します。
php-opcache
パッケージがインストールされると、FastCGI Process Manager (php-fpm
) により SELinux AVC 拒否が生じます。この問題を回避するには、/etc/php.d/10-opcache.ini
ファイルのデフォルト設定を以下のように変更します。
opcache.huge_code_pages=0
この問題は、php: 7.3
ではなく、php:7.2
ストリームにのみ影響することに注意してください。
6.7.12. コンパイラーおよび開発ツール
ltrace
ツールが、関数呼び出しを報告しません。
すべての RHEL コンポーネントに適用されるバイナリー強化の改善により、ltrace
ツールが、RHEL コンポーネントからのバイナリーファイルの関数呼び出しを検出できなくなりました。これにより、ltrace
の出力では、このようなバイナリーファイルで使用されたときに検出される呼び出しが報告されなくなるため、空になります。現在利用できる回避策はありません。
ただし、ltrace
では、それぞれの強化フラグを使用せずに構築されたカスタムバイナリーファイルの呼び出しは報告されます。
(BZ#1618748)
6.7.13. ID 管理
GSSAPI 認証を使用する場合に、期限切れのアカウントを持つ AD ユーザーのログインが可能。
アカウントの期限が切れたかどうかを参照するために SSSD が使用する accountExpires
属性は、デフォルトでグローバルカタログにレプリケートされません。これにより、GSSAPI 認証を使用する場合に、期限切れのアカウントを持つユーザーはログインできます。この問題に対処するには、sssd.conf
ファイルで ad_enable_gc=False
を指定してグローバルカタログサポートを無効にすることができます。この設定では、GSSAPI 認証を使用する場合に、期限切れのアカウントを持つユーザーはアクセスが拒否されます。
SSSD は、このシナリオにおいて各 LDAP サーバーに個別に接続するため、接続数を増やすことができることに注意してください。
(BZ#1081046)
--agent-uid pkidbuser
オプションを指定して cert-fix
ユーティリティーを使用すると、証明書システムが破損します。
--agent-uid pkidbuser
オプションを指定して cert-fix
ユーティリティーを使用すると、証明書システムの LDAP 設定が破損します。したがって、証明書システムは不安定になり、システムの復元に手動の操作が必要になる可能性があります。
/etc/nsswitch.conf
を変更するには、手動によるシステムの再起動が必要です。
authselect select profile_id
コマンドの実行など、/etc/nsswitch.conf
ファイルを変更した場合は、関連するすべてのプロセスで、更新バージョンの /etc/nsswitch.conf
ファイルが使用されるように、システムを再起動する必要があります。システムを再起動できない場合は、システムを Active Directory (System Security Services Daemon
(SSSD) または winbind
) に追加するサービスを再起動します。
IdM で AD 信頼のサポートを有効にすると、必要な DNS レコードに関する情報が表示されません。
外部 DNS 管理を使用した Red Hat Enterprise Linux Identity Management (IdM) インストールで Active Directory (AD) 信頼のサポートを有効にすると、必要な DNS レコードに関する情報が表示されません。AD へのフォレストの信頼は、必要な DNS レコードが追加されるまで成功しません。この問題を回避するには、ipa dns-update-system-records --dry-run コマンドを実行して、IdM が必要とするすべての DNS レコードのリストを取得します。IdM ドメインの外部 DNS が必要な DNS レコードを定義すると、AD へのフォレスト信頼を確立できるようになります。
SSSD が、ローカルユーザーの LDAP グループメンバーシップを誤って返します。
SSSD (System Security Services Daemon) がローカルファイルのユーザーに対応している場合、ファイルプロバイダーには、他のドメインのグループメンバーシップが含まれません。これにより、ローカルユーザーが LDAP グループのメンバーである場合、id local_user
コマンドはユーザーの LDAP グループメンバーシップを返しません。この問題を回避するには、システムが /etc/nsswitch.conf
ファイルのユーザーのグループメンバーシップを調べるデータベースの順序を元に戻すか、sss files
を files sss
に置き換えるか、以下を追加して、暗黙的な files
ドメインを無効にします。
enable_files_domain=False
/etc/sssd/sssd.conf
ファイルの [sssd]
セクションに移動します。
これにより、id local_user
が、ローカルユーザーの正しい LDAP グループメンバーシップを返します。
RHEL 8 で、systemd-user
のデフォルトの PAM 設定が変更になり、SSSD の動作に影響を及ぼす可能性があります。
Red Hat Enterprise Linux 8 では、プラグ可能な認証モジュール (PAM) スタックが変更されました。たとえば、systemd
ユーザーセッションは、PAM サービス systemd-user
を使用して PAM 対話を開始するようになりました。このサービスは、PAM サービスの system-auth
を再帰的に追加します。ここには、pam_sss.so
インターフェイスが含まれる場合もあります。これは、SSSD アクセス制御が常に呼び出されることを意味します。
RHEL 8 システムのアクセス制御ルールを規定する場合は、変更に注意してください。たとえば、systemd-user
サービスを、許可されたサービスリストに追加できます。
IPA HBAC、AD GPO などの一部のアクセス制御メカニズムでは、systemd-user
サービスが、許可されたサービスリストにデフォルトで追加されているため、何もする必要はありません。
SSSD が同じ優先順位を持つ複数の証明書一致ルールを正しく処理しません。
指定した証明書が、優先順位が同じ複数の証明書の一致ルールに一致する場合、System Security Services Daemon (SSSD) は、いずれか一方のみを使用します。これを回避するには、|
(or) 演算子で連結した個々のルールのフィルターで設定される LDAP フィルターを持つ 1 つの証明書一致ルールを使用します。証明書一致ルールの例は、man ページの sss-certamp (5) を参照してください。
(BZ#1447945)
複数のドメインが定義されている場合は、プライベートグループを auto_private_group = hybrid で作成できません。
複数のドメインが定義され、最初のドメイン以外のドメインによってハイブリッドオプションが使用されると、プライベートグループは、auto_private_group = hybrid オプションでの作成に失敗します。暗黙的なファイルドメインが sssd.conf ファイルの AD または LDAP ドメインとともに定義され、MPG_hybrid としてマークされていない
場合、SSSD は uid=gid のユーザーに対してプライベートグループを作成し、この gid を持つグループは AD または LDAP に存在しません。
sssd_nss レスポンダーは、最初のドメインの auto_private_groups
オプションの値のみを確認します。これにより、RHEL 8 でデフォルトのセットアップを含む、複数のドメインが設定されているセットアップでは、auto_private_group
オプションを指定しても効果が得られません。
この問題を回避するには、sssd.conf
の sssd セクションで enable_files_domain = false
を設定します。その結果、enable_files_domain
オプションが false に設定されていると、sssd は、アクティブなドメインリストの開始に id_provider=files
とともにドメインを追加しないため、このバグは発生しません。
(BZ#1754871)
python-ply
は FIPS との互換性がありません。
python-ply
パッケージの YACC モジュールは、MD5 ハッシュアルゴリズムを使用して YACC 署名のフィンガープリントを生成します。ただし、FIPS モードは、セキュリティー以外のコンテキストでのみ許可される MD5 の使用をブロックします。そのため、python-ply は FIPS と互換性がありません。FIPS モードのシステムでは、ply.yacc()
への呼び出しに失敗し、次のエラーメッセージが表示されます。
"UnboundLocalError: local variable 'sig' referenced before assignment"
この問題は python-pycparser
および python-cffi
のいくつかのユースケースに影響します。この問題を回避するには、/usr/lib/python3.6/site-packages/ply/yacc.py
ファイルの 2966 行目を変更し、sig = md5()
を sig = md5(usedforsecurity=Fals)
に置き換えます。これにより、python-ply
を FIPS モードで使用できます。
6.7.14. デスクトップ
Wayland セッションの制限
Red Hat Enterprise Linux 8 では、GNOME 環境および GNOME Display Manager (GDM) のデフォルトのセッションタイプとして、以前の RHEL メジャーバージョンで使用されていた X11 セッションに代わり、Wayland が使用されます。
以下の機能は、Wayland の下では現在利用できないか、期待どおりに動作しません。
- Wayland では、マルチ GPU の設定が利用できません。
-
xrandr
などの X11 設定ユーティリティーは、ハンドリング、解像度、ローテーション、レイアウトのアプローチが異なるため、Wayland では動作しません。ディスプレイ機能は、GNOME 設定を使用して設定できます。 - 画面の録画とリモートデスクトップでは、アプリケーションが Wayland のポータル API をサポートする必要があります。特定のレガシーアプリケーションはポータル API をサポートしません。
- Wayland では、ポインターのアクセシビリティーは利用できません。
- クリップボードマネージャーは利用できません。
Wayland 上の GNOME Shell は、ほとんどのレガシー X11 アプリケーションで発行されたキーボードグラブを無視します。
/org/gnome/mutter/wayland/xwayland-grab-access-rules
GSettings キーを使用して、X11 アプリケーションがキーボードグラブを発行するようにできます。デフォルトでは、Wayland 上の GNOME Shell により、以下のアプリケーションがキーボードグラブを発行できます。- GNOME Boxes
- Vinagre
- Xephyr
-
virt-manager
、virt-viewer
、およびremote-viewer
-
vncviewer
- ゲスト仮想マシン (VM) 内のWayland には安定性とパフォーマンスの問題があります。RHEL は、仮想マシンで実行している場合に X11 セッションに自動的にフォールバックします。
X11 GNOME セッションを使用していた RHEL 7 システムから RHEL 8 にアップグレードすると、システムでは引き続き X11 が使用されます。また、次のグラフィックドライバーが使用されている場合は、自動的に X11 にフォールバックします。
- プロプライエタリー NVIDIA ドライバー
-
cirrus
ドライバー -
mga
ドライバー -
aspeed
ドライバー
Wayland の使用は手動で無効にできます。
-
GDM の Wayland を無効にするには、
/etc/gdm/custom.conf
ファイルにWaylandEnable=false
オプションを設定します。 - GNOME セッションで Wayland を無効にするには、ログイン名を入力してから、ログイン画面の歯車メニューでレガシーの X11 オプションを選択します。
Wayland の詳細は https://wayland.freedesktop.org/ を参照してください。
ドラッグアンドドロップが、デスクトップとアプリケーション間で機能しません。
gnome-shell-extensions
パッケージのバグにより、ドラッグアンドドロップ機能は現在、デスクトップとアプリケーションの間では機能しません。この機能のサポートは、今後のリリースで追加される予定です。
ソフトウェアリポジトリーからの flatpak
リポジトリーの無効化ができません。
現時点で、GNOME Software ユーティリティーの Software Repositories ツールで flatpak
リポジトリーを無効化または削除することはできません。
Generation 2 の RHEL 8 仮想マシンが Hyper-V Server 2016 ホストで起動できない場合があります。
Microsoft Hyper-V Server 2016 ホストで実行している仮想マシンで RHEL 8 をゲストオペレーティングシステムとして使用すると、仮想マシンが起動しなくなり、GRUB ブートメニューに戻る場合があります。さらに、以下のエラーが Hyper-V イベントログに記録されます。
The guest operating system reported that it failed with the following error code: 0x1E
このエラーは、Hyper-V ホストの UEFI ファームウェアバグが原因で発生します。この問題を回避するには、Hyper-V Server 2019 をホストとして使用します。
(BZ#1583445)
GNOME Shell on Wayland は、ソフトウェアレンダラーを使用すると、動作が遅くなっていました。
ソフトウェアレンダラーを使用すると、GNOME Shell を Wayland コンポジター (GNOME Shell on Wayland) として使用しても、画面のレンダリングにキャッシュ可能なフレームバッファーを使用しません。これにより、GNOME Shell on Wayland が遅くなります。この問題を回避するには、GNOME Display Manager (GDM) ログイン画面に移動し、代わりに X11 プロトコルを使用するセッションに切り替えます。そのため、キャッシュ可能なメモリーを使用する Xorg ディスプレイサーバーが使用され、上記の状況の GNOME Shell on Xorg は、GNOME Shell on Wayland に比べて速く動作します。
(BZ#1737553)
システムクラッシュにより、fadump 設定が失われることがあります。
この問題は、ファームウェア支援ダンプ (fadump) が有効になっているシステムで確認されています。また、ブートパーティションは XFS などのジャーナリングファイルシステムにあります。システムクラッシュにより、ダンプサポートが有効でない古い initrd
をブートローダーがロードする可能性があります。したがって、復元後、システムは vmcore
ファイルをキャプチャーせず、fadump 設定が失われる可能性があります。
この問題を回避するには、以下を実行します。
/boot
が別のパーティションの場合は、以下を実行します。- kdump サービスを再起動します。
root ユーザーで以下のコマンドを実行するか、CAP_SYS_ADMIN 権限を持つユーザーアカウントを使用します。
# fsfreeze -f # fsfreeze -u
-
/boot
が別のパーティションではない場合は、システムを再起動します。
(BZ#1723501)
ldap_id_use_start_tls
オプションのデフォルト値を使用する場合の潜在的なリスク
ID ルックアップに TLS を使用せずに ldap://
を使用すると、攻撃ベクトルのリスクが生じる可能性があります。特に、中間者 (MITM) 攻撃は、攻撃者が、たとえば、LDAP 検索で返されたオブジェクトの UID または GID を変更することによってユーザーになりすますことを可能にする可能性があります。
現在、TLS を強制する SSSD 設定オプション ldap_id_use_start_tls
は、デフォルトで false
に設定されています。セットアップが信頼できる環境で動作していることを確認し、id_provider = ldap
に暗号化されていない通信を使用しても安全かどうかを判断してください。注記: id_provider = ad
および id_provider = ipa
は、SASL および GSSAPI によって保護された暗号化接続を使用するため、影響を受けません。
暗号化されていない通信を使用することが安全ではない場合は、/etc/sssd/sssd.conf
ファイルで ldap_id_use_start_tls
オプションを true
に設定して TLS を強制します。デフォルトの動作は、RHEL の将来のリリースで変更される予定です。
(JIRA:RHELPLAN-155168)
6.7.15. グラフィックインフラストラクチャー
radeon
がハードウェアを適切なハードウェアリセットに失敗します。
現在、radeon
カーネルドライバーは、kexec コンテキストでハードウェアを正しくリセットしません。代わりに radeon
がフェイルオーバーします。これにより、kdump サービスの残りの部分が失敗します。
この問題を回避するには、/etc/kdump.conf
ファイルに以下の行を追加して、kdump で radeon
をブラックリストに指定します。
dracut_args --omit-drivers "radeon" force_rebuild 1
マシンと kdump を再起動します。kdumpの起動後、設定ファイルから force_rebuild 1
行が削除される可能性があります。
このシナリオでは、kdump 中にグラフィックは利用できませんが、kdump は正常に動作します。
(BZ#1694705)
6.7.16. Web コンソール
非特権ユーザーがサブスクリプションページにアクセスできます。
管理者以外のユーザーが Web コンソールの サブスクリプションページ に移動すると、Web コンソールでは、Cockpit had an unexpected internal error(Cockpit に予期しない内部エラーが発生しました) という一般的なエラーメッセージが表示されます。
この問題を回避するには、権限のあるユーザーで Web コンソールにサインインし、Reuse my password for privileged tasks チェックボックスをチェックします。
6.7.17. 仮想化
cloud-init
を使用した Microsoft Azure での仮想マシンのプロビジョニングに失敗します。
現在、cloud-init
ユーティリティーを使用して、Microsoft Azure プラットフォームで RHEL 8 仮想マシンをプロビジョニングすることができません。この問題を回避するには、以下のいずれかの方法を使用します。
-
cloud-init
の代わりにWALinuxAgent
パッケージを使用して、Microsoft Azure に仮想マシンをプロビジョニングします。 以下の設定を
/etc/NetworkManager/NetworkManager.conf
ファイルの[main]
セクションに追加します。[main] dhcp=dhclient
(BZ#1641190)
一部の場合において RHEL 7 ホストの RHEL 8 仮想マシンは、1920x1200 を超える解像度で表示できません。
現在、RHEL 7 ホストシステムで RHEL 8 仮想マシンを実行している場合は、kiosk モードでアプリケーションを実行するなど、仮想マシンのグラフィカル出力を表示する方法によっては、1920x1200 を超える解像度を表示することはできません。そのため、ホストハードウェアがより高い解像度に対応している場合でも、この方法での仮想マシンを表示解像度は最大 1920x1200 のみとなります。
(BZ#1635295)
Windows Server 2019 ホストの RHEL 8 仮想マシンで GUI ディスプレイのパフォーマンスが下がります。
Windows Server 2019 ホストのグラフィカルモードで RHEL 8 をゲストオペレーティングシステムとして使用すると、GUI ディスプレイのパフォーマンスが下がり、ゲストのコンソール出力に現在必要なよりも長い時間がかかります。
これは、Windows 2019 ホストで既知の問題で、Microsoft が修正を保留しています。この問題を回避するには、SSH を使用してゲストに接続するか、ホストとして Windows Server 2016 を使用します。
(BZ#1706541)
RHEL 仮想マシンのインストールが失敗することがあります。
特定の状況下では、virt-install
ユーティリティーを使用して作成した RHEL 7 および RHEL 8 仮想マシンが、--location
オプションを指定すると起動に失敗します。
この問題を回避するには、代わりに --extra-args
オプションを指定して、ネットワークが到達可能なインストールツリーを指定します。以下にその例を示します。
--extra-args="inst.repo=https://some/url/tree/path"
これにより、RHEL インストーラーはインストールファイルを正しく検出できるようになります。
(BZ#1677019)
QXL では、Wayland を使用する仮想マシンの複数のモニターを表示できません。
remote-viewer
ユーティリティーを使用して、Wayland ディスプレイサーバーを使用している仮想マシンのモニターを複数表示すると、仮想マシンが応答しなくなり、Waiting for display というステータスメッセージが永久に表示されます。
この問題を回避するには、Wayland を使用する仮想マシンの GPU デバイスとして qxl
の代わりに virtio-gpu
を使用します。
(BZ#1642887)
virsh iface-\*
コマンドが一貫して動作しません。
現在、virsh iface-*
コマンド (virsh iface-start
、virsh iface-destroy
など) は、設定の依存関係が原因で頻繁に失敗します。したがって、ホストネットワーク接続の設定および管理には virsh iface-\*
コマンドを使用しないことが推奨されます。代わりに、NetworkManager プログラムとその関連管理アプリケーションを使用します。
(BZ#1664592)
cloud-init
を使用して ESXi 仮想マシンをカスタマイズし、VM を再起動すると、IP 設定が失われ、仮想マシンの起動が非常に遅くなります。
現在、cloud-init
サービスを使用して VMware ESXi ハイパーバイザーで実行している仮想マシンを修正し、静的 IP を使用して、仮想マシンをクローンすると、新しいクローンの仮想マシンを再起動するのにかかる時間が非常に長くなる場合があります。これは、cloud-init
が仮想マシンの静的 IP を DHCP に書き換えてから、利用可能なデータソースを検索しているからです。
この問題を回避するには、仮想マシンを最初に起動してから cloud-init
をアンインストールします。その結果、その後の再起動の速度は低下しません。
(BZ#1666961, BZ#1706482)
RHEL 8 仮想マシンが、対応するホストで起動できません。
RHEL 8 仮想マシン (VM) で pseries -rhel7.6.0-sxxm
マシンタイプを使用すると、DD 2.2 または DD2.3 CPU を使用する Power9 S922LC for HPC ホストで起動できない場合があります。
代わりに仮想マシンを起動しようとすると、以下のエラーメッセージが出力されます。
qemu-kvm: Requested safe indirect branch capability level not supported by kvm
この問題を回避するには、仮想マシンの XML 設定を次のように設定します。
<domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <qemu:commandline> <qemu:arg value='-machine'/> <qemu:arg value='cap-ibs=workaround'/> </qemu:commandline>
IBM POWER 仮想マシンが、ゼロメモリーの NUMA ノードで正常に動作しません。
現在、RHEL 8 ホストで実行している IBM POWER 仮想マシン (VM) が、ゼロメモリー (memory='0'
) を使用する NUMA ノードで設定されていると、仮想マシンが起動しません。したがって、Red Hat は、RHEL 8 ではゼロメモリー NUMA ノードを持つ IBM POWER 仮想マシンを使用しないことを強く推奨しています。
(BZ#1651474)
RHEL 7-ALT ホストから RHEL 8 への POWER9 ゲストの移行に失敗する
現在のリリースでは、RHEL 7-ALT ホストシステムから RHEL 8 に POWER9 仮想マシンを移行すると、Migration status: active のステータスで応答がなくなります。
この問題を回避するには、RHEL 7-ALT ホストで Transparent Huge Pages (THP) を無効にすることで、移行が正常に完了します。
(BZ#1741436)
AMD EPYC でホストパススルーモードを使用する際に、SMT CPU トポロジーが仮想マシンで検出されない
AMD EPYC ホストで行われた CPU ホストパススルーモードで仮想マシンを起動すると、TOPOEXT
機能フラグは存在しません。したがって、仮想マシンは、コアごとに複数のスレッドを持つ仮想 CPU トポロジーを検出できません。この問題を回避するには、ホストパススルーの代わりに EPYC CPU モデルを使用して仮想マシンを起動します。
多くの virtio-blk ディスクを使用すると、仮想マシンが起動しないことがあります。
多数の virtio-blk デバイスを仮想マシンに追加すると、プラットフォームで利用可能な割り込みベクトルの数が使い切られる可能性があります。これが発生すると、仮想マシンのゲスト OS は起動できず、dracut-initqueue[392]: Warning: Could not boot
エラーが表示されます。