Cisco MDS 9000 ファミリー トラブルシューティング ガイド Release 3.x
インストール、アップグレード、およ び再起動のトラブルシューティング
インストール、アップグレード、および再起動のトラブルシューティング
発行日;2012/01/13 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 6MB) | フィードバック

目次

インストール、アップグレード、および再起動のトラブルシューティング

概要

ベスト プラクティス

インストールのベスト プラクティス

アップグレードのベスト プラクティス

再起動のベスト プラクティス

モジュールの中断のあるアップグレード

ファブリック スイッチにおける中断のないアップグレードでのトラブルシューティング

Fabric Manager のインストールのトラブルシューティング

Cisco SAN-OS ソフトウェアのインストールの状況確認

Cisco SAN-OS ソフトウェアのアップグレードとダウングレードのトラブルシューティング

ソフトウェアのインストールにおける非互換性の報告

互換性の問題の診断

インストール時のソフトウェアのエラーによる終了

Fabric Manager を使用した SAN-OS ソフトウェアのインストール

Cisco SAN-OS ソフトウェアの CLI からのインストール

Cisco SAN-OS ソフトウェアのシステム再起動のトラブルシューティング

電源投入時または再起動時におけるスイッチのハングアップ

破損したブートフラッシュの復旧

Supervisor 1 の BIOS 設定を使用した復旧

Supervisor 2 モジュールの loader> プロンプトからの復旧

supervisor 1 モジュールの loader> プロンプトからの復旧

switch(boot)# プロンプトからの復旧

デュアル スーパーバイザ モジュール搭載スイッチの復旧

1 つのスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧

両方のスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧

エラー状態の認識

スイッチまたはプロセスのリセット

回復可能なシステムの再起動

回復不能なシステムの再起動

管理パスワードの回復

ソフトウェア イメージのその他の問題

システム ヘルスのエラーによるすべてのポートのダウン

FCIP のリロード後のスイッチの再起動

FCIP リンクの開始の失敗

admin ロールの作成、変更、または削除が不可能

リンクのリセット後の FC ID の変更

スイッチが不正なユーザを表示

インストール、アップグレード、および再起動のトラブルシューティング

この章では、Cisco MDS 9000 ファミリ製品のインストール、アップグレード、または再起動の際に発生する可能性がある問題を識別して解決する方法について説明しています。

この章で説明する内容は、次のとおりです。

「概要」

「ベスト プラクティス」

「モジュールの中断のあるアップグレード」

「ファブリック スイッチにおける中断のないアップグレードでのトラブルシューティング」

「ファブリック スイッチにおける中断のないアップグレードでのトラブルシューティング」

「Cisco SAN-OS ソフトウェアのインストールの状況確認」

「Cisco SAN-OS ソフトウェアのアップグレードとダウングレードのトラブルシューティング」

「Cisco SAN-OS ソフトウェアのシステム再起動のトラブルシューティング」

「管理パスワードの回復」

「ソフトウェア イメージのその他の問題」

概要

各 Cisco MDS 9000 スイッチには、キックスタート イメージおよびシステム イメージの 2 つで構成されたオペレーティング システム(Cisco SAN-OS)が付属しています。また、Storage Services Module(SSM; ストレージ サービス モジュール)が取り付けられている場合は、モジュール イメージもあります。

インストール、アップグレード、および再起動は、SAN メンテナンス活動の一部分で継続的に実施されます。これらの操作を実稼働環境で実行する際に継続中の動作が中断されるリスクを最小限に抑え、また何らかの問題が発生したときに素早く復旧させる方法を確認しておくことが重要です。


) 文書化の目的で、このマニュアルでは「アップグレード」という用語を使用します。ただし、アップグレードは、ユーザのニーズにより、スイッチのアップグレードとダウングレードの両方を意味しています。


ベスト プラクティス

ここでは、Cisco SAN-OS ソフトウェアのインストール、イメージのアップグレードとダウングレード、および再起動のベスト プラクティスについて説明します。具体的な内容は、次のとおりです。

「インストールのベスト プラクティス」

「アップグレードのベスト プラクティス」

「再起動のベスト プラクティス」

インストールのベスト プラクティス

Cisco SAN-OS ソフトウェアのイメージをインストールする際は、ベスト プラクティスの次のガイドラインに従ってください。

サーバの可用性 ― FTP または TFTP サーバが利用できることを確認します。

CLI からの互換性チェック ― show install all impact CLI コマンドを使用して、新しいイメージが正常であること、および新規のロードがハードウェアの互換性に与える影響を確認します。互換性を調べてください。

Device Manager を使用した互換性チェック ― Device Manager で Admin > Show Image Version を選択し、MDS ファイル システムのディレクトリにあるイメージの情報を表示します。

アップグレードのベスト プラクティス

すべてのイメージをアップグレード中にアップデートする必要があるわけではありません。次のチェックリストを使用して、アップグレードの準備を行ってください。

 

チェックリスト
確認済み

新しい Cisco SAN-OS イメージを、bootflash: または slot0: にあるスーパーバイザ モジュールにコピーします。

 

実行コンフィギュレーションをスタートアップ コンフィギュレーションに保存します。

 

コンフィギュレーションのコピーをリモート TFTP サーバにバックアップします。

 

ファブリックに対するメンテナンスの適切な時間枠の中でアップグレードのスケジュールを確保します。

 

使用しているスーパーバイザ モジュールのタイプに合う正しいイメージを持っていることを確認します。

 

auto モードに設定されている SSM ポートがないことを確認します。

 

チェックリストの確認が終了すると、ファブリック内のスイッチをアップグレードする準備は完了です。


) アップグレード中にアクティブ スーパーバイザはスタンバイ スーパーバイザになりますが、これは正常な動作です。


Cisco SAN-OS ソフトウェアのイメージをアップグレードおよびダウングレードする際は、ベスト プラクティスの次のガイドラインに従ってください。

アップグレードまたはダウングレードするリリースに対応する『Cisco SAN-OS Release Notes』の内容を確認します。『 Cisco SAN-OS Release Notes 』は、次の Web サイトから入手できます。

http://cisco.com/en/US/products/ps5989/prod_release_notes_list.html

FTP または TFTP サーバが利用できることを確認します。

スタートアップ コンフィギュレーションを NVRAM 内のスナップショット コンフィギュレーションにコピーします。このステップでは、スタートアップ コンフィギュレーションのコピーをバックアップします。

Device Manager で、Admin > Copy Configuration を選択し、From: フィールドで startupConfig オプション ボタンを選択し、To: フィールドで serverFile オプション ボタンを選択します。その他のフィールドを設定して、Apply をクリックします。

CLI の場合は、copy nvram:startup-config nvram-snapshot-config コマンドを使用します。

可能であれば、中断のないアップグレードの実行を選択します。Release 2.x 以前の Cisco SAN-OS ソフトウェア リリースから Cisco SAN-OS Release 3.x へのアップグレードは、システムの中断なしで行うことができます。さらに古いバージョンの Cisco SAN-OS が稼働している場合は、いったん Release 2.x にアップグレードしてから、Release 3.x にアップグレードしてください。

各スーパーバイザ コンソールへの PC シリアル接続を確立して、アップグレードの作業をファイルに記録します。このシリアル接続で、起動時のすべてのエラー メッセージまたは問題を受け取ります。

Fabric Manager の場合は、Tools > Other > Software Install を選択するか、またはツールバーの Software Install アイコンをクリックして、Software Install Wizard を起動します。

CLI の場合は、 install all {asm-sfn | kickstart | ssi | system} URL コマンドを使用して、完了スクリプトの実行、イメージのテスト、およびハードウェアの互換性の確認を行います。詳細については、「Cisco SAN-OS ソフトウェアの CLI からのインストール」を参照してください。install all コマンドを使用すると、次の利点があります。

1 つのコマンドを使用するだけで、中断を最小限に抑えた手順を実行し、スイッチ全体をアップグレードできます。

コマンドを続行する前に、目的のシステム変更に関する説明情報を受け取れます。

コマンドを取り消すオプションがあります。コマンドの効果についての説明が表示されたあとに次の質問が表示されるので、続行または取り消しを選択できます(デフォルトは no)。

Do you want to continue (y/n) [n] :y
 

このコマンドの進捗状況は、コンソール、Telnet、および SSH の画面に表示できます。

稼働中のキックスタート イメージおよびシステム イメージを含むイメージの整合性は、自動的にチェックされます。

このコマンドでは、プラットフォームの妥当性検査を実行して、不正なイメージが使用されていないことを確認します。たとえば、MDS 9200 シリーズ スイッチのアップグレードに、誤って MDS 9500 シリーズのイメージが使用されていないことを確認します。

install all コマンドを発行したあとに、シーケンス内でいずれかのステップが失敗すると、コマンドは進行中のステップを完了してから終了します。

たとえば、何らかの理由でスイッチング モジュールのアップデートが失敗した場合(たとえば、ファブリックの状態が不安定なため)、コマンド シーケンスはそのモジュールのアップデートを途中まで行って終了します。このような場合は、影響を受けたスイッチング モジュールで発生している問題を確認してから、他のスイッチング モジュールをアップグレードできます。

write erase CLI コマンドを発行したあとでセットアップ スクリプトを実行した場合は、セットアップ スクリプトの完了後に VSAN 1 のデフォルト ゾーン ポリシーを設定する必要があります。Fabric Manager の場合は、Fabricxx > VSAN 1 > Default Zone を選択し、次に Policies タブを選択して Default Zone Behavior ドロップダウン メニューを permit または deny に設定します。CLI の場合は、zone default-zone コマンドを使用します。

