No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

The Displayed Version of the EFSC Board Is Still the Old Version After the Metro1000V3 Is Upgraded

Publication Date:  2012-07-25 Views:  32 Downloads:  0
Issue Description
An engineer upgrades the Metro1000V3 from 5.37.02.22 to 5.37.04.12. The upgrade is performed with the packet loading toolkit. The upgrade process completely conforms to the upgrade guide, the software package is successfully loaded, and the upgrade steps are correct. After the upgrade is completed, the engineer queries the versions of the boards. All the versions of the boards except one EFSC board are correct. The version of the EFSC board is displayed as 2.21, although the actual version is 2.24. The engineer separately loads the EFSC board software using the toolkit. The upgrade is normally completed but the version of the EFSC board is still displayed as 2.21. 
Alarm Information
Null
Handling Process
Run the debug command to delete the ne.ini file and ofs2, and then reset the EFSC board. The detailed steps are as follows:
1) Run :ethn-debug-enable:enable to enable the debug command.
2) Run the following commands to delete ofs2 and the ne.ini file:
:ethn-debug:4,"test remove ofs2\hwx\ne.ini"
:ethn-debug:4,"test remove ofs2\hwx\42efs10.dlb"
3) Run the :cfg-reset-board:4,hard command to hard reset the EFSC board.
4) Run the :cfg-get-bdverinfo:4 command to query the EFSC board version information.
5) Run :ethn-debug-enable: disable to disable the debug command.
After ofs2 is deleted, the version of the EFSC board is displayed as 2.42. 
 
Root Cause
When you use the toolkit to upgrade board software, the new software is loaded only to ofs1. The returned data shows that ofs2 of the EFSC board contains the old version of board software whereas ofs1 contains the new version of board software. This indicates that the board software has been successfully loaded to the ofs file system on the EFSC board. Perform an upgrade test for the two suites of software. Both suites of software can normally start. Therefore, the EFSC boards of the existing network run osf2 after they are activated. The following causes are possible when the EFSC boards run ofs2:
1) The relevant command has been run to forcibly run ofs2.
2) ofs1 fails to be started and thus ofs2 is started.
3) ofs2 runs before the upgrade, and continues to run after the EFSC boards of the existing network are upgraded and activated.
The EFSC board does not support the setting of which software to use, and no such operation has been performed. Therefore, the first probability is excluded.
Simulate the upgrade process in the lab. ofs1 can be normally upgraded and started. Therefore, the second probability is also excluded.
Therefore, the cause is ascertained. ofs2 runs before the upgrade and continues to run after the upgrade, although the new software has been successfully loaded to ofs1. 
 
Suggestions
1. How to learn whether ofs1 or ofs2 runs on the NEs?
You cannot directly obtain this information from the existing network environment. Instead, you need to connect a debugging cable to obtain the information.
2. Does the EFSC board have one or two suites of software in normal cases?
Normally the EFSC board has only one suite of software.
3. Is there any other influence on the boards and the NEs after the software on the OFS2 board is deleted?
The board software restarts and the services are interrupted for a while after the software on the OFS2 board is deleted. This, however, does not affect the subsequent running of the NEs and the boards.
In general, the delivered EFSC board loads the software to ofs1 only. In this case, a few boards in the batch of delivered boards are loaded with two suites of board software and the running of these boards is not affected except when these boards are upgraded. 
 

END