内容

概要

疑わしいハードウェア問題のトラブルシューティング

システムの電源が入らない、起動しない、または常にリブートする、または誤ったイメージをブートする

ファンの障害がシステムから報告される

ハードディスクの問題の疑い

高温の警告/アラーム

フロントパネルボタンが反応しない

ネットワークアダプタの問題

シリアルポートに予期しないログインプロンプトが表示される（VCSのみ）

TANDBERGアプリケーション/tshが起動しない（VCSのみ）

ブートログに「preboot agent installation failure」というメッセージが表示される

ログと証拠

Webからのシステムスナップショット

ルートシェルからのシステムスナップショット

クラッシュログ

センサーログ

DMIコード

ボードテスト

smartctl

ifconfigの出力

Ethtool統計情報ダンプ

ウイルスのチェック

アラームと警告

身体的証拠

コンソールアクセス

デフォルト設定の復元

前提条件ファイル

デフォルト設定へのリセットの実行

USBスティックによるリセット

一般的な非ハードウェア障害の問題

ディスクがいっぱいです – 空き領域

ディスクがいっぱいです – Inode

概要

このドキュメントでは、Return Material Authorization(RMA)プロセスを通じてCisco TelePresence Video Communication Server(VCS)またはCisco TelePresence Conductorを返却することを検討する場合のトラブルシューティングと情報収集の方法について説明します。

注：このドキュメントは、CEシリーズアプライアンスには適用されません。このガイドは、LCDパネル、キーパッド、および黒の前面プレートを備えたレガシーアプライアンスにのみ適用されます。CEシリーズアプライアンスの場合は、そのアプライアンスの基本情報の代わりに『Cisco UCS C220 Server Installation and Service Guide』を参照し、サービス契約に従って標準のサポートプロセスに従います。RMAを要求する際には、必要な情報をシスコのサポートエンジニアに提供することが重要です。サポートエンジニアからの連絡を待つ必要はありません。サポートチケットはいつでも適切な情報で更新できます。

疑わしいハードウェア問題のトラブルシューティング

システムの電源が入らない、起動しない、または常にリブートする、または誤ったイメージをブートする

VCS/TelePresence Conductorシステムの電源が入らない、起動しない、または常にリブートする場合は、次の項目を確認してください。

1. LED/LCDディスプレイは点灯していますか。

「はい」の場合、デバイスの電源は入りますが、起動しない可能性があります。次のことを確認してください。

- システムのUSBポート(特にUSBキーボード/ビデオ/マウス(KVM))に接続されているデバイスはありますか。

可能な場合は、それらを取り外し、システムの電源を切ってから再び入れます。それでもシステムが起動しない場合は、シリアルコンソールに接続し、ブートアップ用の出力をできる限り収集します。出力をサポートチケットに添付します。

ヒント：シリアル接続を使用してシステムに接続する方法については、「コンソールアクセス」を参照してください。

- システムのシリアルポートに接続されているデバイスはありますか。

可能な場合は、それらを取り外し、システムの電源を切って再度入れ直します。それでもシステムが起動しない場合は、シリアルコンソールに接続し、ブートアップ用の出力をできる限り収集します。出力をサポートチケットに添付します。

ヒント：シリアル接続を使用してシステムに接続する方法については、「コンソールアクセス」を参照してください。

LED/LCDが点灯していない場合は、システムの電源コンセントと電源リード線を変更します。ユニット背面の電源スイッチとソフトスイッチが正しい位置にあり、適切な位置に押されていることを確認します。電源ケーブルを別のデバイスに接続して、正常に動作することを確認します。

2. デバイスのリブートが続いているにもかかわらず、少しアップ状態が続く場合は、センサーログを収集してみてください。詳細については、「ログと証拠」を参照してください。

3. それでもシステムが起動しない場合は、システムを確認するために実行した手順のリストを含むサポートチケットを発行します。

ファンの障害がシステムから報告される

ファンの障害が報告された場合は、「アラームと警告」の「ログと証拠」に示すように、システムから障害の証拠を収集します。収集した情報を添付してサポートチケットを発行します。

ハードディスクの問題の疑い

管理者は、ハードディスクに障害があると考えています。ハードディスクは「マウント解除」されていると記述されていますか。

