File System Diagnostic Error

OPERATING INSTRUCTIONS

177/1543-CRA 119 0360/10 Uen A

Copyright

© Ericsson AB 2008–2014. All rights reserved. No part of this document may be

reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to
continued progress in methodology, design and manufacturing. Ericsson shall
have no liability for any error or damage of any kind resulting from the use
of this document.

177/1543-CRA 119 0360/10 Uen A | 2014-11-20

 Contents

Contents

1 Overview 1
1.1 Description 1
1.2 Prerequisites 1

2 Procedure 3
2.1 Analyzing the Alarm 3
2.2 Regular MP 3
2.3 Redundant Core MP 4

177/1543-CRA 119 0360/10 Uen A | 2014-11-20

File System Diagnostic Error

177/1543-CRA 119 0360/10 Uen A | 2014-11-20

 Overview

1 Overview

This instruction concerns alarm handling.

1.1 Description
The alarm is a primary alarm. The alarm is issued by the MO PluginUnit. This
alarm is a result of the system health check. The severity of the alarm is Major.
For more information on the system health check, refer to the User Guide for
System Check.

The possible alarm causes and fault locations are explained in Table 1.

Table 1 Alarm Causes

Alarm Description Fault Reason Fault Location Impact
Cause
Fault in the The file system has File system The board Possible loss of
file system. failed. inconsistency that issued the functionality.
that can alarm.
be fixed by
formatting the
volumes on the
affected board.

Note: If the alarm is not acted on, that is if the disk is not formatted, continued
operation is uncertain. The node might also fail as a consequence.

1.2 Prerequisites
This section provides information on the documents, tools and conditions that
apply to the procedure.

1.2.1 Documents
Before starting this procedure, ensure that you have read the following
document:

• System Safety Information

1.2.2 Tools

No tools are required.

177/1543-CRA 119 0360/10 Uen A | 2014-11-20 1

 File System Diagnostic Error

1.2.3 Conditions

Before starting this procedure, ensure that the following conditions are met:

• There is no hardware reconfiguration in progress.

• There is no system upgrade in progress.

• The O&M node IP address is known.

• You have the task profile, FM Advanced or higher, if security level 3 is set.

2 177/1543-CRA 119 0360/10 Uen A | 2014-11-20

 Procedure

2 Procedure

2.1 Analyzing the Alarm

Do the following:

1. Determine whether the board is a Regular MP or a Core MP by comparing

the Local Distinguished Name (LDN) of the PlugInUnit that issued the
alarm with the boards listed in the attribute faultTolerantCoreStates
in the MO ManagedElement.

• If the board is not listed in the attribute, go to Section 2.2 on page 3.

• If the board is listed in the attribute together with another board, go

to Section 2.3 on page 4.

Note: If the node restarts, the alarm ceases. Do a health check again as
described in Step 8 and Step 9. If the alarm is issued again, repeat
this procedure.

2.2 Regular MP
This section is valid for a board that is not a Core MP.

Do the following:

1. Lock the faulty board, using the instruction Lock Board. The Lock type
is Soft lock.

2. Login to the node using the command telnet <IP address> or the
command ssh <IP address>.

3. Identify the link handler path of the faulty board (xxyy00, where xx=SMN
and yy=APN), as described in the hardware configuration. For example,
the board in slot 12 in the main subrack (SMN=00) has the link handler
path 001200.

4. Login to the faulty board using the command lhsh <link handler
path>.

5. Format the volumes on the faulty board, using the command formathd
/d and formathd /p<link handler path>. Example: formathd
/p001200.

6. Restart the board using the instruction Restart Board with restart rank
Cold restart with test, restart reason Unplanned cold with
HW test, and restart information File System Diagnostic Error.

177/1543-CRA 119 0360/10 Uen A | 2014-11-20 3

 File System Diagnostic Error

7. If the board is still locked, unlock the board, using the instruction Unlock
Board.

8. Run health check again, using the action startHealthCheck on the MO

ManagedElement. For information about the status and result of the health
check, see the attribute healthCheckResult.

9. Wait for the health check to finish, by observing the value of

healthCheckResultCode, which is a part of the attribute
healthCheckResult.

10. If the alarm remains, continue with the next step. If the alarm ceases, exit
this procedure.

11. Replace the board, using the instruction for replacing that board.

12. Run health check again, using the action startHealthCheck on the MO
ManagedElement. For information about the status and result of the health
check, see the attribute healthCheckResult.

13. Wait for the health check to finish, by observing the value of
healthCheckResultCode, which is a part of the attribute
healthCheckResult.

14. If the alarm remains, consult the next level of maintenance support.

2.3 Redundant Core MP

This section is valid for a node with two Core MPs, which means that the
node is fault-tolerant.

The most likely fault reason is a file system inconsistency that can be fixed by
formatting the volumes on the affected board. If the alarm still remains after
restarting the board and running health check, a board replacement might
be necessary.

This procedure is normally performed by Ericsson personnel only.

4 177/1543-CRA 119 0360/10 Uen A | 2014-11-20