Show Table of Contents
第35章 インストールと起動
キックスタートファイルで %packages --nobase --nocore を指定すると、トレースバックとともにインストールが失敗する
キックスタートファイルに
%packages セクションが含まれていて --nobase と --nocore のオプションを同時に指定するとトレースバックメッセージが出てインストールが失敗します。これは、yum-langpacks パッケージがないためです。
この問題を回避するには、キックスタートファイルで
%packages --nobase --nocore を使用する際に、%packages セクションに yum-langpacks パッケージを追加します。
キックスタートで指定された root パスワードがポリシー要件を満たさない場合、インストールを続行できない
root パスワードを定義しているキックスタートファイルを使用していて、そのパスワードが Security Policy で選択されたセキュリティーポリシーの要件を満たさない場合、インストールを完了することができません。
インストールの開始 ボタンが灰色表示され、このボタンを押す前に root パスワードを手動で変更することができません。
この問題を回避するには、キックスタートで使用するパスワードが選択されたセキュリティーポリシーで定義されている要件を満たすことを確認します。
レスキューモードで Btrfs の root ボリュームの検出とマウントに失敗する
インストーラーのレスキューモード (インストールメディアのブートメニューから、または
inst.rescue ブートオプションを使用してアクセス) では、Btrfs サブボリューム上に配置された / (root) ディレクトリーがある既存システムを検出できません。代わりに、'You don't have any linux partitions.' というエラーメッセージが表示されます。
この問題を回避するには、shell に入り、root ボリュームを手動でマウントします。
Initial Setup で間違ったウィンドウのタイトル
Initial Setup ツールは、インストール後の最初の再起動後に自動的に表示され、ネットワーク接続やシステム登録ができるものです。このウィンドウタイトルに
__main__.py という文字列が表示されます。
これは表面上の問題で、使用上の問題はありません。
FBA DASD の IBM System z 上で再インストールを実行すると、インストーラーがクラッシュする
Fixed Block Architecture (FBA) DASD の IBM System z 上で Red Hat Enterprise Linux 7 を再インストールすると、これらデバイスのサポートが完全でないことから、インストーラーがクラッシュします。
この問題を回避するには、FBA DASD をデバイスの無視対象リストに入れて、インストール中に存在しないようにします。これは、インストーラーの起動前に行なってください。root シェルから
chccwdev コマンドを実行し、さらに cio_ignore コマンドでデバイスを手動でオフラインに切り替え、デバイスの無視対象リストに追加します。
別の方法では、これらのコマンドを使用する代わりに、インストール開始前に CMS 設定ファイルからすべての FBA DASD デバイス ID を削除します。
IBM System z でのインストール後に HyperPAV エイリアスが利用できない
既知の問題により、HyperPAV エイリアスとして設定された DASD をインストール後に自動的にシステムにアタッチすることができません。これらのストレージデバイスはインストール中に Installation Destination 画面で利用可能となっていますが、インストール後に再起動すると、すぐにはアクセスできません。
この問題を一時的に (次回の再起動まで) 解決するには、
chccwdev コマンドを使用してこれらのデバイスをデバイスブラックリストから削除します。
# chccwdev -e <devnumber>
再起動後も HyperPAV エイリアスを利用可能にするには、デバイス番号を
/etc/dasd.conf 設定ファイルに追加します。
lsdasd コマンドを使うとデバイスが利用可能になったことが確認できます。
IBM System z 上で生成された anaconda-ks.cfg ファイルがシステムの再インストールに使用できない
anaconda-ks.cfg ファイルはシステムのインストール中に生成されるキックスタートファイルで、インストールプロセス中に選択されたものがすべて含まれています。このファイルは、 IBM System z DASD 上のディスクサイズを小数で表示します。これは DASD が 4KiB アライメントをレポートするためですが、受け入れられるのは整数のみであることから、計算されたディスクサイズはキックスタートファイルに記録される際に間違ったものになります。このため、生成されたキックスタートファイルを使用してインストールを再生することができません。
IBM System z 上で
anaconda-ks.cfg ファイルを使用してシステムを再生するには、すべての小数値を手動で整数に変更する必要があります。
インストール中の NetworkManager のエラーメッセージ
システムのインストール中に、次のエラーメッセージが表示され、ログに記録されることがあります。
ERR NetworkManager: <error> [devices/nm-device.c:2590] activation_source_schedule(): (eth0): activation stage already scheduled
このエラーメッセージのためにインストールが完了できないことはありません。
libocrdma パッケージが InfiniBand Support パッケージグループから欠落している
libocrdma パッケージが InfiniBand Support グループのデフォルトパッケージセットに収納されていません。このため InfiniBand Support グループを選択し、Emulex OneConnect アダプターでの RoCE (RDMA over Converged Ethernet) の正常な動作を期待しても、必要なドライバー libocrdma がデフォルトではインストールされません。
初回の起動時、手作業で次のコマンドを実行し足りないパッケージをインストールします。
# yum install libocrdma
別の方法では、キックスタートファイルの
%packages セクションに libocrdma パッケージを追加します。
これで Emulex OneConnect デバイスを RoCE モードで使用できるようになります。
/boot パーティションのサイズが十分でないため、システムのアップグレードができない
/boot パーティションにはインストール済みのカーネルや初期 ram ディスクが含まれていますが、複数のカーネルや kernel-debug などの新たなパッケージがインストールされると、満杯になってしまう場合があります。これはインストール中にこのパーティションのサイズがデフォルトの 500 MB に設定されるためで、システムがアップグレードできなくなります。
回避策としては、
yum を使用して不要になった古いカーネルを削除します。新規システムをインストールする場合はこの可能性を考慮して、/boot パーティションをデフォルトサイズ (500 MB) よりも大きいサイズ (例えば 1 GB) に設定します。
1 つ以上のディスクでラベルが欠けている場合、マルチパスデバイスでのインストールが失敗する
マルチパスデバイスへのインストール時には、マルチパスのメンバーである 1 つ以上のディスクの読み込みに失敗すると、インストーラーがエラーダイアログを表示します。この問題は、1 つ以上のディスクでラベルが欠けていて、その場合にインストールが続行できないために発生します。
この問題を回避するには、インストール中に使用するマルチパスデバイスの一部であるディスクすべてでディスクラベルを作成します。
ホスト名が %pre スクリプトで定義されていると、キックスタートの静的 IPv4 設定が上書きされる
キックスタートファイルの
%pre セクションでホスト名を定義する際、ホスト名を設定するだけの network コマンド ("network --hostname=hn") は、デフォルトの --bootproto 値 ("dhcp") およびデフォルトの --device 値 ("link"、これはリンクが見つかった最初のデバイスを意味します) のデバイス設定とみなされます。するとキックスタートは、network --hostname=hn --device=link が使用されたかのように動作します。
--device オプションでデフォルトとみなされているデバイス (リンクが見つかった最初のデバイス) が静的 IPv4 設定を使用するように設定されている場合 (例えば、前の network コマンドで)、この設定は --hostname オプションで暗黙に示される IPv4 DHCP で上書きされます。
この問題を回避するには、ホスト名を定義する
network コマンドを最初に使用し、その次に通常は上書きされる 2 つ目の network コマンドを使用するようにします。
キックスタートファイル内でホスト名を定義する
network コマンドがそれ 1 つの場合、--device オプションに存在しないインターフェースを指定して追加します (例、network --hostname=hn --device=x)。
キックスタートで realm コマンドを使用すると、インストーラーがクラッシュする
既知の問題により、
realm コマンドはキックスタートファイルで使用できません。インストール中にこのコマンドを使って Active Directory または Identity Management ドメインに参加しようとすると、インストーラーがクラッシュします。
この問題を回避するには、インストールが完了するのを待ってから手動でドメインに参加するか、
realm join <realm name> コマンドをキックスタートファイルの %post セクションに追加します。コマンドラインを使ってドメインに参加することについての情報は、realm(8) man ページを参照してください。
システムアップグレード中にインストールのビルドインヘルプが更新されない
Red Hat Enterprise Linux 7.1 から 7.2 にアップグレードする際に、Anaconda インストールのビルドインヘルプ (anaconda-user-help パッケージ) が更新されません。これはパッケージが大幅に変更されているためです。
この問題を回避するには、アップグレード実行前に
yum を使用して anaconda-user-help パッケージを削除し、Red Hat Enterprise Linux 7.2 へのアップグレードが完了した後でこのパッケージを再度インストールします。
grubby により間違った順序のブートメニューエントリーが生成される
grubby ツールは、GRUB2 ブートローダー設定ファイルの修正と更新に使用されますが、ブートメニュー設定ファイルを生成する際にリストの最上部にデバッグブートメニューエントリーを追加する場合があります。通常のエントリーがデフォルトでハイライト表示され選択されていても、このデバッグメニューエントリーがこれらのエントリーを押し下げます。
複数のドライバー更新イメージを同時に使用しても、最後に指定されたものだけが適用される
インストール中に
inst.dd=/dd.img ブートオプションを使用し、複数のドライバー更新イメージを一度に読み込むように指定してドライバー更新の実行を試みると、Anaconda は最後のパラメーターインスタンスを除いてすべて無視します。
この問題を回避するには、以下の方法があります。
* 可能な場合はインストール後に追加ドライバーをインストールする
*
driverdisk キックスタートコマンドのようなドライバー更新イメージを指定する別の方法を使用しる
* 複数のドライバー更新イメージを 1 つにする
LDL 形式の DASD を検出するとインストールがクラッシュする
IBM System z 上で LDL (Linux Disk Layout) 形式の DASD を検出すると、インストーラーがクラッシュします。このクラッシュは
libparted ライブラリー内の競合状態によって発生し、これらの DASD がインストールターゲットとして選択されていなくても発生します。これ以外のアーキテクチャーでは、この問題はありません。
LDL 形式の DASD をインストール中に使用する場合は、インストーラーを起動する前に root シェルの
dasdfmt コマンドを使用して各 LDL DASD を手動で CDL (Compatible Disk Layout) に再フォーマットします。
LDL DASD がシステム上に存在し、これらをインストール中に使用したくない場合は、インストールプロセス中はデバイスの無視対象リストに入れてます。これは、インストーラーの起動前に行なってください。root シェルから
chccwdev コマンドを実行し、さらに cio_ignore コマンドでデバイスを手動でオフラインに切り替え、デバイスの無視対象リストに追加します。
別の方法では、これらのコマンドを使用する代わりに、インストール開始前に CMS 設定ファイルからすべての LDL DASD デバイス ID を削除します。
カーネルと redhat-release パッケージのアップグレード後に再起動するとカーネルパニックが発生
redhat-release-server-7.2-9.el7 と kernel パッケージを同一の Yum 操作でインストールすると、GRUB2 設定の新規カーネルメニューエントリーで
initrd の行が欠落します。すると、最後にインストールされたカーネルを使って起動を試みると、この行がないことからカーネルパニックが発生します。この問題は通常、yum update を使って以前のマイナーリリースから Red Hat Enterprise Linux 7.2 にシステムアップグレードを行う際に見られます。
この問題を回避するには、redhat-release-server と kernel のパッケージを別の Yum 操作でアップグレードするようにします。別の方法では、GRUB2 設定ファイルの新規カーネルのメニューエントリーを確かめ (BIOS システムでは
/boot/grub2/grub.cfg、UEFI システムでは /boot/efi/EFI/redhat/grub.cfg)、ここに initrd を手動で追加します。
initrd の設定の行は、
initrd /initramfs-3.10.0-327.el7.x86_64.img のようになります。ファイル名が同一メニューエントリー内で設定されたカーネル (vmlinuz) と一致すること、またファイルが /boot ディレクトリー内に存在することを確認します。古いメニューエントリーを参照してください。
グラフィカル環境がインストールされていても、Initial Setupがテキストモードで開始される
Initial Setup ユーティリティーはインストールが完了し、インストールされたシステムの初回起動後にスタートします。これが場合よっては、グラフィカル環境が利用可能でグラフィカルバージョンの Initial Setup がスタートすべき状況でも、テキストモードでスタートするケースがあります。これは、Initial Setup のグラフィカルとテキストの両方のモードが有効になっているために発生します。
この問題を回避するには、インストール中にキックスタートファイルを使用し、
%post セクションを含めて実行しないバージョンの Initial Setup を無効にします。
インストール後にグラフィカルバージョンの Initial Setup を実行するようにするには、以下の
%post セクションを使用します。
%post systemctl disable initial-setup-text.service systemctl enable initial-setup-graphical.service %end
テキストモードの Initial Setup を使用するには、
enable と disable コマンドを入れ替えて、グラフィカルサービスを無効に、テキストモードを有効にします。
/lib/ と /lib64/ のルート以外のファイルシステムへのリンクが ldconfig.service により削除される
Red Hat Enterprise Linux 7.2 では
ldconfig.service が導入され、ルート以外のファイルシステムがマウントされる前に、起動プロセスの初期段階で実行されます。ldconfig.service が実行されると、/lib/ ディレクトリーと /lib64/ ディレクトリー内のリンクが削除されます (これらのリンクがまだマウントされていないファイルシステムを参照する場合)。この問題を回避するには、これらのシンボリックリンクが削除されずに、システムが期待どおりに起動するようコマンド systemctl mask ldconfig で ldconfig.service を無効にします。
Red Hat Enterprise Linux 7.2 へのアップデート後に IPC を使用しているデーモンが予期せずに終了する
Red Hat Enterprise Linux 7.2 では、ユーザーが完了した最後のセッションでのすべての割り当て済みプロセス間通信 (IPC) リソースのクリーンアップという新しい
systemd 機能が導入されました。セッションは管理 cron ジョブまたは対話型セッションになります。この動作により、同じユーザーで同じリソースを使用して実行されているデーモンが予期せず終了することがあります。この問題を回避するには、ファイル /etc/systemd/logind.conf を編集し、以下の行を追加します。
RemoveIPC=no
次に、以下のコマンドを実行して変更を反映します。
systemctl restart systemd-logind.service
これらの手順の実行後は、説明された状況でデーモンがクラッシュしなくなります。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.