「はい」の場合は、「ログと証拠」に記載されている情報をできるだけ収集します。

- 物理的な証拠：LCDに表示されるメッセージを表示し、収集した情報を添付してサポートチケットを発行します。

- smartctl

- デスクトップ管理インターフェイス(DMI)コード

- アラームと警告

収集した情報を添付してサポートチケットを発行します。

マウントされていない場合（ディスクが「アンマウント済み」と表示されていない場合）は、管理者がハードディスクに問題があると考える理由を調査します。この情報は、ディスクの問題を示す十分な証拠となります。

- 身体的証拠

- smartctl

- DMIコード

- アラームと警告

- システムスナップショット

ヒント：詳細については、「ログと証拠」を参照してください。

dmesgや/var/log/messagesなど、標準的なLinuxログにディスク関連のエラーメッセージが記録されている場合があります。収集した情報を添付してサポートチケットを発行します。

次に、表示される可能性があるエラーログのタイプの例をいくつか示します。

ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

ata4.00: cmd c8/00:00:81:53:2a/00:00:00:00:00/e1 tag 0 dma 131072 in

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

ata4.00: status: { DRDY }

ata4: hard resetting link

ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

ata4.00: configured for UDMA/133

ata4.00: device reported invalid CHS sector 0

ata4: EH complete

e2fsck 1.41.9 (22-Aug-2009)

ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

ata4.00: cmd c8/00:c0:a1:53:2a/00:00:00:00:00/e1 tag 0 dma 98304 in

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

ata4.00: status: { DRDY }

ata4: hard resetting link

ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

ata4.00: configured for UDMA/133

ata4.00: device reported invalid CHS sector 0

ata4: EH complete

ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

ata4.00: cmd c8/00:d0:91:54:2a/00:00:00:00:00/e1 tag 0 dma 106496 in

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

ata4.00: status: { DRDY }

ata4: hard resetting link

ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

ata4.00: configured for UDMA/133

ata4.00: device reported invalid CHS sector 0

ata4: EH complete

ata4: limiting SATA link speed to 1.5 Gbps

ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

ata4.00: cmd c8/00:d0:91:54:2a/00:00:00:00:00/e1 tag 0 dma 106496 in

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

ata4.00: status: { DRDY }

ata4: hard resetting link

ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

ata4.00: configured for UDMA/133

ata4.00: device reported invalid CHS sector 0

ata4: EH complete

ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

ata4.00: cmd c8/00:d0:91:54:2a/00:00:00:00:00/e1 tag 0 dma 106496 in

res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

ata4.00: status: { DRDY }

ata4: hard resetting link

ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

ata4.00: configured for UDMA/133

ata4.00: device reported invalid CHS sector 0

ata4: EH complete

ata4: link is slow to respond, please be patient (ready=0)

ata4: SRST failed (errno=-16)

ata4: link is slow to respond, please be patient (ready=0)

ata4: SRST failed (errno=-16)

ata4: link is slow to respond, please be patient (ready=0)

ata4: SRST failed (errno=-16)

ata4: limiting SATA link speed to 1.5 Gbps

ata4: SRST failed (errno=-16)

ata4: reset failed, giving up

kernel: irq 19: nobody cared (try booting with the "irqpoll" option)

kernel: Pid: 0, comm: swapper Not tainted 2.6.31.12 #1

kernel: Call Trace:

kernel: <IRQ> [<ffffffff810743d6>] __report_bad_irq+0x26/0xa0

kernel: [<ffffffff810745dc>] note_interrupt+0x18c/0x1d0

kernel: [<ffffffff81074db5>] handle_fasteoi_irq+0xb5/0xe0

kernel: [<ffffffff8100e35d>] handle_irq+0x1d/0x30

kernel: [<ffffffff8100d887>] do_IRQ+0x67/0xe0

kernel: [<ffffffff8100bcd3>] ret_from_intr+0x0/0xa

kernel: <EOI> [<ffffffff81012c03>] ? mwait_idle+0x63/0x80

kernel: [<ffffffff8100a500>] ? enter_idle+0x20/0x30

kernel: [<ffffffff8100a574>] ? cpu_idle+0x64/0xb0

kernel: [<ffffffff81399d05>] ? rest_init+0x65/0x70

kernel: [<ffffffff816c250a>] ? start_kernel+0x33c/0x348