再起動のベスト プラクティス

Cisco SAN-OS から実行できるシステム再起動には、次の 3 つの異なるタイプがあります。

回復可能 ― プロセスが再起動し、サービスには影響しません。

回復不能 ― プロセスの再起動回数が一定時間(秒)内に実行できる再起動の最大数を超えたために、プロセスの再起動を再実行できない場合に使用します。

システム停止またはクラッシュ ― システムとの通信が完全にできなくなった場合に使用します。

再起動のスケジュールは、重要な業務時間内にサービスが中断されないように設定してください。


) ログ メッセージは、システム再起動の全体にわたって保存されるものではありません。ただし、重大度が critical 以上(レベル 0、1、および 2)のログ メッセージは、最大 100 個まで NVRAM に保存されます。このログは、show logging nvram CLI コマンドを使用していつでも表示できます。


モジュールの中断のあるアップグレード

SSM、MPS-14/2 または IP Storage(IPS)サービス モジュールのソフトウェアに対しては、中断のあるアップグレードが行われます。これらのモジュールには、モジュールを順番にアップグレードするローリング アップグレードのインストール メカニズムが使用されます。モジュール内のすべてのアプリケーションを安定した状態にするために、最初のモジュールのアップグレード完了と次のモジュールのアップグレード開始の間には、Cisco SAN-OS によって遅延時間が設定されます。IPS モジュールの場合、安定状態を保証するには、次の IPS モジュールのアップグレード開始前に 5 分の遅延が必要です。

SSM では、レイヤ 1 およびレイヤ 2 プロトコルの中断のないアップグレードを、次の条件下でサポートしています。

SSM で稼働している Cisco SAN-OS Release 2.1(2) 以降を、それよりも新しいリリースにアップグレードする場合。

インストールされている Release 2.1(2) 用の EPLD(Erassable Programmable Logic Device)イメージを SSM ハードウェアが持っている場合。how version module <module number> epld CLI コマンドを使用して、EPLD のバージョンが 0x07 以降であることを確認してください。

レイヤ 3 サービスに対する Data Path Processor(DPP)のでプロビジョニングによって、SSM 上のすべてのレイヤ 3 サービスは無効になっています。

ファブリック スイッチにおける中断のないアップグレードでのトラブルシューティング

中断のないアップグレードが開始されると、アップグレードを開始しようとしているすべてのサービスを通知し、アップグレードを進めることができるかどうか調査します。このときにサービスがアップグレードを進めることができない場合(たとえば FSPF タイマーがデフォルト値に設定されていない場合、CFS 動作が進行中である場合など)、サービスのアップグレードが打ち切られます。そのような場合、show install all failure-reason コマンドを入力してアップグレードを進めることができない理由を識別します。

...
Do you want to continue with the installation (y/n)? [n] y
 
Install is in progress, please wait.
 
Notifying services about the upgrade.
[# ] 0% -- FAIL. Return code 0x401E0066 (request timed out).
 
Please issue "show install all failure-reason" to find the cause of the failure.<---show all failure-reason コマンドを入力するよう求めるプロンプトが表示される
 
Install has failed. Return code 0x401E0066 (request timed out).
Please identify the cause of the failure, and try 'install all' again.
 
switch# show install all failure-reason
Service: "cfs" failed to respond within the given time period.
switch#
 

何らかの理由(保存ランタイム状態障害やラインカード アップグレード障害など)による障害がある場合、アップグレードがすでに進行中であると、変更をロールバックできないため、アップグレードの途中でスイッチが再起動されます。そのような場合、アップグレードは失敗します。show install all failure-reason コマンドの入力は求められません。これを入力しても有益な情報は得られません。

アップグレードがうまくいかなかった理由を判別するのにサポートが必要な場合は、 show tech support コマンド出力から詳細を収集し、可能であればインストールからコンソール出力を収集します。

Fabric Manager のインストールのトラブルシューティング

ここでは、Fabric Manager のインストールが失敗した場合に考えられる原因とその解決方法について説明します。Fabric Manager では、Fabric Manager のリリースに適したバージョンの Sun JAVA JRE がインストールされている必要があります。 表2-1 に、Fabric Manager 2.x リリースの推奨 JRE を示します。

 

表2-1 Fabric Manager および推奨される JRE バージョン

Fabric Manager のリリース
推奨される JRE バージョン

2.0(1b) ~ 2.1(1b)

1.4.2_05

2.1(2) 以降

1.5.0

Windows 2003 では、JRE 1.4.2_03 を使用すると、Fabric Manager および Device Manager は正常に動作しません。

現象 Fabric Manager または Device Manager が起動しない。

 

表2-2 Fabric Manager または Device Manager が起動不能

現象
考えられる原因
解決方法

Device Manager が起動しない。

Device Manager で、Fabric Manager Server 経由のプロキシが設定されている。

Device Manager startup ダイアログボックスで Proxy SNMP through FM Server チェックボックスをオフにし、Device Manager を再起動します。

Fabric Manager が起動しない。

不正な Fabric Manager Server を使用している。

FMServer プルダウン メニューで適切な Fabric Manager Server を選択していることを確認します。Fabric Manager Server をまだ選択していない場合は、Fabric Manager Server をダウンロードしてください。

Fabric Manager Server が稼働していない。

Windows PC 上で、スタート > コントロール パネル > 管理ツール > サービス をクリックし、Fabric Manager Server および Fabric Manager Database が開始されていることを確認します。デフォルト設定では、Fabric Manager Server サービスは、PC を再起動するときに自動的に開始されます。

互換性がないバージョンの JRE が使用されている。

インストールした Fabric Manager のリリースに対して、正しいバージョンの JRE がインストールされていることを確認します。インストールしたソフトウェア バージョンに対応するリリース ノートを参照して、どのバージョンの JRE と互換性があるかを確認してください。

Fabric Manager が正しくインストールされていない。

問題が解消しない場合は、Cisco MDS 9000の Uninstall プログラムを使用してアプリケーションをいったん削除してから、Fabric Manager を再インストールします。

Cisco SAN-OS ソフトウェアのインストールの状況確認

Fabric Manager では、Software Install Wizard を使用して、ソフトウェアのインストールの進捗状況を監視できます。CLI では、show install all status コマンドを使用して、ソフトウェアのインストールの進捗状況を監視できます。

また、show install all status CLI コマンドを使用すると、実行中の install all コマンドまたは最後に install all コマンドが実行されたときのログを、コンソール、SSH、または Telnet セッションから表示できます。

このコマンドでは、コンソール端末に接続していない場合でも、install all コマンドの出力がアクティブ スーパーバイザ モジュールおよびスタンバイ スーパーバイザ モジュールの両方に提供されます。ここでは、CLI(GUI ではなく)から発行された install all コマンドのステータスだけを表示します。例2-1 を参照してください。

例2-1 install all コマンドの出力

switch# show install all status
There is an on-going installation... <---------------------- 実行中のインストール
Enter Ctrl-C to go back to the prompt.
Verifying image bootflash:/b-1.3.0.104
-- SUCCESS
Verifying image bootflash:/i-1.3.0.104
-- SUCCESS
Extracting “system” version from image bootflash:/i-1.3.0.104.
-- SUCCESS
Extracting “kickstart” version from image bootflash:/b-1.3.0.104.
-- SUCCESS
Extracting “loader” version from image bootflash:/b-1.3.0.104.
-- SUCCESS
switch# show install all status
This is the log of last installation. <----------------- 最後に実行されたインストールのログ
Verifying image bootflash:/b-1.3.0.104
-- SUCCESS
Verifying image bootflash:/i-1.3.0.104
-- SUCCESS
Extracting “system” version from image bootflash:/i-1.3.0.104.
-- SUCCESS
Extracting “kickstart” version from image bootflash:/b-1.3.0.104.
-- SUCCESS
Extracting “loader” version from image bootflash:/b-1.3.0.104.
-- SUCCESS
 

Cisco SAN-OS ソフトウェアのアップグレードとダウングレードのトラブルシューティング

ここでは、ソフトウェアのインストレーションに対するアップグレードまたはダウングレードが失敗した場合に考えられる原因とその解決方法について説明します。発生する症状は、次のとおりです。

「ソフトウェアのインストールにおける非互換性の報告」

「インストール時のソフトウェアのエラーによる終了」

ソフトウェアのインストールにおける非互換性の報告

現象 ソフトウェアのインストールで非互換性が報告される。

 

表2-3 ソフトウェアのインストールにおける非互換性の報告

現象
考えられる原因
解決方法

ソフトウェアのインストールで非互換性が報告される。

稼働中のイメージでイネーブルにされている機能は提供された新しいイメージと互換性がない。

Fabric Manager Software Install Wizard または install all CLI コマンドのいずれかで、非互換性の問題を再調査します。問題点を修正して、インストールを再実行します。詳細については、「互換性の問題の診断」を参照してください。

スイッチ上でどの機能がイネーブルになっているかを確認し、新しいイメージと互換性がないと考えられる機能をすべてディセーブルにします。両方のイメージの適切なリリース ノートを参照してください。

互換性の問題の診断

動的な互換性チェックの結果を表示するには、show incompatibility system bootflash:filename CLI コマンドを使用します。

install all CLI コマンドにより互換性の問題が報告されたときは、show incompatibility CLI コマンドを使用して診断を行います。

アップグレードを試行中の場合は、install all CLI コマンドが次の警告を返すことがあります。

Warning: The startup config contains commands not supported by the system image; as a result, some resources might become unavailable after an install.
Do you wish to continue? (y/ n) [y]: n
 

show incompatibility CLI コマンドを使用して問題を特定します。

メッセージ 1 では、使用中のリモート SPAN(RSPAN)機能が、インストールされたイメージではサポートされていないことを示しています。この非互換性は重大な問題であり、アップグレードを続行するとスイッチが不整合な状態になる可能性があるため、設定された機能が動作を停止することがあります。

switch# show incompatibility system bootflash:new-image
The following configurations on active are incompatible with the system image
1) Feature Index : 67 , Capability : CAP_FEATURE_SPAN_FC_TUNNEL_CFG
Description : SPAN - Remote SPAN feature using fc-tunnels
Capability requirement : STRICT
 

