よくある質問
BigFix Patch for Solaris をより深く理解するために、以下の質問と回答をお読みください。
- 「ダウンロード・プラグインの管理」ダッシュボードはデータを反映していません。どうすればよいでしょう。
- この問題のトラブルシューティングのために実施できる手順を以下に示します。
- 最新の「パッチ・サポート」サイトを収集します。
- 「パッチ・サポート」サイトから使用できる「ダウンロード・プラグインのバージョン」分析をアクティブにします。
- BigFix コンソール・キャッシュをクリアします。
- パッチが失敗しても、正常に完了するのはなぜですか。
特殊な状況で、パッチが正常に適用されているのにもかかわらず、関連状態によって、パッチが依然として必要であると示されることがあります。パッチに関連した特殊な状況がないかどうかを確認するか、または HCL ソフトウェア・サポートにお問い合わせください。
- パッチのインストールに失敗した場合は、どうすればよいでしょう。
パッチのインストールが失敗した場合は、パッチを正しいコンピューターに適用したかどうかを確認するか、Oracle Web サイトからパッチをダウンロードして手動で実行してください。
- デフォルト・アクションがないのはなぜですか。
Fixlet® またはパッチを適用する前に、必ずテスト・ベッドでテストする必要があります。Fixlet® に複数のアクションが関連付けられている場合もあります。アクションを開始する前に、Fixlet® の「説明」タブ内のテキストを必ず参照してください。
- 置き換えられるパッチとは何ですか?
置き換えられるパッチとは、適用する必要がなくなった古いバージョンのパッチです。
- どのシェルを使用すべきですか?
- BigFix Patch for Solaris では、Bourne シェル・スクリプトを使用してエンドポイントにパッケージがインストールされます。Fixlet を使用して正常にパッチが適用できるように、エンドポイントに sh 互換シェルがインストールされていることを確認してください。
- 欠落しているパッチについてはどのように処理すればよいですか。
BigFix は、アンバンドルされているパッチ以外のすべてのパッチを提供します。欠落しているパッチは置き換えられている可能性があります。最近置き換えられたコンテンツの場合は、「置き換えられた Solaris パッチの評価を有効化」タスク (ID #13) を実行して、置き換えを評価できるようにします。このタスクは「Patches for Solaris」サイトから入手できます。古いコンテンツについては、HCL ソフトウェア・サポートにお問い合わせください。
- Oracle サポート・アカウントをすでに持っているのに、パッチをダウンロードするプラグインが失敗します。なぜでしょうか?
ご使用の Oracle サポート・アカウントには、正常にパッチをダウンロードするための有効なサポート識別子が含まれていなければなりません。
- 推奨パッチ・クラスターや重要パッチ更新 (CPU) のパッチをダウンロードしてインストールするためには、どの程度のスペース量が必要でしょうか。
パッチのダウンロードおよびインストールには、少なくとも 12 GB のディスク・スペースが必要です。推奨パッチ・クラスターの場合、「Solaris 10: ディスク容量不足 - /var」タスク (ID #3) を使用して、
/varを含むファイル・システムに、パッチ・クラスターのパッチを解凍してインストールするための十分なスペースがあるかどうかを確認できます。
- パッチ・クラスターのインストールのデバッグにどのログを使用できますか?
- Patches for Solaris サイトからの Fixlet の場合
- パッチ・クラスターのインストールに使用されたコマンドをデバッグするには、/var/opt/BESClient/__BESData/__Global/Logs/<YYMMDD>.installcluster.log にあるログを確認してください。このログは BigFix のログ形式に準じており、実行のたびにタイム・スタンプから始まります。あるエンドポイントで 1 日に複数回 Fixlet® が適用された場合、各実行がログ・ファイルに追加されます。ログ・ファイルは上書きされません。
- Patches for Solaris Live Upgrade サイトからの Fixlet の場合
- パッチ・クラスターのインストールに使用されたコマンドをデバッグするには、
/var/opt/BESClient/__BESData/__Global/LUdata/<BE_name>_cluster_install.logにあるログを確認してください。あるエンドポイントで 1 日に複数回 Fixlet® が適用された場合、ログが上書きされ、最新の適用に関する詳細が記録されます。
- 「パッチ・クラスター」Fixlet の sha1 の値とサイズが古いです。なぜでしょうか?
Oracle 推奨パッチ・クラスターが頻繁に更新されるために、「パッチ・クラスター」Fixlet® の sha1 値とサイズが古くなっている可能性があります。更新された Fixlet は、パッチ・ベンダーとのサービス・レベルの合意に基づいて提供されます。
- ダウンロード・プラグインが正しく登録されているかどうかは、どのように確認すればよいですか?
ダウンロード・プラグインが正しく登録されているかどうかを確認するには、アクション・タスクと共に、Fixlet® を実行します。パッチのダウンロードが成功したことを確認します。成功していない場合には、ダウンロード・プラグインを登録解除してから再登録することが必要な場合があります。
- ダウンロード・プラグインを登録する方法を教えてください。ダウンロード・プラグインの登録タスクまたは「ダウンロード・プラグインの管理」ダッシュボードのどちらを使用すればよいですか。
- ダウンロード・プラグインを登録するには、「Patching Support」サイトの「ダウンロード・プラグインの管理」ダッシュボードを使用する必要があります。既存のダウンロード・プラグインの登録タスクは使用しないでください。プラグインの登録について詳しくは、『Solaris ダウンロード・プラグインの登録』を参照してください。注: ダウンロード・プラグインの登録解除、構成、およびアップグレードを行う際にも、「ダウンロード・プラグインの管理」ダッシュボードを使用する必要があります。既存のダウンロード・プラグインの登録解除および編集タスクは使用しないでください。ダッシュボードについて詳しくは、BigFix Knowledge Center の『「ダウンロード・プラグインの管理」ダッシュボード』のトピックを参照してください。
- パスワードは難読化されると思っていましたが、まだ平文のままです。なぜでしょうか?
ダウンロード・プラグインのバージョンが 2.0 より前であることを確認してください。2.0 より前である場合は、古いバージョンのダウンロード・プラグインを使用しています。このバージョンでは、資格情報が平文で保管されます。資格情報を暗号化するには、「Patching Support」サイトの「ダウンロード・プラグインの管理」ダッシュボードから、ダウンロード・プラグインを 2.0 以降にアップグレードしてください。
- Solaris ダウンロード・プラグインで問題が発生しています。どうすればよいでしょう。
plugin.iniディレクトリーで C:\Program Files (x86)\BigFix Enterprise\BES Server\DownloadPlugins\SolarisProtocol ファイルを見つけます。plugin.iniファイルで構成情報が正しく設定されていることを確認してください。
- 非アクティブなブート環境のアクティブ化を選択しないで、コンピューターをリブートすると、どうなりますか。
コンピューターは再び現行アクティブ・ブート環境にリブートします。
- 一部のブート環境内にすでにクライアントがあります。クライアントを「Solaris ブート環境の管理」ダッシュボードからインストールすると、それらのブート環境はどうなりますか。
そのような場合にブート環境がどうなるかについての詳細は、『BigFix クライアントのインストール時の動作』を参照してください。
- ベースラインを使ったブート環境のパッチはどのように行えばよいですか。
ベースラインを使用してブート環境でパッチを行う方法は、ベースラインを使用してコンピューターにパッチを行うのと同じ方法です。
- 1 つのマシン上で、Live Upgrade 用の複数のブート環境を選択できますか。
Solaris マシン上に複数の非アクティブなブート環境がある場合でも、Live Upgrade 用に選択できるブート環境は 1 つのみです。
- 同じマシン上にある複数のブート環境をアクティブにすることはできません。なぜでしょうか?
ブート環境をアクティブにすると、システムの次回のリブート時にブート可能になります。また、Solaris マシンでは、稼働できるブート環境は一度に 1 つのみです。
- Live Upgrade 用の複数のブート環境を選択しました。一部のブート環境がアクションから除外されるのはなぜですか。
- アクションから除外されるブート環境は、そのアクションに対する要件を満たしていない可能性があります。各アクションには、次のようなそれぞれ独自の一連の基準があります。
- Live Upgrade 用のブート環境の選択:
- クライアントはブート環境にインストールされている必要があります。
- ブート環境のアクティブ化:
- クライアントはブート環境にインストールされている必要があります。
- クライアントがインストールされていない非アクティブなブート環境で、Live Upgrade 用にその環境が選択された場合、どうすればよいですか。このシナリオが起きる可能性はありますか。
はい。このシナリオが起きる可能性があるのは、非アクティブなブート環境が 1 つのみあるシステム上で、「Solaris ライブ・アップグレードを使用可能にする」タスクが適用された場合です。デフォルトでは、タスクはクライアントの有無を調べずに、Live Upgrade 用の非アクティブなブート環境を選択します。このようなシナリオが生じた場合、「Solaris ブート環境の管理」ダッシュボードからクライアントをインストールする必要があります。
- 「Solaris ブート環境の管理」ダッシュボードにコンピューターの重複が表示されるのはなぜですか。
- コンピューターはさまざまなクライアント ID を持っています。コンピューターが不意にオフラインになった後、再びオンになると、そのコンピューターに新しいクライアント ID が割り当てられます。コンソールでは、クライアント ID が新規であるため、古いコンピューターは認識されません。レポート時刻が最も古いコンピューターを削除することをお勧めします。以下の手順を実行します。
- をクリックします。
- 削除するコンピューターを右クリックします。
- 「データベースから削除」をクリックします。
- 「Solaris ライブ・アップグレードを使用可能にする」タスクは何を行いますか。
Live Upgrade を有効にすると、バックエンド・ユーティリティー・スクリプトによってすべてのブート環境から情報が取り出されます。その情報は非暗号化テキスト形式で保存され、
/var/opt/BESClient/__BESData/__Global/LUdataに置かれます。
- Live Upgrade のログ・ファイルはどこで見つけられますか。
- ライブ・アップグレード・ログ・ファイルは
/var/opt/BESClient/__BESData/__Global/LUdataにあります。次のようなログ・ファイルをトラブルシューティングで使用できます。SLU.log- ブート環境が Live Upgrade 用に有効化されたことを検証します。
restart.log- ブート環境が正常にアクティブ化されたことを検証します。
<BE_name>_package.txt- クライアントがすでにブート環境にインストール済みであることを検証します。このテキスト・ファイルには、特定のブート環境のパッケージおよびバージョンのリストが記録されます。クライアントのバージョンがファイルにリストされていない場合、そのクライアントはインストールされていません。
<BE_name>_patch.txt- インストール済みパッチのリストを検証します。
<BE_name>_cluster_pre_install.log- 推奨パッチ・クラスター用の前提条件パッチが適用されているかどうかを検証します。
<BE_name>_cluster_install.log- 推奨パッチ・クラスターのインストールが正常に行われたかどうかを検証します。
<BE_name>_CPU_Pre_install.log- CPU 用の前提条件パッチが適用されているどうかを検証します。
<BE_name>_CPU_install.log- CPU 用のインストールが正常に行われたかどうかを検証します。
- アクティブなブート環境でダッシュボードに
Null値が表示された場合、どうすればよいでしょう。 「Solaris ライブ・アップグレードを使用可能にする」タスクまたは「ブート環境情報の更新」タスクの、どちらか適切な方を実行します。
- ブート環境を切り替えたばかりですが、新規の実行中のブート環境はサーバーに報告していません。どうすればよいでしょう。
- クライアントがインストールされているかどうかを調べます。コマンド行インターフェースから
pkginfo |grep BESを実行し、ブート環境内にクライアントが存在するかどうかを調べます。 - クライアントが実行中であるかどうかを調べます。コマンド行インターフェースから
ps -ef | grep -i besを実行し、クライアントが現在実行中であるかどうかを調べます。 actionsite.afxmファイルが/etc/opt/BESClient/にあることを確認します。- サーバー・ホスト名を ping できるかどうかを調べます。サーバー・ホスト名を ping できない場合、
/etc/hostsを編集し、IP アドレスとホスト名をファイルに追加します。
- クライアントがインストールされているかどうかを調べます。コマンド行インターフェースから
- アクションがとられた後で「Solaris ブート環境の管理」ダッシュボードの最新表示に長時間かかるのはなぜですか。
- この遅延は、バックエンドで複数のプロセスが実行されていることが原因で発生する場合があります。アクションが実行されると、ユーティリティー・スクリプトはブート環境から変更内容を取得し、その情報をテキスト形式で保管します。次に、クライアントは、そのデータをサーバーに送信します。サーバーは、分析を使用してデータを収集し、データはダッシュボードによって読み取られます。通常、対象のコンピューターがアクションの状態をダッシュボードに報告するまでに数分かかります。
- ローカル Image Packaging System (IPS) パッケージ・リポジトリーはどのように作成するのですか。
- Image Packaging System (IPS) パッケージ・リポジトリーの作成方法については、Oracle 資料の Web サイト (http://docs.oracle.com) を参照してください。
- 鍵ファイルと証明書ファイルはどこで入手できますか。
- どちらのファイルも My Oracle Support サイトから入手できます。詳しくは、『http://pkg-register.oracle.com』を参照してください。
- 鍵ファイルと証明書ファイルは、常に
.pem形式ですか。 - はい、どちらのファイルも Oracle Support サイトからダウンロードしたときは
.pem形式になっています。注「Solaris Image Packaging System リポジトリーの管理 (Solaris Image Packaging System Repository Management)」ダッシュボードで使用できる鍵ファイルと証明書ファイルは、.pem形式のものに限られます。
- Solaris 11 エンドポイントにパッチを適用するときは、シングル・ユーザー・モードにする必要がありますか。
- Live Upgrade は Image Packaging System (IPS) で処理されるため、シングル・ユーザー・モードにする必要はありません。詳しくは、『http://www.oracle.com/technetwork/server-storage/solaris11/overview/solaris-matrix-1549264.html』を参照してください。
- SRU のパッチをダウンロードしてインストールするには、どの程度のスペースが必要ですか。
- 必要なスペースは、どのファイルがシステムにインストールされるのかによって正確に決まります。SRU のパッチ適用を行う場合、システムは欠落しているパッケージを調査し、関係のあるファイルのみをダウンロードします。重要: セキュリティー上の理由から、ファイル・アプリケーションでは添付ファイル配置が使用されます。
「ディスクに制限あり」
エラーを避けるために、サーバーおよびリレーのキャッシュ・サイズ全体を拡張し、ダウンロードする大きなサイズの SRU に対応できるようにしてください。SRU は巨大になる場合があり、イメージ・ファイルあたり約 2.7 GB になることもあります。キャッシュを拡張しないと、巨大なダウンロード・ファイルによって、キャッシュ内の既存ファイルがフラッシュされることがあります。
- 既存の Live Upgrade オファーは、Solaris 11 でも機能しますか。
- いいえ、残念ながら機能しません。既存の Live Upgrade ソリューションは、Solaris 10 でのみ機能します。
- 自分のマシンにパッチを適用しようとしていますが、一時スペースが非常に限られています。これは問題があると考えるべきですか。
- Solaris 11 の Image Packaging System (IPS) では、SRU 全体がダウンロードされるわけではありません。システムは、欠落しているパッケージを調査し、関係のあるファイルのみをダウンロードします。
- ローカル・リポジトリーがありますが、これを使用して Solaris 11 エンドポイントにパッチを適用するには、どのようにローカル・リポジトリーを設定すればよいですか。
- 「Solaris Image Packaging System リポジトリーの管理 (Solaris Image Packaging System Repository Management)」ダッシュボードを使用して、パッチ適用のために使用するようにローカル・リポジトリーを設定します。
- 最新の SRU を使用して Solaris 11 システムにパッチを適用したいのですが、インターネットに接続できません。どうすればよいでしょう。
- 最新の SRU イメージを取り込むことのできるローカル・リポジトリーが必要です。エンドポイントは、インターネットに接続する代わりに、そのリポジトリーを使用できます。
- ローカル・リポジトリーを最新にするためにすべてのタスクを実行する必要はありますか。あるいは、最新のサポート・リポジトリー更新 (SRU) を使用してタスクを実行できますか。
- すべての SRU をインストールする必要はありません。エンドポイントを最新の状態に維持するには、最新の SRU をインストールしてください。ただし、エンドポイントで特定の SRU が必要な場合は、ベース・リポジトリー・コンテンツと、エンドポイントのアップグレード先の SRU をリポジトリーでホストする必要があります。たとえば、Solaris 11/11 エンドポイントと 11.1 エンドポイントの両方があり、これらを最新の状態に維持する場合は、以下のコンテンツをリポジトリーでホストする必要があります。
- Solaris 11 11/11 リポジトリー・ベース・イメージ + SRU 13.4 (最新 SRU)
- Solaris 11 11.1 リポジトリー・ベース・イメージ + SRU 21.4.1(最新 SRU)
- SRU のパッチ適用を行う場合、どのような方法が推奨されますか。ローカル・リポジトリー経由ですか、それともサポート・サイト経由ですか。
- ローカル・リポジトリーを使用すると、ダウンロード速度やネットワーク負荷の点で有利です。
- Solaris 11 のログはどこにありますか。
- Solaris 11 のログは、/var/opt/BESClient/IPSData/ にあります。Solaris 11 のパッチのトラブルシューティングには、以下のログ・ファイルを使用できます。注: これらのログには、Fixlet® またはタスクからのアクションの最新の結果が示されています。
pkg_set_publisher.log- 「Solaris Image Packaging System リポジトリーの管理 (Solaris Image Packaging System Repository Management)」ダッシュボードで新しいリポジトリーがエンドポイントに割り当てられたかどうかを検証するためのものです。
update_repo_sru.log- リポジトリー更新タスクが成功したかどうかを検証するためのものです。このログ・ファイルには、各種のアクション: (圧縮ファイルの解凍、イメージのマウント、リポジトリーへのコンテンツのコピー、リポジトリー・インデックスの再構築) に関する情報が記録されています。 注: リポジトリーの検証が失敗した場合、このログには情報が記録されません。このエラーはコンソールに表示されるだけです。失敗したコンピューターで
「アクション情報の表示...」
をチェックできます。
pkg_update_entire.log- 指定された SRU でエンドポイントが更新されたかどうかを検証するためのものです。このログ・ファイルには、以下のコマンドからの出力が記録されています。
pkg update entire@PACKAGE_VERSION_FOR_THAT_SRU
- pkg_deployment_results.log
- 「pkg を使用したパッケージのインストール (Install packages by using pkg)」タスクを使用したパッケージのインストールが正常に行われたかどうかを検証します。このログ・ファイルには、以下のいずれかのコマンドからの出力が記録されています。
pkg install <package_name1> <package_name2> pkg update
「Patches for Solaris」
サイトと「Patches for Solaris Live Upgrade」
サイトに表示される Fixlet® コンテンツの違いは何ですか?- 「Patches for Solaris」サイトには、レガシー Solaris 10 以前の中核的な OS パッチ・コンテンツが含まれています。ここでは、CPU や推奨パッチ・クラスターのパッチを適用する際に、さらに古い従来のシングル・ユーザー・モードを使用しています。「Patches for Solaris Live Upgrade」サイトに含まれているパッチ・コンテンツは、Solaris Live Upgrade ユーティリティーを使用して、現在実行されている OS ではなく、非アクティブなブート環境にパッチをインストールします。このサイトのコンテンツには、セキュリティー・パッチ、推奨パッチ・クラスター、および重要パッチ更新があります。
「Patches for Solaris Live Upgrade」
サイトにある Fixlet® を使用して、非アクティブな BE に CPU パッチを適用しました。これをリブートしない場合、「Patches for Solaris」
サイトにある同じ CPU パッチが引き続き関連のあるものとして表示されているように見えます。なぜでしょうか?- これらの 2 つのサイトにおける特定のパッチの関連度は異なります。「Patches for Solaris Live Upgrade」サイトの Fixlet は、非アクティブなブート環境にパッチを適用します。一方、「Patches for Solaris」サイトの Fixlet は、実行中のブート環境にパッチを適用します。非アクティブなブート環境をリブートしない場合、アクティブなブート環境の状況は現行のままです。引き続きそのパッチの関連性が表示される理由の 1 つとして、アクティブなブート環境が同じ CPU でパッチ適用されていない可能性が考えられます。
- ゾーンを構成する方法を教えてください。
- 非グローバル・ゾーンの構成について詳しくは、『Oracle System Administration Guide』(http://docs.oracle.com/cd/E19044-01/sol.containers/817-1592/z.conf.start-29/index.html) を参照してください。
- 指定したゾーンに Fixlet® をパッチ適用する方法を教えてください。
- Fixlet® は
patchadd -Gオプションを使用して、現在のゾーンにパッチを適用します。patchaddオプションについて詳しくは、『http://docs.oracle.com/cd/E19253-01/816-5166/patchadd-1m/index.html』 を参照してください。
- ゾーンからパッチを削除する前に、何をする必要がありますか?
- そのパッチが他のインストール済みパッチから依存されていないこと、および元のパッチ・ファイルのバックアップが存在することを確認してください。これをしないと、ロールバック・アクションが失敗し、その結果、パッチがゾーン内にインストールされたままになる場合があります。
- ロールバック・ログはどこに格納されていますか?
-
/var/opt/BESClient/__BESData/Patches for Solaris/__PatchRollback/ にある
rollback.logファイルを使用します。
- Solaris のパッチまたは Fixlet® コンテンツがゾーン・パッチ適用をサポートしているかどうかは、どうすれば分かりますか?
- Solaris パッチの情報ファイルをチェックして、
SUNW_PKG_ALLZONES変数の値を確認してください。パッチ・パッケージが TRUE に設定されている場合、Oracle はすべてのゾーン (グローバル・ゾーンおよび非グローバル・ゾーン) に強制インストールすることを意味します。このようなパッチの Fixlet® コンテンツでは、インストール・アクションは 1 つのみです。パッチ・パッケージが FALSE に設定されている場合、インストールはグローバル・ゾーンまたは非グローバル・ゾーンのいずれかで行うことができます。このようなパッチの Fixlet® では、2 つのインストール・アクションが行われます。
- ローカル・リポジトリーにあるカスタム・パッケージをインストールするには、どうすればよいですか?
- 「Patches for Solaris 11」サイトから「pkg を使用したパッケージのインストール (Install packages by using pkg)」タスクを使用できます。
- インストール・タスクを使用して、複数のカスタム・パッケージをインストールできますか?
- はい、使用可能なタスクを使用して複数のカスタム・パッケージをインストールすることができます。パッケージ名を区切るために、スペースを使用してください。
- 「pkg を使用したパッケージのインストール」タスクを使用して、単一ファイルのパッケージをインストールできますか?
- 単一ファイルのインストールには、pkgadd コマンドを使用します。「pkg を使用したパッケージのインストール」タスクは、pkg コマンドのみをサポートしています。
- 「pkg を使用したパッケージのインストール 」タスクが失敗した場合に考えられる原因は何ですか?
- この失敗の考えられる原因は以下のとおりです。
- リポジトリーが構成されていない。
- リポジトリーがエンドポイントに登録されていない。
- エンドポイントでインターネット接続が使用できない。
- 「pkg を使用したパッケージのインストール」を使用してパッケージをインストールしました。パッケージが正常にインストールされたかどうかは、どのように確認すればよいですか?
- 「Image Packaging System の結果」分析を使用すると、「pkg を使用したパッケージのインストール」タスクを使用してインストールされたパッケージがエンドポイントに正常にインストールされたかどうかを確認できます。
- 「Image Packaging System の結果」分析で何も返されません。なぜでしょうか?
- 「pkg を使用したパッケージのインストール」タスクを少なくとも 1 回適用して、エンドポイントの
pkg_list.logファイルを作成する必要があります。このファイルにはエンドポイントのインストール済みパッケージがすべて格納され、「Image Packaging System の結果 (Image Packaging System Results)」分析で使用されます。
- ディスク・ミラーの分割および再ミラーリングについてのログ・ファイルはどこにありますか?
break_mirrors.logファイルとre_mirrors.logファイルはどちらも /var/opt/BESClient/EDRDeployData フォルダー内にあります。
- ルート・ディスク・ミラーを分割した後にそれらを再ミラーリングするにはどうすればよいか?
- 「Patches for Solaris」サイトから「Solaris ディスクの再ミラー」タスクを使用すると、サブミラーまたはディスクをオンラインに戻すことができます。このタスクで使用するコマンドについて詳しくは、『http://docs.oracle.com/cd/E23824_01/html/821-1462/metattach-1m.html』 を参照してください。
- 「Solaris ミラーの分割 (Break Solaris mirrors)」タスクでは、どのようなタイプのミラーリングがサポートされていますか?
- 「Solaris ミラーの分割 (Break Solaris mirrors)」タスクでは次の UFS ミラーを分割できます: ルート (
(/))、/var、/opt、および/usr。ZFS ファイル・システムのミラーまたは VxVM ベースのミラーはサポートされていません。
- 1 つのミラーにいくつのサブミラーを含めることができますか?
- 最大 3 つのサブミラーまたはディスクから成る 1 つのミラーを作成できます。詳しくは、『Solaris Volume Manager Administration Guide』 (http://docs.oracle.com/cd/E19253-01/816-4520/) を参照してください。
- 非アクティブな ZFS ブート環境にパッチを適用しようとしましたが、関連する Fixlet が
「Patches for Solaris Live Upgrade」
で見つかりません。どうすればよいでしょう。 - Solaris Live Upgrade を使用する際に同時にマウントできる ZFS ブート環境は、最大 2 つです。マウントされた ZFS ブート環境が 2 つを超えている場合、Fixlet® の関連度の評価に失敗します。この問題が発生した場合は、以下の手順を実行してください。
- 「Solaris ライブ・アップグレードを使用可能にする」タスク (ID #2) がエンドポイントに関連付けられているかどうかを確認します。
- エンドポイントの /.alt.<BE_Name> フォルダーを確認して削除します。
mountおよびzfs listの結果を確認し、ゾーン・ファイル・システムのマウント・ポイントをリセットするためにコンピューターを再起動します。- エンドポイントで「Solaris ライブ・アップグレードを使用可能にする」タスク (ID #2) を実行します。
- 「エンドポイント・アップグレード・リスト - Solaris 11 (Endpoint Upgrade List - Solaris 11)」分析をアクティブ化する前に、なぜ、「使用可能なパッケージ更新の確認 - Solaris 11 (Check Available Package Updates - Solaris 11)」タスクを実行する必要があるのですか?
- このタスクにより、
pkg_upgrade_output.txtという出力ファイルが /var/opt/BESClient/IPSData/ フォルダーに格納されます。このファイルは、アップグレードをする必要があるエンドポイントのリストを表示するために、分析で使用されます。このタスクを一度も実行していない場合、分析では、このファイルが存在しないと示されます。分析で確実に最新の内容が表示されるようするには、このタスクを実行してください。
- 「エンドポイント・アップグレード・リスト - Solaris 11 (Endpoint Upgrade List - Solaris 11)」分析を表示する前に、「使用可能なパッケージ更新の確認 - Solaris 11 (Check Available Package Updates - Solaris 11)」タスクを実行する必要がありますか?
- はい、分析の結果を表示する前に、このタスクを実行してください。このタスクを定期的に実行することで、最新の内容を収集できます。
- 「エンドポイントのアップグレード・リスト - Solaris 11」分析で、エンドポイントの出力ファイルの 1 つを構文解析できないことが示されています。何が起こっているのですか。
- /var/opt/BESClient/IPSData/ フォルダーに保存されている
pkg_upgrade_output.txtファイルが破損している可能性があります。以下の手順を実行します。pkg_upgrade_output.txtファイルの指示を確認して従います。- 「使用可能なパッケージ更新の確認 - Solaris 11 (Check Available Package Updates - Solaris 11)」タスクを再度実行し、
pkg update -nコマンドを実行して既存のpkg_upgrade_output.txtファイルを上書きします。 - 分析を再度確認します。