kernel: [<ffffffff816c1b75>] ? x86_64_start_reservations+0x125/0x129

kernel: [<ffffffff816c1c5d>] ? x86_64_start_kernel+0xe4/0xeb

kernel: handlers:

kernel: [<ffffffff81254260>] (ata_sff_interrupt+0x0/0x110)

kernel: [<ffffffff81254260>] (ata_sff_interrupt+0x0/0x110)

kernel: [<ffffffff81280ba0>] (usb_hcd_irq+0x0/0x70)

kernel: Disabling IRQ #19

高温の警告/アラーム

VCS/TelePresence Conductorが高温アラームを報告します。

- このユニットは、側面空気吸入口と背面空気吸出口とを有する。十分な換気（特に両側）があることを確認するためにチェックを行うべきである。側面が正常に見える場合でも、Codian Multipoint Control Unit(MCU)などの別のデバイスがユニットの吸気口に直接排気を放出する可能性があります。

- MCUのエアーフローは右から左です。VCS/TelePresence Conductorの右にラックする場合は特に注意してください。

- サーミスタの温度センサーで、誤った読み取りが報告される場合があります。すべてのアラームを確認し、その後の発生についてシステムを監視します。

- 「ログと証拠」に示すように、システムから障害の証拠を収集します。

- アラームと警告

- 身体的証拠。

収集した情報を添付してサポートチケットを発行します。

フロントパネルボタンが反応しない

前面パネルの特定のバージョン、特に初期のシスコブランドパネルでは、前面パネルのボタンの接点に問題があります。この問題は、新しいバージョンの前面パネルで解決されており、システムの日常的な動作には影響しません。

問題の証拠を収集します。「ログと証拠」の「DMIコード」セクションを参照してください。

前面パネルが反応しない場合は、アプライアンスへのシリアル接続を使用して初期設定を行うことができます。

ヒント：シリアル接続を使用してアプライアンスに接続する方法については、「コンソールアクセス」を参照してください。

ネットワークアダプタの問題

管理者から、ネットワークアダプタに問題があるか、LANリンクがダウンしているという報告がありました。

アプライアンスが接続されているスイッチ/ルータ上の異なるLANケーブルとポートが試行されていることを確認します。

「ログと証拠」で詳しく説明されているように、問題に関する次の証拠を収集します。

- ifconfigの出力

- ethtool統計情報ダンプ

- ボードテスト

- 身体的証拠

- アラームと警告

- システムスナップショット

収集した情報を添付してサポートチケットを発行します。

シリアルポートに予期しないログインプロンプトが表示される（VCSのみ）

Cisco VCSが起動すると、通常は次のようなメッセージが表示されます。

tandberg login: root

Password:

ただし、デバイスの起動時に、Fusion MPT SASドライバからのメッセージがログインプロンプトと衝突する場合があります。この場合、次の出力が表示されます。

tandberg login: Fusion MPT misc device (ioctl) driver 3.04.14

mptctl: Registered with Fusion MPT base driver

mptctl: /dev/mptctl @ (major,minor=10,220)

これは、シスコが認識しているソフトウェアの問題が原因で、RMAは発生しません。この問題は、X6.0以降のバージョンのコードで修正されています。

TANDBERGアプリケーション/tshが起動しない（VCSのみ）

コンソールセッション(Secure Shell(SSH)、Telnet、シリアル、またはKVM)にadminとしてログインしようとすると、「unable to connect to tsh」または「/tmp/hwfail exists: TANDBERG application startup inhibited」というメッセージが表示されます。

1. /tmp/hwfailファイルは存在しますか。

「はい」の場合は、ログと証拠からこの情報を収集します。

- ルートシェルからのシステムスナップショット

- DMIコード

- ボードテスト

- 身体的証拠

2. 「tsh」と入力するか、adminとしてログインすると、「tshに接続できません」というメッセージが表示されますか。

- システムに「cat /tandberg/etc/rk」というリリースキーがあり、そのリリースキーがシステムのシリアル番号とインストールされているソフトウェアレベルに対して有効であることを確認します。

- それでも問題が解決せず、アプリケーションが起動しない場合は、次の情報を収集します。

- ルートシェルからのシステムスナップショット

- DMIコード