メッセージ 2 では、新しいイメージでファイバ チャネル トンネル機能がサポートされていないことを示しています。RSPAN 機能では、ファイバ チャネル トンネルが使用されます。

2) Feature Index : 119 , Capability : CAP_FEATURE_FC_TUNNEL_CFG
Description : fc-tunnel is enabled
Capability requirement : STRICT
 

インストール時のソフトウェアのエラーによる終了

現象 ソフトウェアのインストールが、エラーにより終了する。

 

表2-4 ソフトウェアのインストールがエラーにより終了

問題
考えられる原因
解決方法

ソフトウェアのインストールがエラーにより終了する。

スタンバイ スーパーバイザ モジュールの bootflash: ファイルシステムに、更新されたイメージを格納する十分な領域がない。

不要なファイルをファイルシステムから削除します。Device Manager の場合は、Admin > Flash Files を選択します。CLI の場合は、delete コマンドを使用します。

指定されたシステム イメージとキックスタート イメージの間に互換性がない。

インストール プロセスの出力を調べて、非互換性の詳細について確認します。システム イメージをアップデートする前に、キックスタート イメージをアップデートしている可能性があります。

install all コマンドが、スタンバイ スーパーバイザ モジュール上で発行された。

このコマンドをアクティブ スーパーバイザ モジュールだけで発行するようにします。

アップグレードの進行中にモジュールが装着された。

インストールを再実行します。詳細については、「Fabric Manager を使用した SAN-OS ソフトウェアのインストール」および「Cisco SAN-OS ソフトウェアの CLI からのインストール」を参照してください。

アップグレードの進行中にファブリックまたはスイッチの設定が行われた。

アップグレードが完了するのを待ってから、スイッチを設定します。Device Manager で Admin > CFS を選択、または CLI で show cfs lock コマンドを使用して、実行中の CFS コミット操作がないことを確認します。

アップグレードの進行中にスイッチの電源が停止した。

インストールを再実行します。詳細については、「Fabric Manager を使用した SAN-OS ソフトウェアのインストール」および「Cisco SAN-OS ソフトウェアの CLI からのインストール」を参照してください。

ソフトウェア イメージの指定されたパスが正しくない。

リモート ロケーションへのパス全体を正しく指定します。

別のインストール プロセスがすでに進行中である。

すべてのステージでスイッチの状態を確認し、10 秒間待機してからインストールを再び実行します。10 秒経過する前にインストール プロセスを再実行すると、コマンドは拒否され、インストールが現在進行していることを示すエラー メッセージが表示されます。

モジュールがアップグレードに失敗した。

インストールを再実行します。詳細については、「Fabric Manager を使用した SAN-OS ソフトウェアのインストール」および「Cisco SAN-OS ソフトウェアの CLI からのインストール」を参照してください。

または、install module CLI コマンドを使用して失敗したモジュールをアップグレードします。

Fabric Manager を使用した SAN-OS ソフトウェアのインストール

Fabric Manager で Software Install Wizard を使用して新しいソフトウェア イメージをインストールする手順は、次のとおりです。


ステップ 1 ツールバーのアイコンをクリックして、Software Install Wizard を開きます(図2-1を参照)。

図2-1 [Software Install Wizard] アイコン

 

Software Install Wizard が表示されます。

ステップ 2 イメージをインストールするスイッチを選択します。処理を進めるには、スイッチを 1 つまたは複数選択する必要があります。 Next をクリックします。

ステップ 3 (任意) Skip Image Download チェックボックスをオンにして、Next をクリックし、ダウンロード済みのイメージを使用します(ダウンロードされたファイルは bootflash: ファイル システム上にあります)。ステップ 7 へ進みます。

ステップ 4 System、Kickstart、Asm-sfn、または ssi カラムの行をクリックして、イメージの URI を入力します。処理を進めるには、スイッチごとに少なくとも 1 つのイメージを指定する必要があります。

ステップ 5 新規イメージ用に十分な空き容量があるかどうかについて、各スイッチにあるアクティブ(および該当する場合はスタンバイ)bootflash: ファイル システムをチェックします。この情報は Flash Space カラムに表示されます。

この画面は、各スイッチにアクティブ(および該当する場合はスタンバイ)bootflash: 用のメモリ領域が十分あり、ステータス(新規イメージ用の十分な領域があるかどうか)を示しています。いずれかのスイッチで十分な領域がない場合、インストールを進めることはできません。最初の画面に戻り、十分な bootflash: メモリ領域がないスイッチに対応するチェックボックスをオフにして、そのスイッチの選択を解除します。

ステップ 6 Next をクリックします。Select Download Image 画面が表示されます。

ステップ 7 System、Kickstart、Asm-sfn、または ssi のテーブル セルをダブルクリックして、各スイッチの bootflash: ファイル システムで使用できるイメージのドロップダウン リストから選択します。処理を進めるには、スイッチごとにイメージを 1 つまたは複数選択する必要があります。


) アップグレードできるスイッチ数に制限はありません。ただし、アップグレードは順次実行されるプロセスであるため、一度にアップグレードされるスイッチは 1 つだけです。


ステップ 8 Next をクリックします。最終確認の画面が表示されます。

ステップ 9 インストールを開始する場合は、Finish をクリックします。新しいイメージをインストールしないでインストール ウィザードを終了する場合は、Cancel をクリックします。


) Trivial File Transfer Protocol(TFTP; 簡易ファイル転送プロトコル)サーバを開始できないホストの場合は、警告が表示されます。既存の TFTP サーバが稼働しているか、または TFTP ポート 69 へのアクセスがセキュリティ上の理由から拒否されている場合(Linux のデフォルト設定)は、TFTP サーバを開始できないことがあります。このような場合は、ファイルをローカル ホストからスイッチに転送できません。



) セッションを終了する前に、アップグレード プロセスが完了していることを確認してください。アップグレードの進行に合わせて、ウィザードにはステータス メッセージが表示されます。ウィザードの左下にステータス メッセージが表示されていることを確認してください。ウィザードには最初にメッセージ Success が表示され、数秒後に InProgress Polling が表示されます。続いて 2 番めのメッセージ Success が表示され、その後 Upgrade Finished が表示されます。



 

Cisco SAN-OS ソフトウェアの CLI からのインストール

スイッチ上のソフトウェアの自動アップグレードを CLI から実行する手順は次のとおりです。


ステップ 1 アクティブ スーパーバイザのコンソール、Telnet、または SSH ポートからスイッチにログインします。

ステップ 2 必要であれば、既存のコンフィギュレーション ファイルのバックアップを作成します。

ステップ 3 install all コマンドを発行して、アップグレードを実行します。

次の例では、SCP サーバにあるソース イメージを使用して、 install all コマンドで SAN-OS 2.0(2b) を 2.1(1a) にアップグレードします。


ヒント 常に、install all コマンドの互換性チェックの出力内容を慎重に確認してください。この互換性チェックでは、アップグレードが必要な対象(BIOS、ローダ、ファームウェア)および中断のないアップグレードに対応していないモジュールが正確に示されます。出力の結果に対して何らかの疑問や懸念がある場合は、n を選択してインストールを停止し、次のレベルのサポートに連絡してください。

ca-9506# install all system scp://testuser@dino/tftpboot/rel/qa/2_1_1a/final/m95
00-sf1ek9-mz.2.1.1a.bin kickstart scp://testuser@dino/tftpboot/rel/qa/2_1_1a/fin
al/m9500-sf1ek9-kickstart-mz.2.1.1a.bin
For scp://testuser@dino, please enter password:
For scp://testuser@dino, please enter password:
 
