第9章 インストールおよび起動
キックスタートでネットワーク設定が提供される場合に initrd のネットワーク設定を修正
以前は、これらのインターフェイスがキックスタートファイルで定義されている場合、インストーラーは
initrd でネットワークインターフェイスを設定または再設定できませんでした。これにより、キックスタートファイル内の他のコマンドでネットワークアクセスが必要な場合は、インストールが失敗し、緊急モードになる可能性がありました。
この問題は解決され、Anaconda が起動プロセスの初期段階で
initrd のキックスタートファイルからのネットワーク設定を適切に処理するようになりました。
Anaconda がキャッシュされた論理ボリュームの作成に対応
インストーラーは、キャッシュされた LVM 論理ボリュームの作成と、そのボリュームへのシステムのインストールをサポートするようになりました。
現在、このアプローチはキックスタートでのみサポートされます。キャッシュされた論理ボリュームを作成するには、logvol キックスタートコマンドの新しい --cachepvs=、--cachesize= オプション、および --cachemode= オプションを使用します。
これらの新しいオプションの詳細は、Red Hat Enterprise Linux 7 インストールガイド を参照してください。
GRUB2 ブートメニューのソートを向上
grub2-mkconfig コマンドで使用されるソートメカニズムの問題により、grub.cfg 設定ファイルが誤ってソートされたカーネルで生成される可能性があります。
GRUB2 は rpmdevtools パッケージを使用して利用可能なカーネルをソートし、設定ファイルが上部に記載されている最新のカーネルバージョンで正しく生成されるようになりました。
ディスクの選択変更時に Anaconda がディスクアクションを適切に元に戻すようになりました。
以前は、Anaconda および Blivet は、ディスクの選択が変更されたときにディスクでスケジュールされたアクションを適切に元に戻せず、さまざまな問題が発生していました。今回の更新で、Anaconda が、元のストレージ設定のスナップショットを作成し、ディスクの選択が変更されたときにこれに戻るように修正され、ディスクに対してスケジュールされているすべてのアクションを完全に元に戻すようになりました。
デバイスマッパーディスク名の検出を改善
Red Hat Enterprise Linux 7 の以前のリリースでは、以前は LVM 論理ボリュームが含まれていて、それらのボリュームのメタデータがまだ存在していたディスクにインストールすると、インストーラーがクラッシュする可能性がありました。インストーラーは正しい
デバイスマッパー 名を認識できず、新しい LVM 論理ボリュームを作成するプロセスが失敗しました。
デバイスマッパーデバイス 名の取得に使用される方法が更新され、既存の LVM メタデータが含まれるディスクへのインストールがより信頼性が向上しました。
パーティショニング時の PReP Boot の処理を修正
状況によっては、カスタムパーティション設定中に IBM Power Systems の
PReP Boot パーティションを無効なサイズに設定する場合があります。この状況では、パーティションを削除すると、インストーラーがクラッシュしていました。
チェックは anaconda に実装され、
4096 KiB から 10 MiB までのパーティションのサイズが常に正しく変更されるようになりました。また、サイズを変更するために PReP Boot パーティションの形式を変更する必要がなくなりました。
RAID1 デバイスの EFI パーティション
EFI システムパーティションを RAID1 デバイスに作成できるようになりました。これにより、1 つのブートディスクに障害が発生した場合のシステム復元が有効になります。ただし、システムは EFI システムパーティションを 1 つだけ検出することが保証されているため、ファームウェアによって検出された ESP のボリュームが破損している（ただし、有効な ESP であるように見えます）、Boot### および BootOrder も破損すると、ブート順序は自動的に再構築されません。この場合、システムは 2 番目のディスクから手動で起動するはずです。
ネットワークの設定時にテキストモードのインストールがクラッシュしなくなる
以前のバージョンでは、インタラクティブテキストモードインストーラーの Network Configuration 画面で、ネームサーバーを指定する際にスペースを使用すると、インストーラーがクラッシュしていました。
Anaconda はネームサーバー定義のスペースをテキストモードで正しく処理し、ネームサーバーアドレスを分離するためにスペースを使用するとインストーラーがクラッシュしなくなりました。
IBM System z のレスキューモード画面がオフではなくなる
以前は、IBM System z サーバーのレスキューモードにある 2 番目の画面と 3 番目の画面が正しく表示されず、インターフェイスの一部がカットオフされていました。このアーキテクチャーのレスキューモードが改善され、すべての画面が正しく機能するようになりました。
Anaconda の OpenSCAP アドオン
インストールプロセス中に、SCAP (Security Content Automation Protocol)コンテンツを適用できるようになりました。この新しいインストーラーアドオンは、カスタムスクリプトに依存しない、信頼性が高く、簡単な方法でセキュリティーポリシーを設定します。
このアドオンは、新しいキックスタートセクション(%addon org_fedora_oscap)と対話式インストール中のグラフィカルユーザーインターフェイスの新しい画面を提供します。3 つの部分はすべて、Red Hat Enterprise Linux 7 インストールガイドに記載されています。
インストール時にセキュリティーポリシーを適用すると、有効にするポリシーに応じて、インストール直後にさまざまな変更が実行されます。プロファイルを選択すると、openscap-scanner パッケージ(OpenSCAP コンプライアンススキャンツール)がパッケージ選択に追加され、インストールの完了後に初期コンプライアンススキャンが実行されます。このスキャンの結果は
/root/openscap_data に保存されます。
scap-security-guide パッケージにより、インストールメディアに複数のプロファイルが提供されています。必要に応じて、HTTP、HTTPS、または FTP サーバーから、データストリーム、アーカイブ、または RPM パッケージとして他のコンテンツを読み込むこともできます。
すべてのシステムでセキュリティーポリシーを適用する必要はないことに注意してください。このアドオンは、組織のルールまたは政府の規制が特定のポリシーが義務付けられている場合にのみ使用してください。そうでないと、セキュリティーポリシーを適用しないデフォルトの状態にアドオンを残すことができます。
CD または DVD のキックスタートファイルを待機しているときに Anaconda がタイムアウトしなくなる
以前は、Anaconda が inst.ks=cdrom:/ks.cfg コマンドを使用して光学メディアからキックスタートファイルを読み込むように設定されており、システムが CD または DVD からも起動した場合、インストーラーはユーザーがディスクをスワップするまで 30 秒しか待機しませんでした。この期間が経過すると、システムは緊急モードに入ります。
今回の更新で、ユーザーが CD または DVD でキックスタートファイルを提供するのを待つときに、Anaconda がタイムアウトしないように変更されました。inst.ks=cdrom 起動オプションが使用され、キックスタートファイルが検出されない場合、Anaconda はプロンプトを表示し、ユーザーがファイルを提供するか、または再起動するまで待機します。