- ボードテスト

- 身体的証拠

- 「はい」の場合は、ログと証拠からこの情報を収集します。

- ルートシェルからのシステムスナップショット

- DMIコード

- ボードテスト

- 身体的証拠

収集した情報を添付してサポートチケットを発行します。

注:TelePresence Conductorにはtshと同等の機能はありません。

ブートログに「preboot agent installation failure」というメッセージが表示される

VCSのブート時にVCSへのシリアル接続がない場合は、ブートログに「プリブートエージェントのインストールに失敗しました」というメッセージが表示されることがあります。

これは問題ではなく、RMAの原因にはなりません。

ログと証拠

このセクションでは、ログの取得、スナップショットの作成、その他の証拠の収集の方法について説明します。

Webからのシステムスナップショット

システムスナップショットプロセスは、管理者のPCにダウンロード可能なさまざまなシステムファイルのファイルアーカイブを作成します。

X6.1またはXC1.1以前でシステムスナップショットを開始するには、次の手順を実行します。

1. [Maintenance] > [System snapshot] を選択します。

2. [Create full snapshot] をクリックします。

3. アーカイブが作成されるまで待ちます（ファイルが多いため、時間がかかる場合があります）。

4. ファイルをローカルPCにダウンロードできるように、ファイルのダウンロードダイアログが表示されます（PCに十分なディスク領域があることを確認します）。

X7.0またはXC1.2以降でシステムスナップショットを開始するには、次の手順を実行します。

1. [Maintenance] > [Diagnostics] > [System snapshot] を選択します。

2. [Create full snapshot] をクリックします。

3. アーカイブが作成されるまで待ちます（ファイルが多いため、時間がかかる場合があります）。

4. ファイルをローカルPCにダウンロードできるように、ファイルのダウンロードダイアログが表示されます（PCに十分なディスク領域があることを確認します）。

スナップショットを作成すると、システム・リソースが予約されます。非常にビジーなシステムでは、「低トラフィック」の期間にスナップショットを開始することをお勧めします（ただし、分析するイベントの後にスナップショットを長く残さないでください）。

一度に（最新の）1つのスナップショットアーカイブ(.tar.gz)が/mnt/harddisk/snapshotに1つだけディスクに保存されます。

ルートシェルからのシステムスナップショット

システムスナップショットプロセスは、管理者のPCにダウンロード可能なさまざまなシステムファイルのファイルアーカイブを作成します。

システムスナップショットを開始するには、次の手順を実行します。

1. rootとしてシステムにログインします。

2. snapshot.shと入力します。

3. アーカイブが作成されるまで待ちます（ファイルが多数あるため、時間がかかる場合があります。ファイルが.tarファイルから.tar.gzファイルに変更されるまで待ちます）。

4. スナップショットが生成されると、/mnt/harddisk/snapshot/(これはtar.gzアーカイブです)からセキュアコピー(SCP)に使用できます。

スナップショットを作成すると、システム・リソースが予約されます。非常にビジーなシステムでは、「低トラフィック」の期間にスナップショットを開始することをお勧めします（ただし、分析するイベントの後にスナップショットを長く残さないでください）。

一度に（最新の）1つのスナップショットアーカイブ(.tar.gz)が/mnt/harddisk/snapshotに1つだけディスクに保存されます。

クラッシュログ

アプリケーションに障害が発生するたびに、インシデントレポートが/tandberg/crash/directoryにディスクに書き込まれます。

インシデントレポートはスナップショットアーカイブに含まれます。

シスコのサポートエンジニアは、外部にルーティング可能なサーバをホストします。このサーバ上に、VCS/TelePresence Conductorを設定してインシデントレポートを投稿できます。管理者がインシデントレポートをポストするようにシステムを設定すると、アプリケーション障害の通知が高速化されます。

Automated Crash Report(ACR)サーバへのクラッシュレポートの自動アップロードは、[メンテナンス(Maintenance)] > [インシデントレポート(Incident reporting)] > [設定(Configuration)] で設定できます(X7.0/XC1.1以降では、[メンテナンス(Maintenance)] > [診断(Diagnostics)] > [インシデントレポート(Incident reporting)] > [設定(Configuration)] です)。

- インシデントレポートでは、送信モードをOn(デフォルトではOff)に設定する必要があります。

