Avaya Definity SI, Руководство по обслуживанию, Страница: 2851 / 2968

download update-file
Issue 4 May 2002 A-47 555-233-123
4. The switch may have had difficulty in writing to the hard patch file. Check
the hardware error log for processor/memory board failures.
5. The hard patch file may be full. Issue a “reset system 1". This should cause
valid files to be applied and invalid ones to be erased.
Error on Application of the Patch
A patch may not have been applied for the following reasons:
1. The memory card was write-protected. Remove this protection and issue a
reset system x command
2. The patch identifiers were inconsistent. Run list configuration software
and compare the old_patch identifier with the values in the update file.
3. The LMM encountered a problem with the patch file. This is unlikely
because the same checks, and more, were performed when the file was
downloaded, prior to marking the file valid. This implies that the memory
which stored the update file was corrupted. Apply the back out file
immediately to back out the changes. Run the flash checksum test to make
sure the system is back to its prepatch state. Check the validity of the file
again with the development community and then try redownloading and
applying the patch immediately.
4. The LMM reports a hard error. The symptoms of this is an entry in the
hardware error log for the processor/memory board, if you’re lucky, or
extremely odd switch behavior followed by SPE down mode if you’re not.
The problem is that the LMM couldn’t complete the programming of
memory with the result that memory is in a corrupted state. The only
recovery is to visit the site armed with new software and processor/
memory circuit packs.
In a High or Critical Reliability System, the failure causes a switch to the
standby processor. The hardware on the standby must be repaired and the
patch redownloaded. (There was nothing wrong with the patch)
Good Application - Bad Patch
This error is caused, not by a failure in the download or application, but by a fault
in the patch file itself. To recover from this type of problem, the back out file which
backs out the patch should be downloaded and applied. Clearly, this requires that
the system be sane enough to receive the file correctly and be able to apply it.
In a High or Critical Reliability System, the user has about eight minutes to
recognize that a problem exists and force an interchange to the standby
processor. If this can be done, the file on the newly active processor can be
invalidated using a file containing a destroy tuple or the wp byte command. The
standby can be restored to a normal state using the back out file.