Copying image from scp://testuser@dino/tftpboot/rel/qa/2_1_1a/final/m9500-sf1ek9
-kickstart-mz.2.1.1a.bin to bootflash:///m9500-sf1ek9-kickstart-mz.2.1.1a.bin.
[####################] 100% -- SUCCESS
 
Copying image from scp://testuser@dino/tftpboot/rel/qa/2_1_1a/final/m9500-sf1ek9
-mz.2.1.1a.bin to bootflash:///m9500-sf1ek9-mz.2.1.1a.bin.
[####################] 100% -- SUCCESS
 
Verifying image bootflash:///m9500-sf1ek9-kickstart-mz.2.1.1a.bin
[####################] 100% -- SUCCESS
 
Verifying image bootflash:///m9500-sf1ek9-mz.2.1.1a.bin
[####################] 100% -- SUCCESS
 
Extracting "slc" version from image bootflash:///m9500-sf1ek9-mz.2.1.1a.bin.
[####################] 100% -- SUCCESS
 
Extracting "ips" version from image bootflash:///m9500-sf1ek9-mz.2.1.1a.bin.
[####################] 100% -- SUCCESS
 
Extracting "svclc" version from image bootflash:///m9500-sf1ek9-mz.2.1.1a.bin.
[####################] 100% -- SUCCESS
 
Extracting "system" version from image bootflash:///m9500-sf1ek9-mz.2.1.1a.bin.
[####################] 100% -- SUCCESS
 
Extracting "kickstart" version from image bootflash:///m9500-sf1ek9-kickstart-mz
.2.1.1a.bin.
[####################] 100% -- SUCCESS
 
Extracting "loader" version from image bootflash:///m9500-sf1ek9-kickstart-mz.2.
1.1a.bin.
[####################] 100% -- SUCCESS
 
 
 
Compatibility check is done:
Module bootable Impact Install-type Reason
------ -------- -------------- ------------ ------
1 yes non-disruptive rolling
2 yes non-disruptive rolling
3 yes disruptive rolling Hitless upgrade is not supported
4 yes disruptive rolling Hitless upgrade is not supported
5 yes non-disruptive reset
6 yes non-disruptive reset
 
 
 
Images will be upgraded according to following table:
Module Image Running-Version New-Version Upg-Required
------ ---------- -------------------- -------------------- ------------
1 slc 2.0(2b) 2.1(1a) yes
1 bios v1.1.0(10/24/03) v1.1.0(10/24/03) no
2 slc 2.0(2b) 2.1(1a) yes
2 bios v1.1.0(10/24/03) v1.1.0(10/24/03) no
3 ips 2.0(2b) 2.1(1a) yes
3 bios v1.1.0(10/24/03) v1.1.0(10/24/03) no
4 svclc 2.0(2b) 2.1(1a) yes
4 svcsb 1.3(5m) 1.3(5m) no
4 svcsb 1.3(5m) 1.3(5m) no
4 bios v1.1.0(10/24/03) v1.1.0(10/24/03) no
5 system 2.0(2b) 2.1(1a) yes
5 kickstart 2.0(2b) 2.1(1a) yes
5 bios v1.1.0(10/24/03) v1.1.0(10/24/03) no
5 loader 1.2(2) 1.2(2) no
6 system 2.0(2b) 2.1(1a) yes
6 kickstart 2.0(2b) 2.1(1a) yes
6 bios v1.1.0(10/24/03) v1.1.0(10/24/03) no
6 loader 1.2(2) 1.2(2) no
 
Do you want to continue with the installation (y/n)? [n] y
 
Install is in progress, please wait.
 
Syncing image bootflash:///m9500-sf1ek9-kickstart-mz.2.1.1a.bin to standby.
[####################] 100% -- SUCCESS
 
Syncing image bootflash:///m9500-sf1ek9-mz.2.1.1a.bin to standby.
[####################] 100% -- SUCCESS
 
Setting boot variables.
[####################] 100% -- SUCCESS
 
Performing configuration copy.
[####################] 100% -- SUCCESS
 
Module 5: Waiting for module online.
2005 May 20 15:46:03 ca-9506 %KERN-2-SYSTEM_MSG: mts: HA communication with standby terminated. Please check the standby supervisor.
-- SUCCESS
 
"Switching over onto standby".
 

ステップ 4 スイッチのコンソールを終了し、新規のターミナル セッションを開き、 show module コマンドを使用してアップグレードされたスーパーバイザ モジュールを表示します。

install all コマンドが発行されたときに、コンフィギュレーションがすべてのガイドラインに適合していれば、すべてのモジュール(スーパーバイザおよびスイッチング)がアップグレードされます。


 

Cisco SAN-OS ソフトウェアのシステム再起動のトラブルシューティング

ここでは、ソフトウェアの再起動に関して考えられる問題とその解決方法について説明します。具体的な内容は、次のとおりです。

「電源投入時または再起動時におけるスイッチのハングアップ」

「破損したブートフラッシュの復旧」

「Supervisor 1 の BIOS 設定を使用した復旧」

「Supervisor 2 モジュールの loader> プロンプトからの復旧」

「supervisor 1 モジュールの loader> プロンプトからの復旧」

「switch(boot)# プロンプトからの復旧」

「デュアル スーパーバイザ モジュール搭載スイッチの復旧」

「エラー状態の認識」

電源投入時または再起動時におけるスイッチのハングアップ

現象 電源投入時または再起動時にスイッチがハングアップする。

 

表2-5 電源投入時または再起動時におけるスイッチのハングアップ

問題
考えられる原因
解決方法

デュアル スーパーバイザ構成で、電源投入時または再起動時にスイッチがハングアップする。

ブートフラッシュが破損している。

詳細については、「デュアル スーパーバイザ モジュール搭載スイッチの復旧」を参照してください。

シングル スーパーバイザ構成で、電源投入時または再起動時にスイッチがハングアップする。

ローダが破損している。

起動プロセスを中断し、コンソール ポートから BIOS を再設定して、BIOS イメージをアップデートする新しいキックスタート イメージをロードします。詳細については、「Supervisor 1 の BIOS 設定を使用した復旧」を参照してください。

BIOS が破損している。

このモジュールを交換します。カスタマー サポート担当者に連絡して、故障したモジュールを返却してください。

キックスタート イメージが破損している。

>loader プロンプトで、起動プロセスを中断します。キックスタート イメージをアップデートします。詳細については、「Supervisor 2 モジュールの loader> プロンプトからの復旧」を参照してください。

起動パラメータが不正である。

起動パラメータを確認して修正し、スイッチを再起動します。

システム イメージが破損している。

switch#boot プロンプトで、起動プロセスを中断します。システム イメージをアップデートします。詳細については、「switch(boot)# プロンプトからの復旧」を参照してください。

破損したブートフラッシュの復旧

すべてのスイッチ コンフィギュレーションは、内蔵ブートフラッシュに格納されています。内蔵ブートフラッシュが破損すると、場合によってはコンフィギュレーションが失われることがあります。コンフィギュレーション ファイルを、定期的に保存およびバックアップしてください。通常、スイッチの起動は、次のシーケンスで行われます(図2-2 を参照)。

1. BIOS によって、ローダがロードされます。

2. ローダでは、キックスタート イメージを RAM にロードして起動します。

3. キックスタート イメージでは、システム イメージをロードして起動します。

4. システム イメージでは、スタートアップ コンフィギュレーション ファイルを読み込みます。

図2-2 通常の起動シーケンス

 

スイッチ上のイメージが破損しているために先に進めない場合は(エラー状態)、スイッチの起動シーケンスを中断して次の項で説明されている BIOS 設定ユーティリティに入ることにより、イメージを復旧できます。このユーティリティには、破損した内蔵ディスクを復旧する必要がある場合にだけアクセスしてください。


注意 ここで説明されている BIOS 設定の変更は、破損したブートフラッシュを復旧する場合にだけ必要になります。

復旧の手順では、通常のシーケンスを中断する必要があります。スイッチの内部シーケンスでは、スイッチの電源を投入してから端末に switch プロンプトが表示されるまでの間に、BIOS、ブート ローダ、キックスタート、およびシステムの 4 つのフェーズがあります( 表2-6 および図2-3 を参照)。

 

表2-6 復旧の割り込み

フェーズ
通常のプロンプト 1
復旧用のプロンプト 2
説明

BIOS

loader>

No bootable device

BIOS によって、電源投入時自己診断テスト、メモリ テスト、および他のオペレーティング システム アプリケーションが開始されます。BIOS 設定ユーティリティでネットブート オプションを使用するには、テストの進行中に Ctrl+C キーを押します。

ブート ローダ

Starting kickstart

loader>

ブート ローダでは、ロードされたソフトウェアの圧縮を解除し、そのファイル名を参照先として使用することでイメージを起動します。これらのイメージは、ブートフラッシュから起動できます。メモリ テストが完了したあとは、 Esc キーを押してブート ローダのプロンプトを開始します。

Kickstart

Uncompressing system

switch(boot)#

ブート ローダのフェーズが完了したあとは、 Ctrl+] 3 キーを押して(Ctrl キーと右角カッコ キーを同時に押す)、 switch(boot)# プロンプトを表示します。破損が原因でコンソールをこのプロンプトで停止させる場合は、システム イメージをコピーしてからスイッチを再起動します。

System

Login:

--

システム イメージでは、最後に保存された実行コンフィギュレーションのコンフィギュレーション ファイルをロードし、スイッチのログイン プロンプトに戻ります。

1.このプロンプトまたはメッセージは、各フェーズの最後に表示されます。

2.このプロンプトまたはメッセージは、スイッチが次のフェーズに進めないときに表示されます。

3.Telnet クライアントによっては、これらのキーが予約されていることがあるので、その場合はキーの割り当てを変更する必要があります。詳細については、Telnet クライアントに付属のマニュアルを参照してください。

図2-3 通常および復旧のシーケンス

 

Supervisor 1 の BIOS 設定を使用した復旧


) Supervisor 2 モジュールは BIOS へのアクセスを提供していません。



注意 この手順では、init system コマンドを使用しており、デバイスのファイル システムを再フォーマットします。この手順を開始する前にコンフィギュレーション ファイルのバックアップを作成しておいてください。

シングル Supervisor 1 モジュール搭載スイッチで、破損した bootflash: デバイス( no bootable device found メッセージ)を復旧する手順は、次のとおりです。


ステップ 1 目的のスイッチのコンソール ポートに接続します。

ステップ 2 スイッチを起動または再起動します。

ステップ 3 BIOS メモリ テスト中に Ctrl+C キーを押して、BIOS 設定を中断します。

ネットブート BIOS 設定ユーティリティの画面が表示されます(図2-4 を参照)。

図2-4 BIOS 設定ユーティリティ

 


) ナビゲート用のオプションは、画面の下部に表示されます。
Tab = 次の行に移動
Ctrl-E = 下方向矢印
Ctrl-X = 上方向矢印
Ctrl-H = 消去(端末を適切に設定していない場合、バックスペースが機能しない場合があります。)


ステップ 4 Tab キーを押し、Basic CMOS Configuration を選択します。

System BIOS Setup - Basic CMOS Configuration 画面が表示されます(図2-5 を参照)。

図2-5 System BIOS Setup - Basic CMOS Configuration 画面

 

ステップ 5 Boot 1st: フィールドを TFTP に変更します。

ステップ 6 Tab キーを必要な回数だけ押し、Local IP Address フィールドに移動します。

ステップ 7 スイッチのローカル IP アドレスを入力し、 Tab キーを押します。

ステップ 8 IP アドレスに対応するサブネット マスクを入力し、 Tab キーを押します。

ステップ 9 デフォルト ゲートウェイの IP アドレスを入力し、 Tab キーを押します。

ステップ 10 TFTP サーバの IP アドレスを入力し、 Tab キーを押します。

ステップ 11 イメージの名前(kickstart)を入力し、 Tab キーを押します。TFTP サーバのルート ディレクトリからのフル パスを使用してください。


注意 ファイル名には、TFTP サーバに表示されている名前をそのまま入力する必要があります。たとえば、MDS9500-kiskstart_mzg.10 という名前のファイルがある場合は、TFTP サーバ上に表示されている名前と同じになるように、大文字の区別および拡張子も含めて正確に入力します。

変更した設定が表示されます(図2-6 を参照)。

図2-6 設定変更後の System BIOS Setup - Basic CMOS Configuration 画面

 

ステップ 12 Esc キーを押して、メイン メニューの画面に戻ります。

ステップ 13 メイン メニューの画面で Write to CMOS and Exit を選択して、変更を保存します。


) これらの変更は、CMOS に保存されます。



注意 新しく設定された値を使用してスイッチを再起動するには、IP 接続が必要です。

次のプロンプトが表示されます。

switch(boot)#
 

ステップ 14 switch(boot)# プロンプトで init system コマンドを入力し、Enter キーを押してファイル システムを再フォーマットします。

switch(boot)# init system
 

) また、init system コマンドでは、既存(稼働中)のキックスタート イメージから新しいローダをインストールします。



注意 このコマンドを発行する前にコンフィギュレーション ファイルのバックアップを作成しておいてください。

ステップ 15 「switch(boot)# プロンプトからの復旧」 で指示されている手順を実行します。


 

Supervisor 2 モジュールの loader> プロンプトからの復旧


注意 この手順では、init system コマンドを使用しており、デバイスのファイル システムを再フォーマットします。この手順を開始する前にコンフィギュレーション ファイルのバックアップを作成しておいてください。


loader> プロンプトは、通常の switch# プロンプトとは異なります。このプロンプトでは、CLI のコマンド補完機能は機能せず、不要なエラーの原因になることがあります。コマンドは、その全体を正確に入力する必要があります。



ヒント loader> プロンプトで使用できるコマンドのリストを表示したり、そのリストにある特定のコマンドに関する詳細な情報を取得したりするには、このプロンプトで help コマンドを実行してください。


シングル スーパーバイザ モジュール搭載スイッチで、破損したキックスタート イメージ(システム エラー状態)を復旧する手順は、次のとおりです。


ステップ 1 loader> プロンプトでスイッチのローカル IP アドレスを入力し、Enter キーを押します。

loader> net --ip=172.16.1.2
 

ステップ 2 サブネット マスクを指定します。

loader> net --nm= 255.255.255.0
 

ステップ 3 デフォルト ゲートウェイの IP アドレスを指定します。

loader> net --gw=172.16.1.1
 

ステップ 4 目的のサーバからキックスタート イメージ ファイルを起動します。

loader> boot tftp://172.16.10.100/m9500-kickstart-3.0.bin
 

この例では、 172.16.10.100 が TFTP サーバの IP アドレスで、 m9500-kickstart-3.0.bin がそのサーバに存在するキックスタート イメージ ファイル名です。

switch(boot)# プロンプトは、使用可能なキックスタート イメージがあることを示すものです。

ステップ 5 switch(boot)# プロンプトで、 init system コマンドを発行します。

switch(boot)# init system
 

注意 このコマンドを発行する前にコンフィギュレーション ファイルのバックアップを作成しておいてください。

ステップ 6 「switch(boot)# プロンプトからの復旧」 で指示されている手順を実行します。


 

supervisor 1 モジュールの loader> プロンプトからの復旧


注意 この手順では、init system コマンドを使用しており、デバイスのファイル システムを再フォーマットします。この手順を開始する前にコンフィギュレーション ファイルのバックアップを作成しておいてください。


loader> プロンプトは、通常の switch# プロンプトまたは switch(boot)# プロンプトとは異なります。このプロンプトでは、CLI のコマンド補完機能は機能せず、不要なエラーの原因になることがあります。コマンドは、その全体を正確に入力する必要があります。



ヒント loader> プロンプトで使用できるコマンドのリストを表示したり、そのリストにある特定のコマンドに関する詳細な情報を取得したりするには、このプロンプトで help コマンドを実行してください。


シングル スーパーバイザ モジュール搭載スイッチで、破損したキックスタート イメージ(システム エラー状態)を復旧する手順は、次のとおりです。


ステップ 1 loader> プロンプトでスイッチの IP アドレスおよびサブネット マスクを入力し、Enter キーを押します。

loader> ip address 172.16.1.2 255.255.255.0
Found Intel EtherExpressPro100 82559ER at 0xe800, ROM address 0xc000
Probing...[Intel EtherExpressPro100 82559ER]Ethernet addr: 00:05:30:00:52:27
Address: 172.16.1.2
Netmask: 255.255.255.0
Server: 0.0.0.0
Gateway: 0.0.0.0
 

ステップ 2 デフォルト ゲートウェイの IP アドレスを指定します。

loader> ip default-gateway 172.16.1.1
Address: 172.16.1.2
Netmask: 255.255.255.0
Server: 0.0.0.0
Gateway: 172.16.1.1
 

ステップ 3 目的のサーバからキックスタート イメージ ファイルを起動します。

loader> boot tftp://172.16.10.100/kickstart-image1
Address: 172.16.1.2
Netmask: 255.255.255.0
Server: 172.16.10.100
Gateway: 172.16.1.1
Booting: /kick-282 console=ttyS0,9600n8nn quiet loader_ver= “2.1(2)”....
............................................Image verification OK
Starting kernel...
INIT: version 2.78 booting
Checking all filesystems..... done.
Loading system software
INIT: Sending processes the TERM signal
Sending all processes the TERM signal... done.
Sending all processes the KILL signal... done.
Entering single-user mode...
INIT: Going single user
INIT: Sending processes the TERM signal
switch(boot)#
 

switch(boot)# プロンプトは、使用可能なキックスタート イメージがあることを示すものです。

ステップ 4 switch(boot)# プロンプトで、 init system コマンドを発行します。

switch(boot)# init system
 

注意 このコマンドを発行する前にコンフィギュレーション ファイルのバックアップを作成しておいてください。

ステップ 5 「switch(boot)# プロンプトからの復旧」 で指示されている手順を実行します。


 

switch(boot)# プロンプトからの復旧

シングル スーパーバイザ モジュール搭載スイッチで、キックスタート イメージを使用してシステム イメージを復旧する手順は次のとおりです。


ステップ 1 設定モードへ移行し、mgmt0 インターフェイスの IP アドレスを設定します。

switch(boot)# config t
switch(boot)(config)# interface mgmt0
 

ステップ 2 init system コマンドを発行した場合は、このステップの手順に従います。それ以外の場合は、ステップ 3 に進みます。

a. ip address コマンドを発行して、スイッチのローカル IP アドレスおよびサブネット マスクを設定します。

switch(boot)(config-mgmt0)# ip address 172.16.1.2 255.255.255.0
 

b. ip default-gateway コマンドを発行して、デフォルト ゲートウェイの IP アドレスを設定します。

switch(boot)(config-mgmt0)# ip default-gateway 172.16.1.1
 

ステップ 3 no shutdown コマンドを発行して、スイッチ上の mgmt0 インターフェイスをイネーブルにします。

switch(boot)(config-mgmt0)# no shutdown
 

ステップ 4 end と入力して、EXEC モードに移行します。

switch(boot)(config-mgmt0)# end
 

ステップ 5 ファイル システムに問題があると考えられる場合は、 init system check-filesystem コマンドを発行します。Cisco MDS SAN-OS Release 2.1(1a) 以降では、このコマンドはすべての内部ファイルシステムを調べて、発見されたエラーをすべて修復します。このコマンドは、完了するまでかなりの時間がかかります。

switch(boot)# init system check-filesytem
 

ステップ 6 目的の TFTP サーバからシステム イメージをコピーします。

switch(boot)# copy tftp://172.16.10.100/system-image1 bootflash:system-image1
 

ステップ 7 目的の TFTP サーバからキックスタート イメージをコピーします。

switch(boot)# copy tftp://172.16.10.100/kickstart-image1 bootflash:kickstart-image1
 

ステップ 8 システム イメージ ファイルおよびキックスタート イメージ ファイルが bootflash: ファイル システムにコピーされたことを確認します。

switch(boot)# dir bootflash:
12456448 Jul 30 23:05:28 1980 kickstart-image1
12288 Jun 23 14:58:44 1980 lost+found/
27602159 Jul 30 23:05:16 1980 system-image1
 
Usage for bootflash://sup-local
135404544 bytes used
49155072 bytes free
184559616 bytes total
 

ステップ 9 システム イメージを bootflash: ファイル システムからロードします。

switch(boot)# load bootflash:system-image1
Uncompressing system image: bootflash:/system-image1
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
 
Would you like to enter the initial configuration mode? (yes/no): yes
 

no を入力した場合は、switch# ログイン プロンプトに戻るので、スイッチを手動で設定する必要があります。



 

デュアル スーパーバイザ モジュール搭載スイッチの復旧

ここでは、デュアル スーパーバイザ モジュール搭載スイッチの 1 つ または両方のスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧手順について説明します。

1 つのスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧

1 つのスーパーバイザ モジュールではブートフラッシュが機能し、またもう 1 つのスーパーバイザ モジュールではブートフラッシュが破損している場合の復旧手順は、次のとおりです。


ステップ 1 機能しているスーパーバイザ モジュールを起動し、スイッチにログインします。

ステップ 2 起動したスーパーバイザ モジュールの switch# プロンプトで、 reload module slot force-dnld コマンドを発行します。 slot は、破損したブートフラッシュがあるスーパーバイザ モジュールのスロット番号です。

破損したブートフラッシュがあるスーパーバイザ モジュールでは、ネットブートを実行し、ブートフラッシュの破損をチェックします。起動スクリプトによってブートフラッシュの破損が検出されると、スクリプトは、破損したブートフラッシュを修復する init system コマンドを生成します。スーパーバイザ モジュールは、HA Standby 状態で起動します。


注意 システムでアクティブ スーパーバイザ モジュールが正常に稼働している場合は、内蔵 bootflash: が破損するのを防止するために、スタンバイ スーパーバイザ モジュール上で init system コマンドを発行する前に、アクティブ スーパーバイザ モジュール上で system standby manual-boot コマンドを EXEC モードで発行する必要があります。スタンバイ スーパーバイザ モジュール上で init system コマンドが完了したあとは、アクティブ スーパーバイザ モジュール上で system no standby manual-boot コマンドを EXEC モードで発行します。


 

両方のスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧

両方のスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧手順は、次のとおりです。


ステップ 1 両方のスイッチを起動し、BIOS メモリ テストの完了後に Esc キーを押して、ブート ローダを中断します。


) 以下のメッセージが表示されたらすぐにEsc キーを押してください。
00000589K Low Memory Passed
00000000K Ext Memory Passed
Hit ^C if you want to run SETUP....
Wait.....
待機時間が長くなるようであれば、ブート ローダ フェーズを省略してキックスタート フェーズに入ります。


loader> プロンプトが表示されます。


注意 loader> プロンプトは、通常の switch# プロンプトまたは switch(boot)# プロンプトとは異なります。このプロンプトでは、CLI のコマンド補完機能は機能せず、不要なエラーの原因になることがあります。コマンドは、その全体を正確に入力する必要があります。

ヒント loader> プロンプトで使用できるコマンドのリストを表示したり、そのリストにある特定のコマンドに関する詳細な情報を取得したりするには、このプロンプトで help コマンドを実行してください。

ステップ 2 スイッチのローカル IP アドレスおよびサブネット マスクを指定します。

loader> ip address 172.16.1.2 255.255.255.0
Found Intel EtherExpressPro100 82559ER at 0xe800, ROM address 0xc000
Probing...[Intel EtherExpressPro100 82559ER]Ethernet addr: 00:05:30:00:52:27
Address: 172.16.1.2
Netmask: 255.255.255.0
Server: 0.0.0.0
Gateway: 0.0.0.0
 

ステップ 3 デフォルト ゲートウェイの IP アドレスを指定します。

loader> ip default-gateway 172.16.1.1
Address: 172.16.1.2
Netmask: 255.255.255.0
Server: 0.0.0.0
Gateway: 172.16.1.1
 

ステップ 4 目的のサーバからキックスタート イメージ ファイルを起動します。

loader> boot tftp://172.16.10.100/kickstart-latest
Address: 172.16.1.2
Netmask: 255.255.255.0
Server: 172.16.10.100
Gateway: 172.16.1.1
Booting: /kick-282 console=ttyS0,9600n8nn quiet loader_ver= “2.1(2)”....
............................................Image verification OK
Starting kernel...
INIT: version 2.78 booting
Checking all filesystems..... done.
Loading system software
INIT: Sending processes the TERM signal
Sending all processes the TERM signal... done.
Sending all processes the KILL signal... done.
Entering single-user mode...
INIT: Going single user
INIT: Sending processes the TERM signal
switch(boot)#
 

switch(boot)# プロンプトは、使用可能なキックスタート イメージがあることを示すものです。

ステップ 5 init system コマンドを発行し、ブートフラッシュのパーティションを再作成してフォーマットします。

ステップ 6 「switch(boot)# プロンプトからの復旧」 で指示されている手順を実行します。

ステップ 7 「1 つのスーパーバイザ モジュールでブートフラッシュが破損した場合の復旧」で指示されている手順を実行して、もう 1 つのスーパーバイザ モジュールを復旧します。


 


) 起動が失敗したときに reload module コマンドを発行しなかった場合、失敗後の 3 ~ 6 分以内に、スーパーバイザ モジュールはスタンバイ スーパーバイザ モジュールを自動的にリロードします。


エラー状態の認識

図2-7 および 図2-8 に示されているエラー メッセージの 1 つまたは両方が表示された場合は、「Supervisor 1 の BIOS 設定を使用した復旧」 で指示されている手順を実行してください。

図2-7 電源を投入して Ctrl+C を押した場合のエラー状態

 

図2-8 電源を投入して Esc を押した場合のエラー状態

 

スイッチまたはプロセスのリセット

回復可能または回復不可能なエラーが発生すると、スイッチまたはスイッチ上のプロセスはリセットされることがあります。

現象 スイッチまたはスイッチ上のプロセスがリセットされる。

 

表2-7 スイッチまたはプロセスのリセット

問題
考えられる原因
解決方法

スイッチまたはスイッチ上のプロセスがリセットされる。

システムまたはシステム内のプロセスで、回復可能なエラーが発生した。

Cisco SAN-OS では、このエラーから自動的に回復します。「回復可能なシステムの再起動」および「スイッチまたはプロセスのリセット」を参照してください。

システム上で回復不可能なエラーが発生した。

Cisco SAN-OS では、このエラーから自動的に回復することはできません。原因の判別については、「回復不能なシステムの再起動」 を確認してください。

クロック モジュールが故障している。

クロック モジュールが故障しているかどうかを確認します。詳細については、「クロック モジュールの問題のトラブルシューティング」を参照してください。次のメンテナンス ウィンドウ内で、故障したクロック モジュールを交換します。

回復可能なシステムの再起動

プロセスが再起動すると、常に Syslog メッセージおよび Call Home イベントが生成されます。イベントがサービスに影響していない場合でも、以後の再起動によってサービスが中断される可能性があるので、ただちに状態を確認して解決してください。

回復可能なシステムの再起動時には、次の手順で対応してください。


ステップ 1 次のコマンドを入力して Syslog ファイルを調べ、再起動したプロセスとその原因を確認します。

switch# show log logfile | include error
 

各メッセージの内容の詳細については、『 Cisco MDS 9000 Family System Messages Reference 』を参照してください。

次に、システムの出力例を示します。

Sep 10 23:31:31 dot-6 % LOG_SYSMGR-3-SERVICE_TERMINATED: Service "sensor" (PID 704) has finished with error code SYSMGR_EXITCODE_SY.
switch# show logging logfile | include fail
Jan 27 04:08:42 88 %LOG_DAEMON-3-SYSTEM_MSG: bind() fd 4, family 2, port 123, ad
dr 0.0.0.0, in_classd=0 flags=1 fails: Address already in use
Jan 27 04:08:42 88 %LOG_DAEMON-3-SYSTEM_MSG: bind() fd 4, family 2, port 123, ad
dr 127.0.0.1, in_classd=0 flags=0 fails: Address already in use
Jan 27 04:08:42 88 %LOG_DAEMON-3-SYSTEM_MSG: bind() fd 4, family 2, port 123, ad
dr 127.1.1.1, in_classd=0 flags=1 fails: Address already in use
Jan 27 04:08:42 88 %LOG_DAEMON-3-SYSTEM_MSG: bind() fd 4, family 2, port 123, ad
dr 172.22.93.88, in_classd=0 flags=1 fails: Address already in use
Jan 27 23:18:59 88 % LOG_PORT-5-IF_DOWN: Interface fc1/13 is down (Link failure
or not-connected)
Jan 27 23:18:59 88 % LOG_PORT-5-IF_DOWN: Interface fc1/14 is down (Link failure
or not-connected)
Jan 28 00:55:12 88 % LOG_PORT-5-IF_DOWN: Interface fc1/1 is down (Link failure o
r not-connected)
Jan 28 00:58:06 88 % LOG_ZONE-2-ZS_MERGE_FAILED: Zone merge failure, Isolating p
ort fc1/1 (VSAN 100)
Jan 28 00:58:44 88 % LOG_ZONE-2-ZS_MERGE_FAILED: Zone merge failure, Isolating p
ort fc1/1 (VSAN 100)
Jan 28 03:26:38 88 % LOG_ZONE-2-ZS_MERGE_FAILED: Zone merge failure, Isolating p
ort fc1/1 (VSAN 100)
Jan 29 19:01:34 88 % LOG_PORT-5-IF_DOWN: Interface fc1/1 is down (Link failure o
r not-connected)
switch#
 

ステップ 2 次のコマンドを入力して、実行中のプロセスおよび各プロセスのステータスを確認します。

switch# show processes
 

システム出力では、各状態(プロセス状態)が次のコードで示されます。

D = 中断なしで休止(通常 I/O)

R = 実行可能(実行キュー上)

S = 休止中

T = 追跡または停止

Z = 存在しない(ゾンビ)プロセス

NR = 実行されていない

ER = 実行されているべきだが、現在は実行されていない


) ER は通常、再起動回数が多すぎたためにシステムにより障害とみなされ、ディセーブルにされたプロセスの状態です。


次に、システムの出力例を示します(出力は簡略化するために短縮されています)。

PID State PC Start_cnt TTY Process
----- ----- -------- ----------- ---- -------------
1 S 2ab8e33e 1 - init
2 S 0 1 - keventd
3 S 0 1 - ksoftirqd_CPU0
4 S 0 1 - kswapd
5 S 0 1 - bdflush
6 S 0 1 - kupdated
71 S 0 1 - kjournald
136 S 0 1 - kjournald
140 S 0 1 - kjournald
431 S 2abe333e 1 - httpd
443 S 2abfd33e 1 - xinetd
446 S 2ac1e33e 1 - sysmgr
452 S 2abe91a2 1 - httpd
453 S 2abe91a2 1 - httpd
456 S 2ac73419 1 S0 vsh
469 S 2abe91a2 1 - httpd
470 S 2abe91a2 1 - httpd
 

ステップ 3 次のコマンドを入力して、異常終了したプロセスを表示し、スタックトレースまたはコア ダンプが実行されているかどうかを確認します。

switch# show process log
Process PID Normal-exit Stack-trace Core Log-create-time
---------------- ------ ----------- ----------- ------- ---------------
ntp 919 N N N Jan 27 04:08
snsm 972 N Y N Jan 24 20:50
 

ステップ 4 次のコマンドを入力して、再起動した特定プロセスの詳細情報を表示します。

switch# show processes log pid 898
Service: idehsd
Description: ide hotswap handler Daemon
Started at Mon Sep 16 14:56:04 2002 (390923 us)
Stopped at Thu Sep 19 14:18:42 2002 (639239 us)
Uptime: 2 days 23 hours 22 minutes 22 seconds
Start type: SRV_OPTION_RESTART_STATELESS (23)
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGTERM (3)
Exit code: signal 15 (no core)
CWD: /var/sysmgr/work
Virtual Memory:
CODE 08048000 - 0804D660
DATA 0804E660 - 0804E824
BRK 0804E9A0 - 08050000
STACK 7FFFFD10
Register Set:
EBX 00000003 ECX 0804E994 EDX 00000008
ESI 00000005 EDI 7FFFFC9C EBP 7FFFFCAC
EAX 00000008 XDS 0000002B XES 0000002B
EAX 00000003 (orig) EIP 2ABF5EF4 XCS 00000023
EFL 00000246 ESP 7FFFFC5C XSS 0000002B
Stack: 128 bytes. ESP 7FFFFC5C, TOP 7FFFFD10
0x7FFFFC5C: 0804F990 0804C416 00000003 0804E994 ................
0x7FFFFC6C: 00000008 0804BF95 2AC451E0 2AAC24A4 .........Q.*.$.*
0x7FFFFC7C: 7FFFFD14 2AC2C581 0804E6BC 7FFFFCA8 .......*........
0x7FFFFC8C: 7FFFFC94 00000003 00000001 00000003 ................
0x7FFFFC9C: 00000001 00000000 00000068 00000000 ........h.......
0x7FFFFCAC: 7FFFFCE8 2AB4F819 00000001 7FFFFD14 .......*........
0x7FFFFCBC: 7FFFFD1C 0804C470 00000000 7FFFFCE8 ....p...........
0x7FFFFCCC: 2AB4F7E9 2AAC1F00 00000001 08048A2C ...*...*....,...
PID: 898
SAP: 0
UUID: 0
switch#
 

ステップ 5 次のコマンドを入力して、再起動の発生時刻を確認します。

switch# show system uptime
Start Time: Fri Sep 13 12:38:39 2002
Up Time: 0 days, 1 hours, 16 minutes, 22 seconds
 

各再起動のタイムスタンプとシステムのアップタイムの長さを比較して、再起動が繰り返し行われているのか、または 1 回限りなのかを判別してください。

ステップ 6 次のコマンドを入力して、コア ファイルを表示します。

switch# show cores
Module-num Process-name PID Core-create-time
---------- ------------ --- ----------------
5 fspf 1524 Jan 9 03:11
6 fcc 919 Jan 9 03:09
8 acltcam 285 Jan 9 03:09
8 fib 283 Jan 9 03:08
 

この出力には、アクティブ スーパーバイザから現在アップロードできるすべてのコアが表示されます。module-num カラムは、コアが生成されたスロットの番号を示しています。前記の例では、スロット 5 のアクティブ スーパーバイザ モジュールで FSPF コアが生成され、スロット 6 のスタンバイ スーパーバイザ モジュールで FCC コアが生成されています。また、スロット 8 のラインカードで、ACLTCAM および FIB を含むコア ダンプが生成されています。

この例の FSPF コア ダンプを IP アドレスが 1.1.1.1 の TFTP サーバにコピーするには、次のコマンドを入力します。

switch# copy core://5/1524 tftp::/1.1.1.1/abcd
 

次のコマンドでは、 log ディレクトリにある zone_server_log.889 という名前のファイルが表示されます。

switch# show pro log pid 1473
======================================================
Service: ips
Description: IPS Manager
 
Started at Tue Jan 8 17:07:42 1980 (757583 us)
Stopped at Thu Jan 10 06:16:45 1980 (83451 us)
Uptime: 1 days 13 hours 9 minutes 9 seconds
 
Start type: SRV_OPTION_RESTART_STATELESS (23)
Death reason: SYSMGR_DEATH_REASON_FAILURE_SIGNAL (2)
Exit code: signal 6 (core dumped)
CWD: /var/sysmgr/work
 
Virtual Memory:
 
CODE 08048000 - 080FB060
DATA 080FC060 - 080FCBA8
BRK 081795C0 - 081EC000
STACK 7FFFFCF0
TOTAL 20952 KB
 
Register Set:
 
EBX 000005C1 ECX 00000006 EDX 2AD721E0
ESI 2AD701A8 EDI 08109308 EBP 7FFFF2EC
EAX 00000000 XDS 0000002B XES 0000002B
EAX 00000025 (orig) EIP 2AC8CC71 XCS 00000023
EFL 00000207 ESP 7FFFF2C0 XSS 0000002B
 
Stack: 2608 bytes. ESP 7FFFF2C0, TOP 7FFFFCF0
 
0x7FFFF2C0: 2AC8C944 000005C1 00000006 2AC735E2 D..*.........5.*
0x7FFFF2D0: 2AC8C92C 2AD721E0 2AAB76F0 00000000 ,..*.!.*.v.*....
0x7FFFF2E0: 7FFFF320 2AC8C920 2AC513F8 7FFFF42C ... ..*...*,...
0x7FFFF2F0: 2AC8E0BB 00000006 7FFFF320 00000000 ...*.... .......
0x7FFFF300: 2AC8DFF8 2AD721E0 08109308 2AC65AFC ...*.!.*.....Z.*
0x7FFFF310: 00000393 2AC6A49C 2AC621CC 2AC513F8 .......*.!.*...*
0x7FFFF320: 00000020 00000000 00000000 00000000 ...............
0x7FFFF330: 00000000 00000000 00000000 00000000 ................
0x7FFFF340: 00000000 00000000 00000000 00000000 ................
0x7FFFF350: 00000000 00000000 00000000 00000000 ................
0x7FFFF360: 00000000 00000000 00000000 00000000 ................
0x7FFFF370: 00000000 00000000 00000000 00000000 ................
0x7FFFF380: 00000000 00000000 00000000 00000000 ................
0x7FFFF390: 00000000 00000000 00000000 00000000 ................
0x7FFFF3A0: 00000002 7FFFF3F4 2AAB752D 2AC5154C .
(テキスト出力は省略)
Stack: 128 bytes. ESP 7FFFF830, TOP 7FFFFCD0
 

ステップ 7 次のコマンドを入力し、スイッチから TFTP を使用して、TFTP サーバにコア ダンプを送信します。

system cores tftp: [ // servername ][ / path ]

 

このコマンドにより、スイッチに TFTP サーバへのコア ファイルの自動コピーが設定されます。たとえば、IP アドレスが 10.1.1.1 の TFTP サーバにコア ファイルを送信するには、次のコマンドを使用します。

switch(config)# system cores tftp://10.1.1.1/cores
 

次の条件が適用されます。

コア ファイルは 4 分ごとにコピーされます。この間隔は変更できません。

TFTP サーバへの特定のコア ファイルのコピーは手動でトリガーすることが可能です。次のコマンドを使用します。
copy core:// module# / pid# tftp:// tftp_ip_address / file_name

プロセス再起動回数の最大値は、プロセスの HA ポリシーに含まれています(このパラメータは変更できません)。プロセスが最大値を超えて再起動されると、古いコア ファイルが上書きされます。

プロセスで保存可能な最大コア ファイル数は、プロセスの HA ポリシーに含まれています(このパラメータは変更できず、3 に設定されています)。

ステップ 8 カスタマー サポート 担当者に連絡してコア ダンプの検査を依頼し、再起動の原因と解決方法を判別します。


 

詳細については、「スーパーバイザの問題のトラブルシューティング」および「スイッチング モジュールおよびサービス モジュールのトラブルシューティング」を参照してください。

回復不能なシステムの再起動

回復不能なシステムの再起動は、次の条件で発生することがあります。

重要なプロセスが失敗したために、再起動ができない場合

プロセス再起動の回数がシステム設定の最大値を超えている場合

プロセス再起動がシステム設定で許可された以上に頻繁に行われている場合

プロセス再起動の影響は、各プロセスに設定されたポリシーによって異なります。回復不能な再起動は、機能の喪失、アクティブ スーパーバイザの再起動、スーパーバイザのスイッチオーバー、またはスイッチの再起動の原因になります。

回復不能な再起動への対応については、「Cisco SAN-OS ソフトウェアのシステム再起動のトラブルシューティング」を参照してください。

show system reset-reason CLI コマンドを使用すると、次の情報が表示されます。

Cisco MDS 9500 シリーズ スイッチでは、スロット 5 およびスロット 6 にあるスーパーバイザ モジュールに対して、直近の 4 つのリセット原因コードが表示されます。どちらかのスロットにスーパーバイザ モジュールが装着されていない場合は、そのモジュールに対応するリセット原因コードは表示されません。

Cisco MDS 9200 シリーズ スイッチでは、スロット 1 にあるスーパーバイザ モジュールに対して、直近の 4 つのリセット原因コードが表示されます。

show system reset-reason module number コマンドを使用すると、指定したスロットにある特定のモジュールに対して、直近の 4 つのリセット原因コードが表示されます。スロットにスーパーバイザ モジュールが装着されていない場合、モジュールのリセット原因コードは表示されません。

予期されたリロードおよび予期されないリロードが発生した時期と理由の履歴をすべて検索します。

リセットまたはリロードが発生したときのタイムスタンプが表示されます。

モジュールのリセットまたはリロードの理由が表示されます。

リセットまたはリロードの原因になったサービスが表示されます(表示されない場合もあります)。

リセットまたはリロードが発生したときに稼働していたソフトウェアのバージョンが表示されます。

例2-2 show system reason-reset コマンドの出力

switch# show system reset-reason module 5
----- reset reason for module 5 -----
1) At 224801 usecs after Fri Jan 21 16:36:40 2005
Reason: Reset Requested by CLI command reload
Service:
Version: 2.1(2)
2) At 922828 usecs after Fri Jan 21 16:02:48 2005
Reason: Reset Requested by CLI command reload
Service:
Version: 2.1(2)
3) At 318034 usecs after Fri Jan 21 14:03:36 2005
Reason: Reset Requested by CLI command reload
Service:
Version:2.1(2)
4) At 255842 usecs after Wed Jan 19 00:07:49 2005
Reason: Reset Requested by CLI command reload
Service:
Version: 2.1(2)
 
 

管理パスワードの回復

管理パスワードを忘れてしまった場合は、 表2-8 の説明に従ってスイッチにアクセスすることができます。

現象 スイッチにアクセスするための管理パスワードを忘れた。

 

表2-8 管理者パスワードの回復

問題
解決方法

Cisco MDS 9000 ファミリ スイッチにアクセスするための管理パスワードを忘れた。

パスワードは、ローカル コンソール接続を使用して回復できます。パスワード回復の最新の手順については、次の Web サイトで『Cisco MDS 9000 CLI Family Configuration Guide』を参照してください。

http://cisco.com/en/US/products/ps5989/products_installation_and_configuration_guides_list.html

Device Manager にアクセスできる場合は、次の手順で管理者パスワードを復旧します。


ステップ 1 必要なユーザ名とパスワードが含まれている TFTP サーバのテキスト ファイルを作成します。

"username admin password 0 admin123"
 

ステップ 2 Admin > Copy Configuration をクリックして、ファイルを TFTP サーバからスイッチの実行コンフィギュレーションにコピーします。


) クリア テキストのパスワード「admin123」で既存のパスワードが上書きされ、実行コンフィギュレーションで暗号化されます。


ステップ 3 Device > Command Line Interface をクリックしてスイッチにログオンし、新規パスワードを確認します。

ステップ 4 Admin > Save Configuration を選択して、実行コンフィギュレーションをスタートアップ コンフィギュレーションに保存します。


 

ソフトウェア イメージのその他の問題

ここでは、関連のリリース ノートで報告されているソフトウェア イメージの問題について説明します。具体的な内容は、次のとおりです。

「システム ヘルスのエラーによるすべてのポートのダウン」

「FCIP のリロード後のスイッチの再起動」

「FCIP リンクの開始の失敗」

「admin ロールの作成、変更、または削除が不可能」

「リンクのリセット後の FC ID の変更」

「スイッチが不正なユーザを表示」

システム ヘルスのエラーによるすべてのポートのダウン

現象 コンソールで、システム ヘルスのエラーが原因でモジュールのすべてのポートがダウンした。

 

表2-9 システム ヘルスのエラーによるすべてのポートのダウン

現象
考えられる原因
解決方法

システム コンソールで、システム ヘルスのエラーが原因でモジュールのすべてのポートがダウンしたことが報告された。

Cisco MDS 9000 モジュール上の不正なモジュールがエラー回復メカニズムから再初期化された可能性があり、モジュールは使用不能状態のままになっている。モジュールが再起動することもある。

使用中の OSM でサポートされているバージョンの Cisco SAN-OS Release 2.0(x) にダウングレードします。

Cisco SAN-OS Release 2.1.2 or 2.1(1b) にアップグレードします。モジュールをリセットすると問題は解消しますが、バグが修正されたバージョンの SAN-OS を使用しない限り、問題が再発する可能性があります。

FCIP のリロード後のスイッチの再起動

現象 FCIP モジュールがリロード、アップグレード、またはダウングレードされたあと、スイッチが再起動した。

 

表2-10 FCIP のリロード後のスイッチの再起動

現象
考えられる原因
解決方法

FCIP モジュールがリロード、アップグレード、またはダウングレードされたあと、スイッチが再起動した。

使用可能な FCIP ポートチャネルのある IPS モジュールがリロード、アップグレード、またはダウングレードされた場合、スーパーバイザ モジュールはリロードおよびシステムの再起動を行うことがある。

IPS モジュールをリロード、アップグレード、またはダウンロードする前に、モジュール上のすべての FCIP ポートチャネルをシャットダウンします。

FCIP リンクの開始の失敗

現象 新規に設定された FCIP リンクを MPS-14/2 モジュール上で稼働させようとすると、開始に失敗することがある。

 

表2-11 FCIP リンクの開始の失敗

現象
考えられる原因
解決方法

新規に設定された FCIP リンクを MPS-14/2 モジュール上で稼働させようとすると、開始に失敗することがある。

この症状は、Cisco MDS SAN-OS Release 2.0(1b) から Release 2.0(3) へアップグレードしたあと、および新規の FCIP リンクを設定したあとに発生することがある。

reload module module-number コマンドを使用して、MPS-14/2 モジュールをリロードします。なお、module-number は、特定のモジュールです。

admin ロールの作成、変更、または削除が不可能

現象 admin ロールの作成、変更、または削除ができない。

 

表2-12 admin ロールの作成、変更、または削除が不可能

現象
考えられる原因
解決方法

admin ロールの作成、変更、または削除ができない。

Cisco SAN-OS Release 2.0 へアップグレードしたあとは、admin ロールの作成、変更、または削除はできない。

Cisco SAN-OS Release 2.0 へアップグレードする前に admin ロールを作成します。

リンクのリセット後の FC ID の変更

現象 リンクのリセット後に FC ID が変更される。

 

表2-13 リンクのリセット後の FC ID の変更

現象
考えられる原因
解決方法

リンクのリセット後に FC ID が変更される。

永続的な FC ID がイネーブルになっている場合に、Cisco SAN-OS Release 1.1 から Release 1.3 以降へのアップグレードを行うと、リンク フラップのあとでストレージ アレイの FC ID が変わることがある。

必要に応じて FC ID を再設定します。

スイッチが不正なユーザを表示

現象 show running-config CLI コマンドを発行すると、スイッチが不正なユーザを表示する。

 

表2-14 スイッチが不正なユーザを表示

現象
考えられる原因
解決方法

show running-config CLI コマンドを発行すると、スイッチが不正なユーザを表示する。

Cisco SAN-OS Release 1.3(x) から Cisco SAN-OS Release 2.0(x) への中断なしのアップグレードを実行したあとで、show running-config コマンドを発行すると、スイッチが不正なユーザを表示する。中断なしのアップグレードが行われたあとに表示されるユーザは、show user-account コマンドが発行されたときに表示されるユーザとは異なる。

ユーザを作成し直します。