- インシデントレポートのURLはhttps://cc-reports.cisco.com/submitapplicationerror/に設定する必要があります(従来のURL https://vcser.tandberg.com/submitapplicationerror/もインシデントレポートサーバに到達します)。

- 「インシデント」（クラッシュ）の後、HTTPS（システムソースポート4000-4999）を使用してインシデントレポートがこのURLに送信されます。

アプリケーション全体がクラッシュすることはなく、ACRはシステム内のサブコンポーネントによって生成される場合もあります。

何らかの理由でクラッシュレポートを有効にできない場合、またはシステムがサーバにルーティング可能なアクセスを持たない場合は、生成されたACRをシステムから個別にコピーし、サポートチケットに添付することができます。

シスコのサポートエンジニアは、調査のためにACRをレポートサーバに手動でアップロードできます。ほとんどの場合、問題の原因を理解するためにシステムスナップショットも必要です。

インシデントレポートは、[メンテナンス(Maintenance)] > [インシデントレポート(Incident reporting)] > [表示(View)] ページ(X7.0/XC1.1以降では、[メンテナンス(Maintenance)] > [診断(Diagnostics)] > [インシデントレポート(Incident reporting)] > [表示(View)] ページ)からシステムから表示およびコピーできます。

センサーログ

アプライアンスハードウェアには多数のセンサーが含まれており、その値はLinuxオペレーティングシステム(OS)で読み取ることができます。これらのセンサーを取得するには、コマンドプロンプトでsensorsと入力します。出力はサポートチケットに添付できます。

~ # sensors

acpitz-virtual-0

Adapter: Virtual device

it8712.7-isa-0290

Adapter: ISA adapter

VCore: +1.22 V (min = +0.83 V, max = +1.39 V)

DDR 1.8V: +1.78 V (min = +1.62 V, max = +1.98 V)

VCC 3.3V: +3.31 V (min = +3.14 V, max = +3.47 V)

VCC 5V: +5.00 V (min = +4.76 V, max = +5.24 V)

+12V: +12.22 V (min = +9.60 V, max = +14.40 V)

VCC 1.5V: +1.49 V (min = +1.42 V, max = +1.57 V)

VBat: +3.26 V (min = +2.99 V)

Fan 1: 9375 RPM (min = 7670 RPM, div = 8)

Fan 2: 9375 RPM (min = 7670 RPM, div = 8)

Fan 3: 10546 RPM (min = 7670 RPM, div = 8)

Sys Temp1: +18.0 C (high = +45.0 C) sensor = thermistor

Sys Temp2: +20.0 C (high = +45.0 C) sensor = thermistor

CPU Temp: +18.0 C (high = +50.0 C) sensor = thermal diode

coretemp-isa-0000

Adapter: ISA adapter

Core 0: +35.0 C (high = +78.0 C, crit = +100.0 C)

coretemp-isa-0001

Adapter: ISA adapter

Core 1: +32.0 C (high = +78.0 C, crit = +100.0 C)

DMIコード

問題が発生した場合は、DMIコードを使用して、問題のシステムに適用されているエンジニアリング変更リクエスト(ECO)を示す有用な参照コードをシスコサポートエンジニアに提供できます。

ルートコンソールセッションからコマンドcat /sys/class/dmi/id/chassis_versionを入力し、出力を追加するか、システムスナップショットからサポートチケットにdmidecode.txtファイルを含めます。

ボードテスト

ルートコンソールセッションからboarddetectコマンドを入力し、その出力をサポートチケットに追加します。

smartctl

VCSには2種類のディスクがあります。

- SDA：これはVCS上のプライマリディスクです。このディスクに障害が発生すると、VCSがまったく起動しなくなります。これが失敗すると、VCSは正常に起動しません。

- SDB：これはセカンダリディスクです。このディスクに障害が発生すると、VCSで問題が発生する可能性があります。SDBに障害があるかどうかを確認する最良の方法は、smartctlツールを使用することです。

Linux OSには、ハードディスクのSelf-Monitoring, Analysis and Reporting Technology(SMART)データを調べるハードディスクチェッカーが含まれています。

これを実行するには、ルートコンソールセッションからコマンドプロンプトでsmartctl -all /dev/sdb2と入力します。出力はサポートチケットに添付できます。

