Solaris OS の patchadd または patchrm の失敗についての解析
この記事は次のトピックを含みます:
注 : この記事には、Solaris 10 オペレーティングシステムだけに適用されるいくつかの項目 (たとえば新しい bootblk) への参照が含まれています。
その他の記事およびそれに関連するスクリプトは、Solaris 8、9、または 10 OS に適用されます。
patchadd または patchrm セッションが成功しなかった理由を判断するには、その根本的原因の解析を始める前に、十分な情報を集めることが重要です。
このドキュメントは、SPARC または x86 のプラットフォーム版の Solaris オペレーティングシステムのユーザー向けとして書かれています。
パッチ適用済のシステムが適切にリブートせず、ループ状態または OK プロンプト (SPARC プラットフォーム用の Solaris OS の場合) が表示される状態の場合に、何を実行すべきかに焦点を当てています。
この記事では、もっとも関連性があるファイル、これらのファイルのある場所、さらにパッチを適用するためにパッチ自動ツールが使用された場合はそのツールによって、ツールから関連する出力内容が置かれる場所について概説しています。
パッチ関連の問題では多くの異なる原因が考えられるので、このドキュメントは実際の障害の解析を支援するものではありません。いくつかの一般的な指針を提供することを目的としています。
CD-ROM またはネットワークからシステムをブートする
システムがリブートされてから、必要な実行レベルの復旧に失敗した場合、または、保守モードに入ることに失敗した場合 (つまりシステムが OK プロンプトが表示された状態になるかあるいはループに落ち入る場合)、システムをアクセス可能にするには、ネットワークまたは CD-ROM からブートして、適切なファイルシステムをマウントすることが必要です。
{1} ok
a. 最初に、システムが OK プロンプトが表示される状態にリブートした時点の適切なコンソール出力を取り込みます。
これが実際の根本的な障害の解析に深く関連する可能性があるので、この出力を保存してください。
b. この時点で、ディスクからのブートに対し、ネットワークまたはメディアからのブートに頼らずにその問題が解決できるかどうかを判断します。
c. もしメディアからシングルユーザーモードにブートしてルートファイルシステムをマウントする必要があれば、いくつかのオプションがあります:
ネットワークからのブート
CD-ROM からのブート
ネットワークからブートするには、クライアントがブートサーバーで適切に構成され、ネットワーク接続および構成が正しいことを確かめてください (これは本ドキュメントには記述していません)。
次に、このコマンドを実行します:
{1}ok boot_net -s
CD-ROM からのブートには、このコマンドを実行します:
{1} ok boot cdrom -s
a. 最初にコンソールからの全部のパニック出力を取り込みます。
b. 次に SPARC システムでは、OK プロンプトが表示された状態になるので、上記のステップ 1 の指示に従います。
x86 システムでは、ハードディスクからブートする前に、ネットワークまたは CD-ROM のいずれかからシステムがブートすることを BIOS でのブート優先度で許可されているかどうかを確かめる必要があります。
ネットワークブートを実行している場合は、クライアントがブートサーバーで適切に構成されていることを確認してください。
たとえば、DHCP を使用している場合は、クライアントのネットワーク接続および構成が正しいことを確認するか、あるいは NIS を使用している場合は、クライアントが NIS サーバーで正しく設定されていることを確認してください。
3. システムが CD-ROM またはネットワークからブートしたあと、検査されるすべての関連ファイルシステムをマウントするために、BigAdmin 記事「ネットワークまたは CD-ROM からブートしたあとで Solaris OS パッチを削除する方法」 の指示に従います。
この段階では、上記のステップ 2 のタスクがすべて完了し、システムが /a の下にマウントされたと想定します。
注 : 次のほとんどのデータは、端末への実際の patchadd 出力を除いて、patchanalysis_gather.txt スクリプトで収集されます。
patchanalysis_gather.txt スクリプトファイルのソースコード を参照してください。
1. patchadd あるいは patchrm に関連するログファイルを収集します。
patchadd セッションが単独で、patchadd ユーティリティーを通して実行され、patchadd 出力の内容がログファイルに取り込まれていないとこのデータは取得できません。出力がまだ使用可能な場合には、単純に端末かコンソールから patchadd の出力をカット&ペーストできることがあります。ここで必要としているのは、patchadd で生成された /var/sadm/patch/ 内のログファイルではなく、patchadd コマンド自体からの実際の STDOUT/STDERR 出力です。
すべての patchadd 出力を、パッチ適用中にファイルに切り替えることを強く推奨します。これにより出力が取得可能になり、あとの検査で必要な場合にその出力を容易に検索することができます。
たとえば、次のコマンドは patchadd の出力をログファイルに送ります:
patchadd <PatchID> 2>&1|tee /opt/patchlogs/118833-36.$$
2. 次の例では、/a をすべてのコマンドへのプレフィックスとして使用します。その理由は、代替メディアからブートを行い、ルートファイルシステムが /a の下にマウントされていると仮定しているからです。
Traffic Light Patch (TLP) ツールを使用して、システムにパッチが当てられている場合、TLP 出力は次のディレクトリに配置されます:
# ls /a/var/sadm/install_data/
PMGT:_TLP-Set_for_node_v4u-880c-muc07,_phase_GREEN,
_snapshot_2008-10-28_log
このデータは、patchanalysis_gather.txtで取り込まれます。これらのファイルは標準テキストファイルで、
patchadd出力を含んでいます。ひとつのファイルが TLP ツールの毎回の実行で生成されます。
3. Sun Update Connection - Enterprise (UCE) あるいは Sun xVM Ops Center (xVMOC) 1.x または 2.x を使用してシステムにパッチを当てられている場合は、
/a/var/opt/SUNWuce/agent が存在すること、つまり、UCE、xVMOC 1.x あるいは xVMOC 2.x が使用されたことを確認します。
/a/var/opt/SUNWuce/agent が存在しない場合、また、
/a/var が正しくマウントされていること (それがルートファイルシステムと分離していると仮定) を確認した場合、システムはいずれのツールによってもパッチを当てられていません。
4. 次のデータも patchanalysis_gather.txt による取り込まれます。
/a/var/opt/SUNWuce/agent が存在する場合、次のコマンドを実行し出力を見てどのパッチ自動ツールが使用されたかを識別します:
pkgparam -R /a -v SUNWucea VERSION
この出力は、UCE がインストールされていることを示します: VERSION='1.1.1-314'。
pkgparam -R/a -v SUNWscnconnmgt VERSION
この出力は、xVMOC 1.x がインストールされていることを示します: VERSION='1.0.0'。
この出力は、xVMOC 2.x がインストールされていることを示します: VERSION='2.0.0.820、REV=2009.01.26.07.57.17'。
ツール中の潜在的な問題をなくすようにサポートするため、あるいは根本的な問題を識別するために別のシステムでこの問題を再現するために、どのツールが使用されるのかを知ることは有用です。
以前に言及されたパッチオートメーションツールはすべてそれらの出力を /a/var/opt/SUNWuce/agent/logs/ の中へ格納します。:
# ls -l /a/var/opt/SUNWuce/agent/logs/
total 33032
-rw-r--r-- 1 root root 5610478 Feb 20 17:12 error.log
-rw-r--r-- 1 root root 10485681 Feb 20 13:15 error.log.ad_bak
-rw-r--r-- 1 root root 94418 Feb 20 13:28 job.log
-rw-r--r-- 1 root root 15478 Feb 19 11:02 job_50007101.tgz
-rw-r--r-- 1 root root 11377 Feb 20 13:04 job_50011801.tgz
-rw-r--r-- 1 root root 12189 Feb 20 13:15 job_50012001.tgz
-rw-r--r-- 1 root root 12185 Feb 20 13:28 job_50012002.tgz
-rw------- 1 root root 323598 Feb 19 10:53 last_nco_file.xml
-rw-r--r-- 1 root root 30730 Feb 20 13:28 last_seeking.tgz
-rw-r--r-- 1 root root 16602 Feb 20 13:28 nco.log
-rw-r--r-- 1 root root 253666 Feb 20 13:28 resolve.log
-rw-r--r-- 1 root root 1434 Feb 20 09:29 uce_agent.log
# gzcat /a/var/opt/SUNWuce/agent/logs/job_50012002.tgz | tar tvf -
drwxr-xr-x 0/0 0 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/
-rwx------ 0/0 4466 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/Task.out
-rw-r--r-- 0/0 167297 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
2/copy_inventory
-rw-r--r-- 0/0 497 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/copy_basket
-rw-r--r-- 0/0 17 Feb 20 13:28 2009 va64-x4100a-muc07_job_500120
02/copy_policy
もっとも重要なログファイルは、Task.out です。それは、実行されたコマンド patchadd の出力を含んでいます。
ただし、今後の検査の可能性に備えて、システムからすべてのファイルを /a/var/opt/SUNWuce/agent/logs/
にコピーすることが推奨されています。さらに ls -ltr of /a/var/opt/SUNWuce/agent/logs の出力もコピーしてください。
このデータは、patchanalysis_gather.txt で取り込まれます。
このセクションでは取り込むべき関連データをリストします。これらのデータはすべて patchanalysis_gather スクリプトによって取り込まれます。
patchadd -R /a -ppkginfo -R /a -ppkginfo -R /adf -k /a および /a の下のその他の任意のマウントポイント/a/var/adm/messages*/a/var/sadm/system/admin/CLUSTER/a/var/sadm/install/contents (このファイルは非常に大きい場合があります)/a/etc/system/a/etc/vfstab /a/release/a/var/sadm/system/logs/ の下のディレクトリ内容/a/var/sadm/install_data/ の下のディレクトリ内容
非大域ゾーンがある場合、次のディレクトリが有用な場合があります。
/a/etc/zones/*
このデータは patchanalysis_gather.txt によって取り込まれます。
すべての非大域ゾーンで次のディレクトリはパッチログを含んでおり、非大域ゾーンの問題を分析するために有用なデータを含んでいる場合があります。
注: 現在、patchanalysis_gather.txt スクリプトはこのデータを収集しません
<zonepath> /root/var/sadm/patch/*
前のデータが収集されたあと、patchadd 出力の検査を始めることをおすすめします。その後、さらに /var/sadm/patch/*/log から収集された、patchadd ログの検査も行なってください。
これらのログにおける、エラーおよび警告を検索してください、特に、patchadd の出力は、/var/tmp のログファイルに格納された、
pkgadd の失敗に関係がある内容を含むかもしれません。
そう場合、/a/var/tmp からこのログファイルを取得して検査してください。このファイルは問題を引き起こした原因を特定するのにとても適しています。
さらに、patchadd 出力を検査して、prepatch あるいは postpatch など、任意のパッチレベルスクリプトが失敗していないか、または予期しないメッセージの生成をしていないか、検査を行なってください。patchadd 出力と、パッチが正常に適用されたシステムからの既知の正常な patchadd 出力とを比較して、追加されたメッセージまたは削除されたメッセージをすべて検索してください。
影響を受けたシステム上に非大域のゾーンが存在する場合は、patchadd 出力を検査して、非大域のゾーンの存在によって起した特別な問題を示すエラーを捜してください。これらは次の形式をとります:
Failed to boot non-global zone <zone-name>
このメッセージは、問題の非大域ゾーンが停止されたこと、また、影響を受けたゾーンを patchadd がソフトウェア保守に使用された内部状態に移動できなかったことを示します。これが発生した場合は、/a/etc/vfstab と共に /a/etc/zones/*.xml ファイルを収集してください。これらのファイルにより、サポートエンジニアは、パッチを適用する前に少なくともシステム状態およびゾーン構成を確認できます。
df -k 出力がルートファイルシステム、あるいは /var 中での利用可能領域が 100% に達していることを表示している場合には、Sun サポートにご連絡することをお勧めます。これは、どのパッチがインストールされていたか、またパッチインストールのどの部分が破損したかに従い、システムを一貫して回復するために、特定の手動でのステップが要求されるからです。
たとえば、137137-09 ポストパッチ実行中に、/platform 中の利用可能記憶領域が 100% に到達した場合、リブート時にシステムは OK プロンプトを表示せずにブートすることはなく、ブートロードが失敗したエラーが表示されます。
このような場合、ブートアーカイブが再構築のための十分なスペースを復元できれば、引き続き損害を受けることなくシステムを容易に回復することが可能です。
これまでに説明したように、どのような作業を行う必要があるか適切に判断するには、始めに問題を正しく認識することが重要です。
問題 : /etc/path_to_inst を開くことができません。
これを修正するには、boot -ar を実行します。また、/etc/patch_to_inst を再構築するように指示された時は、「yes」を選択します。
問題 : ブートブロックの問題が発生しました。(これは Solaris 10 SPARC ベースのシステムに特有であり、カーネルアップデートパッチ 137137-09 レベルが当てられています)。通常、これらは次のうちの 1 つに似たエラーになります:
The file just loaded does not appear to be executable.Boot load failed. The file just loaded does not appear to be executable.
詳細な指示を受けるために次の情報を Sun サポートにご連絡されることをお勧めします。df -n /a | awk '{print $3}' (ルートが ./a にマウントされている場合)から $ROOTFSTYPE を取得することができます:
ls -l /platform/`uname -m`/boot_archive
ls -l /platform/`uname -m`/lib/fs/$ROOTFSTYPE/bootblk
SPARC プラットフォーム用の Solaris 10 10/08 リリース、あるいはカーネルアップデートパッチ 137137-09 が適用された場合、新規 bootblk がインストールされます。この新規 bootblk は、Solaris 10 10/08 より前のリリースを更新する場合、または 137137-09 が適用されていない場合の ufsboot のロードとは代わって、boot_archive を使用してシステムをブートします。
したがって、どの bootblk が適切かを判断することが重要です。間違った bootblk をインストールすると、正しい bootblk ががインストールされるまでシステムはリブート不能になります。この場合、Sun サポートから詳細な指示を受けられることをお勧めします。
ルートファイルシステムが、boot_archive の構築中に、/platform のスペースを使い果たしてしまった場合、次のエラーが発生します:
The file just loaded does not appear to be executable.
この場合も Sun サポートにご連絡することをお勧めします。これは、スペースを解放し、bootadm コマンドを使用して boot_archive を構築するために、最良の長期的対処方法を決定するシステムの解析が必要になるためです。
ブートブロックをインストールするためにメディアからブートするとき、installboot のようなツールを使用する場合は、正しいメディアからinstallboot を使用することが重要です。137137-09 レベルにパッチを当てたシステム、あるいはすでに Solaris 10 10/08 OS を実行しているシステム上に bootblk をインストールするためには、Solaris 10 10/08 またはそれ以降のメディアを終了したり、またはマウントされたシステムからinstallbootを使用したりすることが必要です。
したがって、たとえば、システムがネットワークから Solaris 5/08 イメージにブートされる場合、これを実行しなければなりません:
#/a/usr/sbin/installboot
次のコマンドは実行しません:
#/usr/sbin/installboot
しかし、Solaris 10 10/08 またはそれ以降のメディアからシステムがブートした場合でも、下記を実行しても問題はありません:
#/usr/sbin/installboot
したがって、マウントされたシステムへの修正のためにメディアからブートする場合、システムユーティリティーの使用には注意が必要であるということです。
使用可能な最新の Solaris 更新イメージをブートイメージとして使用することをお勧めします。
次にいくつかの追加リソースがあります:
Print-friendly Version
