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