~ # smartctl --all /dev/sdb2

smartctl 5.39.1 2010-01-28 r3054 [x86_64-pc-linux-gnu] (local build)

Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===

Model Family: Seagate Barracuda 7200.10 family

Device Model: ST3250410AS

Serial Number: 9RY29MGL

Firmware Version: 3.AAC

User Capacity: 250,059,350,016 bytes

Device is: In smartctl database [for details use: -P show]

ATA Version is: 7

ATA Standard is: Exact ATA specification draft version not indicated

Local Time is: Mon Apr 4 16:10:02 2011 GMT

SMART support is: Available - device has SMART capability.

SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===

SMART overall-health self-assessment test result: PASSED

General SMART Values:

Offline data collection status: (0x82) Offline data collection activity

was completed without error.

Auto Offline Data Collection: Enabled.

Self-test execution status: ( 0) The previous self-test routine completed

without error or no self-test has ever

been run.

Total time to complete Offline

data collection: ( 430) seconds.

Offline data collection

capabilities: (0x5b) SMART execute Offline immediate.

Auto Offline data collection on/off support.

Suspend Offline collection upon new

command.

Offline surface scan supported.

Self-test supported.

No Conveyance Self-test supported.

Selective Self-test supported.

SMART capabilities: (0x0003) Saves SMART data before entering

power-saving mode.

Supports SMART auto save timer.

Error logging capability: (0x01) Error logging supported.

General Purpose Logging supported.

Short self-test routine

recommended polling time: ( 1) minutes.

Extended self-test routine

recommended polling time: ( 64) minutes.

SCT capabilities: (0x0001) SCT Status supported.

SMART Attributes Data Structure revision number: 10

Vendor Specific SMART Attributes with Thresholds:

ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE

1 Raw_Read_Error_Rate 0x000f 111 092 006 Pre-fail Always - 35118725

3 Spin_Up_Time 0x0003 097 097 000 Pre-fail Always - 0

4 Start_Stop_Count 0x0032 099 099 020 Old_age Always - 1076

5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0

7 Seek_Error_Rate 0x000f 084 060 030 Pre-fail Always - 313078675

9 Power_On_Hours 0x0032 073 073 000 Old_age Always - 23803

10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0

12 Power_Cycle_Count 0x0032 099 099 020 Old_age Always - 1078

187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0

189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0

190 Airflow_Temperature_Cel 0x0022 074 068 045 Old_age Always - 26

(Lifetime Min/Max 24/32)

194 Temperature_Celsius 0x0022 026 040 000 Old_age Always - 26 (0 12 0 0)

195 Hardware_ECC_Recovered 0x001a 081 051 000 Old_age Always - 149212051

197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0

198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0

199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0

200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0

202 Data_Address_Mark_Errs 0x0032 100 253 000 Old_age Always - 0

SMART Error Log Version: 1

No Errors Logged

SMART Self-test log structure revision number 1

SMART Selective self-test log data structure revision number 1

SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS

1 0 0 Not_testing

2 0 0 Not_testing

3 0 0 Not_testing

4 0 0 Not_testing

5 0 0 Not_testing

Selective self-test flags (0x0):

After scanning selected spans, do NOT read-scan remainder of disk.

If Selective self-test is pending on power-up, resume after 0 minute delay.

ifconfigの出力

一部のアプライアンスでは、物理ネットワークポートが失われる可能性があります。これを確認するには、ルートコンソールセッションを開き、コマンドifconfig -a | grep eth。次の4つのインターフェイスをリストする必要があります。

~ # ifconfig -a | grep eth

eth0 Link encap:Ethernet HWaddr 00:10:F3:1E:D4:90

eth1 Link encap:Ethernet HWaddr 00:10:F3:1E:D4:91

eth2 Link encap:Ethernet HWaddr 00:10:F3:1E:D4:92

eth3 Link encap:Ethernet HWaddr 00:10:F3:1E:D4:93

4個未満がリストされている場合、このアプライアンスにハードウェアの問題がある可能性がありますが、リブートすることでも解決する場合があります。

Ethtool統計情報ダンプ

Linux OSには、イーサネットアダプタの統計情報をダンプするツールが含まれています。

ルートコンソールセッションから、アプライアンスで使用されるメインネットワークアダプタに対してethtool -S eth0コマンドを入力します。LAN 2ポートに問題がある場合はethtool -S eth1を入力します。

~ # ethtool -S eth0

NIC statistics:

rx_packets: 49308441

tx_packets: 13055377

rx_bytes: 10446941316

tx_bytes: 8354830356

rx_broadcast: 36524340

tx_broadcast: 129146

rx_multicast: 5884

tx_multicast: 79

rx_errors: 0

tx_errors: 0

tx_dropped: 0

multicast: 5884

collisions: 0

rx_length_errors: 0

rx_over_errors: 0

rx_crc_errors: 0

rx_frame_errors: 0

rx_no_buffer_count: 0

rx_missed_errors: 0

tx_aborted_errors: 0

tx_carrier_errors: 0

tx_fifo_errors: 0

tx_heartbeat_errors: 0

tx_window_errors: 0

tx_abort_late_coll: 0

tx_deferred_ok: 0

tx_single_coll_ok: 0

tx_multi_coll_ok: 0

tx_timeout_count: 0

tx_restart_queue: 0

rx_long_length_errors: 0

rx_short_length_errors: 0

rx_align_errors: 0

tx_tcp_seg_good: 115846

tx_tcp_seg_failed: 0

rx_flow_control_xon: 465

rx_flow_control_xoff: 465

tx_flow_control_xon: 0

tx_flow_control_xoff: 0

rx_long_byte_count: 10446941316

rx_csum_offload_good: 12205535

rx_csum_offload_errors: 0

rx_header_split: 0

alloc_rx_buff_failed: 0

tx_smbus: 0

rx_smbus: 0

dropped_smbus: 0

rx_dma_failed: 0

tx_dma_failed: 0

ウイルスのチェック

ウイルスの存在を検索するには、ルートコンソールセッションからps auxコマンドを使用できます。

たとえば、「war dialer」を確認するには、ps auxと入力します | grep svwar.py。「war dialer」が存在する場合は、次のような出力行が表示されます。

9430 root 20 0 19020 4340 1880 R 1 0.1 0:00.01 python svwar.py -v -d

users.txt <address>

ウイルスが存在しない場合、コマンドは出力を生成しません。

ヒント：これらの問題は、USBの再インストール手順で解決できます。「デフォルト設定の復元」を参照してください。

アラームと警告

アラームと警告は、システムのWebページと、CLIにログインしたときやxstatusコマンドを入力したときに表示されます。LCDパネルにも表示される場合があります。

Webインターフェイスからの画面キャプチャまたはxstatusコマンドからの出力を提供する必要があります。次に例を示します。

身体的証拠

実施した手順のカメラの電話機のビデオや、モニタ出力の写真、次の例のようなLED、LCD、およびネットワークリンクライトの表示は、RMAの根本原因を突き止めるのに非常に役立ちます。

アラームLED点灯

LCDテキスト

コンソールアクセス

ネットワークの問題や、VCS/TelePresence Conductorへのリモートからのアクセスを妨げるその他の問題が発生した場合に、ログやその他の情報を収集するには、シリアルコンソールを使用できます。アプライアンスの前面にあるデータポートに接続する必要があります。

コンソール接続には、次の設定を使用する必要があります。

設定値

値

ボーレート

115200 ビット/秒

データ ビット

8

パリティ

なし

ストップ ビット

1

フロー制御（ハードウェアおよびソフトウェア）

なし

デフォルト設定の復元

ごくまれに、システムで「工場出荷時の状態にリセット」スクリプトを実行する必要が生じることがあります。これにより、ソフトウェアイメージが再インストールされ、設定が機能上の最小値にリセットされます。

注：デフォルト設定に復元すると、特にシステムが古いバージョンからアップグレードされている場合は、以前に設定された値とは異なる現在のデフォルト値が使用されます。特に、多重化されたメディアポートなどのポート設定に影響する場合があります。デフォルト設定を復元した後、ファイアウォールの想定される動作に合わせてこれらのポート設定をリセットする必要がある場合があります。

前提条件ファイル

次に説明するfactory-reset手順では、正常にインストールされた最新のソフトウェアイメージに基づいてシステムをリビルドします。この再インストールに使用されるファイルは、システムの/mnt/harddisk/factory-reset/フォルダに保存されます。これらのファイルは次のとおりです。

- rkという名前の16文字のリリースキーのみを含むテキストファイル。

- tandberg-image.tar.gzという名前のtar.gz形式のソフトウェアイメージを含むファイル。

場合によっては（最も一般的には、アップグレードされていない新規の仮想マシンのインストール）、これらのファイルがシステムに存在しないことがあります。その場合は、これらのファイルを最初にSCPをルートとして配置する必要があります。

デフォルト設定へのリセットの実行

この手順は、シリアル・コンソールから（またはキーボードとモニターを使用してアプライアンスに直接接続して）実行する必要があります。これは、ネットワーク設定が書き換えられるため、リセットを開始するために使用されるSSHセッションがドロップされ、手順の出力が表示されないためです。

このプロセスには約20分かかります。

1. rootとしてシステムにログインします。

2. factory-resetと入力します。

3. 必要に応じて質問に回答します。推奨応答では、システムが完全に工場出荷時のデフォルト状態にリセットされます。

プロンプト

推奨される対応

オプションキー{YES/NO]を保持しますか？

はい

IP設定を保持しますか[はい/いいえ]?

はい

SSHキーを保持しますか[はい/いいえ]?

はい

SSL証明書とキーを保持しますか[はい/いいえ]?

はい

rootおよびadminパスワードを保持しますか[はい/いいえ]?

はい

ログファイルを保存しますか[はい/いいえ]?

はい

ハードディスクを交換しますか？ [はい/いいえ]（レガシーアプライアンスハードウェアで実行されているシステムにのみ適用されます）

NO

4. 最後に、続行することを確認します。

USBスティックによるリセット

Cisco TACでは、代替のリセット方法も提案する場合があります。そのためには、ソフトウェアイメージをUSBスティックにダウンロードし、USBスティックを接続した状態でシステムを再起動する必要があります。

この方法を使用する場合は、使用後にUSBスティックをクリアダウンして再構築する必要があります。1つのシステムをリセットして、USBスティックを別のシステムで再利用しないでください。

一般的な非ハードウェア障害の問題

ディスクがいっぱいです – 空き領域

ハードディスクに格納できるデータの量は設定されています。ハードディスクがいっぱいになると、ハードウェア障害の症状が発生する可能性がありますが、そうではなく、RMAはこの問題に対処するための推奨される方法ではありません。現在のディスク使用率を確認するには、コマンドdf as rootを実行します。dfの – hスイッチは、データを人間が読める形式（1kブロックではなくMBとGB）で印刷することを要求します。

~ # df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/sda5       955M  493M  414M  55% /

devtmpfs        3.0G  236K  3.0G   1% /dev

/dev/ram0       190M  3.7M  176M   3% /var

/dev/ram1       1.5G  3.2M  1.4G   1% /tmp

/dev/sda7       955M  670M  237M  74% /tandberg

/dev/sdb2        40G  7.0G   31G  19% /mnt/harddisk

この例では、どのパーティションも（100%またはほぼ100%）完全にフルになっていないことがわかります。パーティションが100%(97%+)以上の場合は、一部のファイルを削除する必要があります。どのファイルを削除すればよいかわからない場合は、Cisco TACにお問い合わせください。

ディスクがいっぱいです – Inode

実際のストレージ容量に加えて、VCSはハードディスク上のinodeを使用します。ディスクがいっぱいになった場合の症状は、ディスク自体がいっぱいになった場合と同様です。

~ # df -ih

Filesystem     Inodes IUsed IFree IUse% Mounted on

/dev/sda5         61K   14K   48K   23% /

devtmpfs         746K  2.2K  744K    1% /dev

/dev/ram0         49K    80   49K    1% /var

/dev/ram1         92K   630   91K    1% /tmp

/dev/sda7         61K  2.0K   59K    4% /tandberg

/dev/sdb2        2.5M  2.1K  2.5M    1% /mnt/harddisk

ハードディスクがiノードの外に出ていたり、iノードの外に出そうになったりする場合、通常は非常に小さなファイルが大量に存在することを意味します。何を削除する必要があるか、および削除が生成された理由を判断するには、Cisco TACに連絡して支援を求めることをお勧めします。