MENU

Nokia Siemens Networks

WCDMA RAN, Rel. RU20,
Operating Documentation,
Issue 03, Doc Change Delivery
2

Upgrading OMS from RN4.0 OMS to RN5.0

OMS and from RN5.0 OMS 5.24 to RN5.0
OMS 5.26

DN0968343
Issue 01A
Approval Date 2010-07-28
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

The information in this document is subject to change without notice and describes only the
product defined in the introduction of this documentation. This documentation is intended for the
use of Nokia Siemens Networks customers only for the purposes of the agreement under which
the document is submitted, and no part of it may be used, reproduced, modified or transmitted
in any form or means without the prior written permission of Nokia Siemens Networks. The
documentation has been prepared to be used by professional and properly trained personnel,
and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes
customer comments as part of the process of continuous development and improvement of the
documentation.
The information or statements given in this documentation concerning the suitability, capacity,
or performance of the mentioned hardware or software products are given "as is" and all liability
arising in connection with such hardware or software products shall be defined conclusively and
finally in a separate agreement between Nokia Siemens Networks and the customer. However,
Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions
contained in the document are adequate and free of material errors and omissions. Nokia
Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which
may not be covered by the document.
Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO
EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-
TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-
RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED
TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY
OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION
IN IT.
This documentation and the product it describes are considered protected by copyrights and
other intellectual property rights according to the applicable laws.
The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark
of Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective
owners, and they are mentioned for identification purposes only.
Copyright Nokia Siemens Networks 2010. All rights reserved

f Important Notice on Product Safety

Elevated voltages are inevitably present at specific points in this electrical equipment.
Some of the parts may also have elevated operating temperatures.
Non-observance of these conditions and the safety instructions can result in personal
injury or in property damage.
Therefore, only trained and qualified personnel may install and maintain the system.
The system complies with the standard EN 60950 / IEC 60950. All equipment connected
has to comply with the applicable safety standards.

The same text in German:

Wichtiger Hinweis zur Produktsicherheit
In elektrischen Anlagen stehen zwangslufig bestimmte Teile der Gerte unter Span-
nung. Einige Teile knnen auch eine hohe Betriebstemperatur aufweisen.
Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Krperverlet-
zungen und Sachschden fhren.
Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die
Anlagen installiert und wartet.
Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene
Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen.

2 Id:0900d805807c9884
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

Table of Contents
This document has 35 pages.

Summary of Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1 Introduction to Upgrading OMS from RN4.0 OMS to RN5.0 OMS 5.24 and
from RN5.0 OMS to RN5.0 OMS 5.26 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 General Requirements for the Upgrade Procedure . . . . . . . . . . . . . . . . . 7
1.2 Checking Hard Disks Bad Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Checking Hard Disks Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Main Steps of the Upgrade Procedure. . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 Preliminary Requirements and Preparations . . . . . . . . . . . . . . . . . . . . . 13

2.1 Required Software Media and Resources . . . . . . . . . . . . . . . . . . . . . . . 13

3 Changes after Committing Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Converted Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Lost Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Installing Upgrade Image of RN5.0 OMS. . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 Transferring Upgrade Image to OMS. . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Update Timezone Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Separating Upgrade Disk in OMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Installing a Disk Image to Upgrade Disk in Target Environment . . . . . . 21
4.5 Executing Data Conversion Scripts in Target Environment . . . . . . . . . . 25
4.6 Executing Installation Cutover in Target Environment . . . . . . . . . . . . . . 26
4.7 Finalizing New Installation in Target Environment . . . . . . . . . . . . . . . . . 28
4.8 Executing OMS Conversion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.9 Committing System to New Installation . . . . . . . . . . . . . . . . . . . . . . . . . 33

5 Performing a Major Software Upgrade Rollback . . . . . . . . . . . . . . . . . . 34

Id:0900d805807c9884 3
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

List of Figures
Figure 1 Main steps of the upgrade procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 Id:0900d805807c9884
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and Summary of Changes
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

Summary of Changes
Changes between issues are cumulative. Therefore, the latest issue contains all
changes made to previous issues.
Changes between issues 01 (2010-06-29, WCDMA RAN RU20 EP1) and 01A (2010-
07-28, WCDMA RAN RU20 EP1)

Introduction to Upgrading OMS from RN4.0 OMS to RN5.0 OMS 5.24 and from
RN5.0 OMS to RN5.0 OMS 5.26 (1)
Note about possiblity of either replacing faulty disk or performing a new installation
has been added to 1.2 Checking Hard Disks Bad Blocks.
References to /dev/sda disk have been taken out from 1.2 Checking Hard Disks
Bad Blocks as it is unnecessary.
Note from Step 2 of 1.2 Checking Hard Disks Bad Blocks has been removed.

Separating Upgrade Disk in OMS (4.3)

Note concerning upgrade of certificates or keys for RAN1206: Secure File Transfer
has been added.

Finalizing New Installation in Target Environment (4.7)

Note concerning upgrade of trusted CA certificates, signed certificate and private
key for RAN1206: Secure File Transfer has been added.
Instruction on how to copy trusted CA certificates, signed certificate and private key
back to the system has been added.

Id:0900d805807c9cee 5
DN0968343 Issue 01A
MENU
Summary of Changes Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

6 Id:0900d805807c9cee
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and Introduction to Upgrading OMS from RN4.0 OMS to
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26 RN5.0 OMS 5.24 and from RN5.0 OMS to RN5.0 OMS

1 Introduction to Upgrading OMS from RN4.0

OMS to RN5.0 OMS 5.24 and from RN5.0 OMS
to RN5.0 OMS 5.26
The purpose of this document is to describe the upgrade procedure from RN4.0 OMS
to RN5.0 OMS.
This document describes the main steps of the procedure.
g Use this document in upgrading from RN4.0 OMS to RN5.0 OMS.
g Use this document in upgrading from RN5.0 OMS 5.24 to RN5.0 OMS 5.26
For an information on how to perform an upgrade from integrated RNC OMS, see
Upgrading from Integrated RNC OMS to Standalone RNC OMS.

1.1 General Requirements for the Upgrade Procedure

Before starting the upgrade procedure, make sure that the hardware meets the following
requirements:

For the OMS:

MCP18-B B01 plug-in unit (or newer)
2 WDU (HDD) (147 GB)
g RN5 disk support depends on the RNC type. See the minimum requirements below:
73 GB disks are supported in RNC196 and RNC450,
147 GB disks are supported in RNC196, RNC450 and RNC2600.
If disks need to be changed, do this in the RN4 level before the upgrade of OMS from
RN4 to RN5.
Note that two hard disk drives (2 WDU units) are mandatory. Do not remove WDU to
use as a backup during upgrade. Upgrade procedures breaks disk mirroring and
upgrades only one disk (second disk) in the system. That makes software rollback pos-
sible.
g There are different MSU image files for different disk sizes:
MSU_RN5_147G.bz and MSU_RN5_147G.md5 files are relevant to 147 GB
disks,
MSU_RN5_73G.bz and MSU_RN5_73G.md5 are relevant to 73 GB disks.
Make sure to use the correct upgrade image.
g OMS requires that HDS-A and HDS-B SCSI ID parameter is set to 0 (zero) to both
disks. Check that steps included in Technical Note TS-RNC-HW-064 Correct jumper
settings in WDUs when using OMS Radio Controllers WCDMA RNC RN3.0, RN4.0
(available in NOLS) document are executed.
Upgrade procedure commands have to be done on root level (su -).

1.2 Checking Hard Disks Bad Blocks

Follow the steps to check whether the used hard disk /dev/sdb has any bad blocks.

Id:0900d805807c9857 7
DN0968343 Issue 01A
MENU
Introduction to Upgrading OMS from RN4.0 OMS to Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
RN5.0 OMS 5.24 and from RN5.0 OMS to RN5.0 OMS from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

g It is recommended to execute this procedure the day before the upgrade, because
the checking time takes a couple of hours.
g If bad blocks are found on /dev/sdb disk, the upgrade cannot be continued. Either
replace the faulty disk or perform a new installation instead of upgrade.

1 Execute the testing command.

Execute command:

# smartctl -t long /dev/sdb

After running the command, estimated testing time appears in the printout.
g Printed time is not valid, checking bad blocks takes 2-4 hours.
Example

# smartctl -t long /dev/sdb

smartctl version 5.33 [i386-redhat-linux-gnu] Copyright (C)
2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Extended Background Self Test has begun

Please wait 31 minutes for test to complete.
Estimated completion time: Fri Nov 27 17:37:08 2009

Use smartctl -X to abort test

[root@CLA-0(RNC-3) /root]

2 Check the disks information.

When the testing procedure is completed, execute command:

# smartctl -a /dev/sdb

Parameter -a allows to check all the disks information.

Example

# smartctl -a dev/sdb
smartctl version 5.33 [i386-redhat-linux-gnu] Copyright (C) 2002-4 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device: FUJITSU MAW3073NP Version: 4701

Serial number: DAU3P7200NGD
Device type: disk
Transport protocol: Parallel SCSI (SPI-4)
Local Time is: Fri Nov 27 17:05:36 2009 EET
Device supports SMART and is Enabled
Temperature Warning Enabled
SMART Health Status: OK

Current Drive Temperature: 34 C

Drive Trip Temperature: 65 C
Manufactured in week 08 of year 2007

8 Id:0900d805807c9857
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and Introduction to Upgrading OMS from RN4.0 OMS to
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26 RN5.0 OMS 5.24 and from RN5.0 OMS to RN5.0 OMS

Current start stop count: 4 times

Recommended maximum start stop count: 10000 times

Error counter log:

Errors Corrected by Total Correction Gigabytes Total
EEC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 0 2 0 0 0 7771.562 0
write: 0 0 0 0 0 16283.945 0

Non-medium error count: 1104

Error Events logging not supported

SMART Self-test log

Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ]
Description number (hours)
# 1 Background long Self test in progress ... - NOW - [- - -]
# 2 Background long Completed - 22299 - [- - -]
# 3 Background long Completed - 22282 - [- - -]

Long (extended) Self Test duration: 1919 seconds [32.0 minutes]

[root@CLA-0(RNC-3) /root]

3 Check the test logs.

Check the testing results when they have been completed.

Error counter log:

Errors Corrected by Total Correction Gigabytes Total
EEC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 0 0 0 0 0 4887.773 0
write: 0 0 0 0 0 19236.313 0

Legend:
Errors corrected by EEC
An error correction is applied to get perfect data (EEC on-the-fly). If there are
entries in this section, upgrade is possible without a disk change.
Errors corrected by reread/rewrite
This parameter code specifies the counter counting the number of errors that are
corrected by applying retries. If there are entries in this section, change the disk
before upgrade.
Total errors corrected
This counter indicates a total corrected errors.
Total uncorrected errors
Total number of blocks which an uncorrected data error has occurred for. If there
are entries in this section, change the disk before upgrade.

Id:0900d805807c9857 9
DN0968343 Issue 01A
MENU
Introduction to Upgrading OMS from RN4.0 OMS to Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
RN5.0 OMS 5.24 and from RN5.0 OMS to RN5.0 OMS from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

1.3 Checking Hard Disks Settings

After OMS installation VG_62 volume group is always available in device node
/dev/sda and VG_63 volume is always available in device node /dev/sdb. Physical
location of disks cannot be changed after installation, because this can cause fatal
errors in OMS and problems with major software upgrade or disk change features. To
prevent that, hard disks' settings need checking before the upgrade. Use the following
commands:
1. Checking SCSI parameters:
For the 73 GB disks:

# cat /proc/scsi/scsi

Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: FUJITSU Model: MBA3073NP Rev: 4701
Type: Direct-Access ANSI SCSI revision: 03

Host: scsi1 Channel: 00 Id: 00 Lun: 00

Vendor: FUJITSU Model: MBA3073NP Rev: 4701
Type: Direct-Access ANSI SCSI revision: 03

Use the following upgrade files for this hardware configuration:

MSU_RN5_73G.bz
MSU_RN5_73G.md5

For the 147 GB disks:

# cat /proc/scsi/scsi

Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: FUJITSU Model: MBA3147NP Rev: 4701
Type: Direct-Access ANSI SCSI revision: 03

Host: scsi1 Channel: 00 Id: 00 Lun: 00

Vendor: FUJITSU Model: MBA3147NP Rev: 4701
Type: Direct-Access ANSI SCSI revision: 03

Use the following upgrade files for this hardware configuration:

MSU_RN5_147G.bz
MSU_RN5_147G.md5

Correct configuration should be as follows:

Disk 1: scsi0 Channel: 00 Id: 00 Lun: 00

Disk 2: scsi1 Channel: 00 Id: 00 Lun: 00

2. Checking physical volume parameters:

10 Id:0900d805807c9857
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and Introduction to Upgrading OMS from RN4.0 OMS to
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26 RN5.0 OMS 5.24 and from RN5.0 OMS to RN5.0 OMS

# pvdisplay

--- Physical volume ---

PV Name /dev/sdb3
VG Name VG_63
PV Size 132.22 GB / not usable 3.55 MB
Allocatable yes
PE Size (KByte) 4096
Total PE 33847
Free PE 17797
Allocated PE 16050
PV UUID 6D8bIm-hn2E-E3ou-iB8B-mpuv-UoWo-3HYRtt

--- Physical volume ---

PV Name /dev/sda3
VG Name VG_62
PV Size 132.22 GB / not usable 3.55 MB
Allocatable yes
PE Size (KByte) 4096
Total PE 33847
Free PE 17797
Allocated PE 16050
PV UUID eXkt57-ioKU-yvkG-7S39-xVnv-g4zX-3Vmkfg

Correct configuration should be as follows:

LVM volume VG_63 has to be available in device node /dev/sdb
PV Name /dev/sdb3
VG Name VG_63
LVM volume VG_62 has to be available in device node /dev/sda
PV Name /dev/sda3
VG Name VG_62

1.4 Main Steps of the Upgrade Procedure

This chapter describes the phases of the upgrade procedure.

Make a full backup from OMS software before starting the upgrade procedure, for more
! details see section Making a full software backup in OMS

Figure Main steps of the upgrade procedure summarizes the upgrade procedure.

Id:0900d805807c9857 11
DN0968343 Issue 01A
MENU
Introduction to Upgrading OMS from RN4.0 OMS to Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
RN5.0 OMS 5.24 and from RN5.0 OMS to RN5.0 OMS from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

Figure 1 Main steps of the upgrade procedure

The upgrade procedure can be completed remotely including the rollback in case of
upgrade failure.

12 Id:0900d805807c9857
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and Preliminary Requirements and Preparations
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

2 Preliminary Requirements and Preparations

This chapter lists the preliminary checks and preparations needed before the upgrade.
Make sure you have the following before starting the procedure.

2.1 Required Software Media and Resources

The following software media and resources are needed for the upgrade procedure:
RN5.0 OMS installation image MSU_RN5_73G.bz and MSU_RN5_73G.md5 (from
NOLS) or RN5.0 OMS installation image MSU_RN5_147G.bz and
MSU_RN5_147G.md5 (from NOLS)
OMS running on RN4.0 or RN5.0 level with two hard drives
Sufficient disk space (~4GB)
Time needed for the upgrade procedure, about 3 hours
OMS correction for On Top of R_OMS1_<RN5_release> release

Id:0900d8058077cd0d 13
DN0968343 Issue 01A
MENU
Changes after Committing Upgrade Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

3 Changes after Committing Upgrade

This chapter lists items that are converted or lost during the upgrade procedure.

3.1 Converted Items

The following items are converted during the upgrade procedure:
User accounts, passwords and groups
Network and timezone settings
NetAct and RNC integration
Measurement timetables, KPIs and thresholds
Measurement xml files, which are not transferred to NetAct.
Certificates for secure file transfer
UIDs in range 500-9999 and over 60000 are transferred to range 10000-60000
GIDs in range 500-9999 are transferred to range 10000-60000
Self defined groups and assigned permissions
Self defined permissions
LDAP parameter: TLSMode and TLSModeSending (omsFragmentId=TLS,
omsFragmentId=Network, omsFragmentId=System,
fsFragmentId=OMS, fsClusterId=ClusterRoot)
g UIDs and GIDs are converted automatically to right range. Username, groups and
permissions defined by enduser are upgraded.

3.2 Lost Items

The following items are lost during the upgrade procedure:
Alarm database is not transferred.
Measurement database is not transferred.
Personal files of each user. Although they can be transferred manually to RN5.0 if
needed.
Logfiles from /var/log
The SSH keyfiles are renewed. SSH clients complain about changed keyfile when
connecting to OMS, it's a normal behavior and disappears when the new keyfile is
accepted.
User defined crontab definitions (system and user specific)
Nemuadmins permission and password changes (will be recreated with RN5.0
default values). The RN5.0 defaults are:
Password: nemuuser
Modify permissions to NWI3 interfaces
Modify permissions to interfaces used by ApplicationLauncher GUI interfaces
(EMI interfaces and LDAP)
omsFtpUser password is not upgraded in RN4.0 OMS to RN5.0 OMS upgrade,
because the account is moved from LDAP to /etc/passwd what is implied by a
performance reasons. New password is asked in Finalizing New Installation in
Target Environment.
omsFtpUser password is upgraded in RN5.0 OMS to RN5.0 OMS upgrade.

14 Id:0900d8058077cd03
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and Installing Upgrade Image of RN5.0 OMS
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

4 Installing Upgrade Image of RN5.0 OMS

4.1 Transferring Upgrade Image to OMS

Purpose
Upgrade image can be transferred to OMS with scp command or for example WinSCP.
It is also possible to install MSU image over network, then image file transfer to OMS is
not needed. This needs ssh (scp) support from file server.
In case of RN5.0 MSU image installation is done over network, step Transfer of upgrade
image to OMS using scp is not needed.

Steps

1 Check disk allocations and free space

Follow the disk allocation check steps to prevent lack of disk space errors during image
transfer.
a) Login to the OMS with Nemuadmin account.
b) Take root access with su - command.
c) Use df -h command to see disk allocation.
# df -h

Filesystem Size Used Avail Use% Mounted on

tmpfs 200M 2.4M 198M 2% /tmp
none 2.0G 284K 2.0G 1% /dev
/dev/md0 4.9G 1.9G 2.8G 40% /var/mnt/local/localimg
/dev/md3 194M 61M 123M 34% /var/mnt/local/cmf
/dev/md1 29G 21G 6.1G 79% /var/mnt/local/sysimg
/dev/md4 2.0G 310M 1.6G 17% /var/mnt/local/log
/dev/md5 8.7G 127M 8.1G 2% /var/mnt/local/backup
/dev/md1 29G 21G 6.1G 79% /var/mnt/remote/sysimg
/dev/md4 2.0G 310M 1.6G 17% /var/mnt/remote/log
/dev/md8 291M 181M 96M 66% /var/mnt/local/MySQL_DB_CosNaming
/dev/md0 4.9G 1.9G 2.8G 40% /var/mnt/local/PMNG/omes/result_files
/dev/md0 4.9G 1.9G 2.8G 40% /var/mnt/local/PMNG/plans/new_plans
/dev/md0 4.9G 1.9G 2.8G 40% /var/mnt/local/PMNG/omes/result_files
/dev/md0 4.9G 1.9G 2.8G 40%
/var/mnt/local/PMNG/store/measurement_schedule_repository
/dev/md10 485M 38M 422M 9% /var/mnt/local/tomcatplat
/dev/md16 194M 126M 58M 69% /var/mnt/local/MySQL_DB_AidS
/dev/md17 15G 2.2G 12G 16% /var/mnt/local/MySQL_DB_PMData
/dev/md9 2.0G 1.2G 740M 61% /var/mnt/local/MySQL_DB_Alarm

Id:0900d805807cd435 15
DN0968343 Issue 01A
MENU
Installing Upgrade Image of RN5.0 OMS Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

Upgrade image needs about 2.5 gigabytes of free space. It can be transferred to
/var/mnt/local/sysimg/home/_nokfsoperator directory.
This directory is stored physically on sysimg partition, which size is 29G with 73G
disks and 39G with 147G disks.
In df -h output, /var/mnt/local/sysimg partition free disk space can be
checked from Avail column (6.1G in printout).
With command du -h --max-depth=1 /var/mnt/local/sysimg/ it is
possible to find unnecessary big files, if there is not enough free space on sysimg
partition.
Example:
Finding directories that take a lot of disk space:
# du -h --max-depth=1 /var/mnt/local/sysimg/

16K /var/mnt/local/sysimg/lost+found
4.0K /var/mnt/local/sysimg/proc
4.0K /var/mnt/local/sysimg/sys
4.0K /var/mnt/local/sysimg/selinux
4.0K /var/mnt/local/sysimg/dev
17M /var/mnt/local/sysimg/var
8.0K /var/mnt/local/sysimg/mnt
1.9G /var/mnt/local/sysimg/opt
34M /var/mnt/local/sysimg/boot
6.7M /var/mnt/local/sysimg/etc
141M /var/mnt/local/sysimg/lib
598M /var/mnt/local/sysimg/usr
3.8M /var/mnt/local/sysimg/bin
36K /var/mnt/local/sysimg/home
4.0K /var/mnt/local/sysimg/initrd
4.0K /var/mnt/local/sysimg/media
68K /var/mnt/local/sysimg/root
14M /var/mnt/local/sysimg/sbin
4.0K /var/mnt/local/sysimg/srv
216K /var/mnt/local/sysimg/tmp
4.0K /var/mnt/local/sysimg/tftpboot
280M /var/mnt/local/sysimg/sets
12K /var/mnt/local/sysimg/ldif_in
18G /var/mnt/local/sysimg/OMSftproot
//Note that this directory takes 18G

16K /var/mnt/local/sysimg/pstate
21G /var/mnt/local/sysimg/

# du -h --max-depth=1 /var/mnt/local/sysimg/OMSftproot/

228K /var/mnt/local/sysimg/OMSftproot/key_counter
140K /var/mnt/local/sysimg/OMSftproot/RUIM_XML
4.0K /var/mnt/local/sysimg/OMSftproot/OMSLicenceManager
4.0K /var/mnt/local/sysimg/OMSftproot/internal_reports
1.2M /var/mnt/local/sysimg/OMSftproot/xmlfiles
4.0K /var/mnt/local/sysimg/OMSftproot/xmlfilesBU
12K /var/mnt/local/sysimg/OMSftproot/Nwi3LMAgent

16 Id:0900d805807cd435
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and Installing Upgrade Image of RN5.0 OMS
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

18G /var/mnt/local/sysimg/OMSftproot/SWPackages
//Note that this directory takes 18G

32K /var/mnt/local/sysimg/OMSftproot/cmplan
12K /var/mnt/local/sysimg/OMSftproot/etc
608K /var/mnt/local/sysimg/OMSftproot/bin
2.8M /var/mnt/local/sysimg/OMSftproot/lib
748K /var/mnt/local/sysimg/OMSftproot/usr
9.7M /var/mnt/local/sysimg/OMSftproot/AuditTrailXMLFiles
16M /var/mnt/local/sysimg/OMSftproot/

In this example, user can remove unnecessary files from the directory below to get
free disk space: /var/mnt/local/sysimg/OMSftproot/SWPackages.
g Check also other filesystems. There should be at lease 10% free disk space
before the start of MSU.

2 Check the localimg directory size

If /var/mnt/local/localimg directory is running out of disk space, remove all
*.core files from /var/crash directory using command:

# rm /var/crash/*.core

3 Transfer of upgrade image to OMS using scp

Use scp command or WinSCP to transfer upgrade image and checksum to the OMS.
For example:
# scp MSU_RN5.bz _nokfsoperator@<Upgraded OMS
IP>:/var/mnt/local/sysimg/home/_nokfsoperator
# scp MSU_RN5.md5 _nokfsoperator@<Upgraded OMS
IP>:/var/mnt/local/sysimg/home/_nokfsoperator

Id:0900d805807cd435 17
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

4.2 Update Timezone Information

Purpose
Contents of files /etc/timezone and /etc_ondisk/timezone needs to be
checked and updated if needed.
Timezone infomation might be wrong in files above, if OMS is installed from USB stick
or if timezone has been changed after installation.

Steps

1 Check used timezone

To check used timezone, enter the following command:
# cat /etc/sysconfig/clock

Example printout:

ZONE="Europe/Berlin"
UTC="true"

Check the content of the file /etc/timezone with command:

# cat /etc/timezone
Example printout, when the timezone is correct (the same timezone in both files
/etc/sysconfig/clock and /etc/timezone).

Europe/Berlin

Example printout, when the timezone is different in files /etc/sysconfig/clock and

/etc/timezone:

Europe/Helsinki

Timezone should be the same in files /etc/sysconfig/clock and

/etc/timezone.

2 Do not change timezone if it is correct

Do not change timezone if it is correct.

3 Update timezone if it is different

1. Automatic update
Execute commands:

# grep ZONE /etc/sysconfig/clock|cut -d '"' -f 2 >/etc/timezone

# grep ZONE /etc/sysconfig/clock|cut -d '"' -f 2 >/etc_ondisk/timezone

Check timezone with command:

# cat /etc/timezone

Timezone should be the same as in file /etc/sysconfig/clock.

18 Id:0900d8058077cd0a
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

2. Manual update
Execute the following command to check correct timezone:
# cat /etc/sysconfig/clock

Example printout:

ZONE="Europe/Berlin"
UTC="true"

In this example, correct timezone is Europe/Berlin (without quotation marks).

Replace existing timezone in /etc/timezone and /etc_ondisk/timezone
files with the correct timezone:

# nano /etc/timezone
# nano /etc_ondisk/timezone

Execute the following command to check timezone:

# cat /etc/timezone

Example printout:
Europe/Berlin

Timezone should be same as in file /etc/sysconfig/clock.

Id:0900d8058077cd0a 19
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

4.3 Separating Upgrade Disk in OMS

Purpose
This step breaks disk mirroring before installing the upgrade disk image. After disk mir-
roring is switched off one of the OMS disks will be upgraded to RN5.0 OMS and the
second one stays at old level as a backup for the rollback procedure.

Steps

1 Separate the upgrade disk.

To separate OMS mirrored disk, enter the following command:
# fsswcli --major --disklock
After you have given the command, the following text appears on the screen:

installing boot on /dev/sda /dev/sda1

installing boot on /dev/sdb /dev/sdb1
Request details
...
Prints removed from the middle, since the command output is
quite long.
...
mdadm: set /dev/VG_63/localimg_CLA-0 faulty in /dev/md0
mdadm: hot removed /dev/VG_63/localimg_CLA-0
Nemuadmin: Detaching /dev/VG_63/localimg_CLA-0 from /dev/md0
succeeded
[root@CLA-0(RNC-1) /root]

Note that during upgrade time disks are no longer fault tolerant, but rollback to old level
is possible. When commit stage is issued at the end of the upgrade procedure OMS will
become fault tolerant once again, but upgrade rollback is no longer possible.
g Ignore this note if RAN1206: Secure File Transfer feature is not used
Certificates or keys for RAN1206: Secure File Transfer are not upgraded. Before
cutover it is possible to collect current certificates and keys and store them on an
external device or media. For more information on needed certificates and keys, see
Activating RAN1206: Secure File Transfer.

20 Id:0900d805807cd4c5
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

4.4 Installing a Disk Image to Upgrade Disk in Target Environ-

ment
Purpose
To overwrite the content of the OMS disk with the disk image of the new installation. This
can be done either locally or remotely over the network.

Before you start

Before installing the image, make sure that MSU_RN5_<disk size>.md5 sum file
exists in the same directory as MSU_RN5_<disk size>.bz file.
If upgrade from RN4.0 CD1.0 is performed, checking the md5 sum is done manually.
If upgrade from RN4.0 CD2.0 or from RN5.0 is performed, checking the md5 sum is done
during fsswcli --major --install -u MSU_RN5_<disk size>.bz command
by default.
If md5sum fails, retransfer the upgrade image from NOLS.

Steps

1 Install a disk image to upgrade disk.

Note that writing the image takes a long time, about 2 hours. Do not interrupt the
process, even though during this time upgrade gives very little output. First records
in/records out output is shown when about half of the upgrade process has been
performed, so be patient.
If OMS does not have enough free disk space to allocate upgrade image, it can be
installed over the network.

If terminal is killed or for example putty window is closed (using X button in the upper
right corner), install process crashes.
If network connection is lost, install process continues.
If install process is executed as a backround process by using & parameter, killing
terminal or closing for example putty window does not interrupt the installation
process.
If install process is interrupted by any reason, it is possible to perform it again by exe-
cuting fsswcli --major --install command.
If install process is interrupted by any reason, it is possible to restore the old software
version by executing fsswcli --major --commit command.
a) Installing a disk image locally into OMS disk.
To install a disk image use the following command:

Id:0900d8058077cd1a 21
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

If upgrade from RN4.0 CD1.0 level is performed:

# md5sum -c MSU_RN5_73G.md5
or
# md5sum -c MSU_RN5_147G.md5
and
# fsswcli --major --install MSU_RN5_73G.bz
or
# fsswcli --major --install MSU_RN5_147G.bz
If upgrade from RN4.0 CD2.0 or from RN5.0 level is performed:
# fsswcli --major --install -u MSU_RN5_73G.bz
or
# fsswcli --major --install -u MSU_RN5_147G.bz

Example: Installing a disk image file

To upgrade from RN4.0 CD2.0 or from RN5.0 level and to install a disk image file
MSU_RN5_147G.bz from the directory
/var/mnt/local/sysimg/home/_nokfsoperator, enter:
# fsswcli --major --install -u
/var/mnt/local/sysimg/home/_nokfsoperator/MSU_RN5_147G.bz
Note that
/var/mnt/local/sysimg/home/_nokfsoperator/MSU_RN5_147G.bz is
location and name of upgrade image, if it was transferred to OMS.
b) Installing a disk image file over the network.
To upgrade from RN4.0 CD2.0 level and install a disk image file
MSU_RN5_147G.bz from the directory /dir in a remote host running secure
shell (SSH), user@host, enter:
# fsswcli --major --install -u user@host:/dir/MSU_RN5_147G.bz

Example: Installing a disk image file over network

# fsswcli --major --install -u
root@10.8.122.133:/root/MSU_RN5_147G.bz

0 logical volume(s) in volume group "VG_63" now active

File descriptor 63 left open
WARNING: Wiping physical volume label from /dev/sdb2 of
volume group "VG_63"
Labels on physical volume "/dev/sdb2" successfully wiped
root@10.8.122.133's password:

4718914+1 records in
4718914+1 records out

143638992+0 records in
143638992+0 records out
Request details

22 Id:0900d8058077cd1a
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

destination device: /dev/sdb

bootloader file: /boot/fsloader.b
primary hard drive: 2 (0x81)
secondary hard drive: -127 (0x00)
boot counter: 0
restore MBR from: (null)
copy MBR to: /boot/sdb.mbr

Scanning '/dev/sdb' ...

major version: 3
minor version: 2
boot drive: 128 (0xFF)
stage2 address: 0x2000
stage2 sector: 0x00000001
stage2 segment: 0x0200
MBR OK

Checking '/boot/fsloader.b' image ...

signature: FSLXX
primary disk (default): 1 (0x80)
secondary disk (default): 2 (0x81)
boot counter (default): 0
Image OK

Copying MBR to '/boot/sdb.mbr' ... done

Applying requested settings ... done
Installing bootloader ... done
Executing the disk lock operation for CLA-0 with disk
/dev/sdb
[root@CLA-0(RNC-1) /root]

If connection to OMS is lost during MSU installation, the script will continue by itself.
Check from /var/log/msu.log file that installation was finished. An example
printout can be found at the end of the log file.

2 Check if installation is performed correctly

For the 73 GB disks configuration:
Check from the printout if disk size of 73 GB is copied. Expected output is as follows:

Disk size to be copied: 73.54 GB

Install started
Please wait for some time to show progress...
Copied 73.54 GB

If copied data is, for example, a size of 20 GB, installation fails. Therefore, output is as
follows:

Disk size to be copied: 73.54 GB

Install started

Id:0900d8058077cd1a 23
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

Please wait for some time to show progress...

Copied 20.84 GB

For the 147 GB disks configuration:

Check from the printout if disk size of 147 GB is copied. Expected output is as follows:

Disk size to be copied: 147.08 GB

Install started
Please wait for some time to show progress...
Copied 147.08 GB

If copied data is, for example, a size of 20 GB, installation fails. Therefore, output is as
follows:

Disk size to be copied: 147.08 GB

Install started
Please wait for some time to show progress...
Copied 20.84 GB

If installation fails, do not perform cutover operations. Commit the system to the old level
by executing command:

# fsswcli --major --commit

Before performing another installation, check if there is any faulty disk in the system.

24 Id:0900d8058077cd1a
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

4.5 Executing Data Conversion Scripts in Target Environment

Purpose
To execute the conversion scripts.

Steps

1 Execute data conversion scripts.

Execute command:
# fsswcli --major --convert

Example: Data conversion

# fsswcli --major --convert

Mounting compatibility partition

Executing the disk unlock operation for CLA-0 with disk
/dev/sdb
Executing the disk lock operation for CLA-0 with disk /dev/sdb
Mounted: /dev/sdb2 /var/mnt/upgrade
...
Printout has been removed from the middle since the command
output is quite long.
...
READY! Stashed old information: passwd, shadow and group files
are now ready: they will be copied by the system to a correct
place in the new system. LDAP information is not: this needs
the fsumimporter!
All done, unmounting compatibility partition

Id:0900d805807b1761 25
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

4.6 Executing Installation Cutover in Target Environment

Purpose
To separate the live disk from the system and cancel the separation of the upgrade disk.

Before you start

Make a backup of trusted CA certificates, signed certificate and private key if feature
RAN1206 is used. Follow the steps:
1. Create directories for trusted CA certificates, signed certificate and private key in
/home/Nemuadmin directory.

Login to OMS with SSH as Nemuadmin and execute commands:

# mkdir /home/Nemuadmin/trusted
# mkdir /home/Nemuadmin/signed

2. Copy trusted CA certificates, signed certificate and private key to local directories.
2.1 Copy trusted CA certificates for the HTTPS client to
/home/Nemuadmin/trusted/ directory.

Execute command:
# cp
/var/opt/Nokia/OMS/OMSPlatform/SS_Inet/OMSFTP/certificates
/*.pem /home/Nemuadmin/trusted/

Allow Nemuadmin to copy the files. Change access rights to the files using
command:
# chmod +r /home/Nemuadmin/trusted/*

2.2 Copy signed certificate and private key for HTTPS server
/home/Nemuadmin/signed/ directory

Execute command:
# cp /opt/Nokia/SS_HTTPDPlat/etc/*.pem
/home/Nemuadmin/signed/

Allow Nemuadmin to copy the files. Change access rights to the files using
command:
# chmod +r /home/Nemuadmin/signed/*

3. Copy trusted CA certificates, signed certificate and private key to external device
(another computer) using WinSCP.

Login to OMS with WinSCP as Nemuadmin (root login is not allowed). Copy certifi-
cates and private key to external directory.

Steps

1 Execute installation cutover

Execute command:

26 Id:0900d805807b7a1a
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

# fsswcli --major --cutover

This command automatically initiates the OMS restart. OMS will restart with same IP
address. During upgrade OMS regenerates it is SSH keys so SSH connection to the
OMS will inform about changed SSH key. Change has to be accepted before SSH client
accepts connection.

Example: Cutover
# fsswcli --major --cutover

Request details
destination device: /dev/sdb
bootloader file: /boot/fsloader.b
primary hard drive: 1 (0x80)
secondary hard drive: -127 (0x00)
...
Printout has been removed from the middle since the command
output is quite long.
...
fshascli --nowarning --restart /
/ is restarted successfully

g OMS is restarted twice during cutover.

Id:0900d805807b7a1a 27
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

4.7 Finalizing New Installation in Target Environment

Purpose
To finalize the new installation. The restart of the OMS after executing installation brings
the system up with the new installation. Software management automatically executes
the updater script (executes the import scripts) and distributes configuration files to the
software set of the new base delivery installation.
g Ignore this note if RAN1206: Secure File Transfer feature is not used
Certificates or keys for RAN1206: Secure File Transfer are not upgraded. Follow the
Activating RAN1206: Secure File Transfer procedure before executing the post-con-
figuration script.

Before you start

Copy trusted CA certificates, signed certificate and private key back to the system.
Follow the steps:
1. Login to OMS with WinSCP as Nemuadmin (root login is not allowed).

2. Copy trusted CA certificates, signed certificate and private key back to proper direc-
tories in OMS (/home/Nemuadmin/trusted/ and
/home/Nemuadmin/signed/) using WinSCP.

3. Login to OMS with SSH as Nemuadmin.

Change as root with su - command. Change access rights to certificates and private
key. Execute commands:

# chmod 444 /home/Nemuadmin/trusted/*.pem

# chmod 444 /home/Nemuadmin/signed/cert.pem

All the certificates have read attribute for every user.

# chmod 600 /home/Nemuadmin/signed/private.pem

Private key has read and write attribute only for root.

Copy trusted CA certificates, signed certificate and private key back to original loca-
tion. Execute commands:

# cp /home/Nemuadmin/trusted/*
/var/opt/Nokia/OMS/OMSPlatform/SS_Inet/OMSFTP/certificates/
# cp /home/Nemuadmin/signed/* /opt/Nokia/SS_HTTPDPlat/etc/

28 Id:0900d805807cd4a1
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

4. Take certificates and private key into use.

Execute commands:
# fshascli -l /HTTPDPlat
# rm -rf /tmp/HTTPDPlat
# fshascli -u /HTTPDPlat
# c_rehash
/var/opt/Nokia/OMS/OMSPlatform/SS_Inet/OMSFTP/certificates

Steps

1 Login to OMS with SSH as Nemuadmin, the password is nemuuser

2 Change as root with command su -

3 Execute post-configuration script

Execute command:
# fsswcli --major --postconfigure
Postconfig asks several questions unlike normal installation. See the prinouts for how to
answer these questions.

Node CLA-0 unlocked

Do you want to create partitions for SAN-1 and up (y/n) [y]: n
Do you want to synchronize the CLA-0 system time to other nodes
(y/n) [y]: y
Do you want to execute noderc level 5 scripts (y/n) [y]: y

You are root, proceeding

Executing modifyOMSSettings.sh

Using FTP RG IP address

OMS FTP server IP address is 10.121.69.14

Type omsFtpUser password [press ENTER to use default]:

You set following settings:

OMS FTP IP = 10.121.69.14
FTP Username = omsFtpUser
FTP Password = ******

Are these parameters correct (yes/no)?

yes

Executing pleas wait...

Changing password to ldap

Changing password for user omsFtpUser.
passwd: all authentication tokens updated successfully.

Id:0900d805807cd4a1 29
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

writing settings to LDAP

modifyOMSSettings.sh finished

This question is asked, if only one ethernet cable from OMS is connected:
OMS binds both eth0 and eth1 to single bond in order to gain network redundancy.
However, if OMS is connected only with single network cable, alarms are raised.

Do you want to disable alarm monitoring for eth1?

answer 1 to disable eth1 alarms and restart FSNodeOSServer

answer 2 to enable eth1 alarms and restart FSNodeOSServer
answer 3 to exit

Answer 1, if eth1 cable will not be connected.

Do you want to unlock the RecoveryGroups and RecoveryUnits of

the cluster (y/n) [y]: y

Unlock them all in a single step? (y/n) [y]: y

After postconfig is executed the following lines should be printed to the screen:

(postConfig.sh) FINISHED SUCCESSFULLY

Results from the run are in /var/log/postconfig_yyyy-mm-dd-
hhmmss.log

where yyyy-mm-dd-hhmmss is year, day, month and time of when postconfig was exe-
cuted.
If users account is locked because too many login failure (wrong password),
account can be unlocked with command:
# pam_tally2 -f /var/log/tallylog -u <account> -r

If secure file transfer licence is enabled in RNC, but NetAct does not support secure
file transfer, then LDAP parameter omsParameterId=TLSMode,
omsFragmentId=TLS, omsFragmentId=Network, omsFragmentId=System,
fsFragmentId=OMS, fsClusterId=ClusterRoot has to be set to
TLSMode=Off with ParameterTool. Otherwise NetAct cannot get files from OMS.
Parameter change is made by writing the new value Off by hand. This operation is
not accessible in the pulldown menu.
g Download and install new version of Application Launcher to upgraded OMSs. Old
versions are not working.

30 Id:0900d805807cd4a1
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

4.8 Executing OMS Conversion

Purpose
To complete user/group/permission LDAP data, PM database conversions and transfer
measurements XML files to the new system.

Steps

1 Execute OMS conversion.

Enter:
# /opt/Nokia/SS_OMSINST/msu/Complete_MSU_Upgrade.sh

Example: An example of Complete_MSU_Upgrade.sh

# /opt/Nokia/SS_OMSINST/msu/Complete_MSU_Upgrade.sh

Starting hoonaaDB
ReadLogConfig( false )
read value dwFlags=3l
trace path and file: /var/log/oms/HoonaaDB_trace.txt
logging prefs file:
file:///opt/Nokia/SS_PlaCommon/config/OMSLogging_prefs.xml
LogManager OK
TraceHandler OK
SyslogHandler OK

Reading configuration...

startDocument

endDocument

startDocument

endDocument found 91 Measurements

Opening database connection...
Checking kpi table...
Checking thres_rule table...
Deleted threshold evaluation for rule "upgrade2"
Deleted threshold rule "upgrade2"
Converting thres_eval table...
All procedures completed successfully

Do you want to import BTS secure file transfer certificates?

Answer yes, if BTS secure file transfer certificates are needed

to import from old system.
Answer no, if BTS secure file transfer certificates are not
needed to import from old system

Id:0900d8058077cd13 31
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

When Complete_MSU_Upgrade is finished the system is on RN5.0 level and ready to

use. Rollback is still possible at this point.

2 Fix activate set --single switch usage

Execute the following command:

# sed "574 s/shift 2/shift 3/" -i /opt/Nokia_BP/sbin/fsswcli

or edit file /opt/Nokia_BP/sbin/fsswcli with nano:

# nano /opt/Nokia_BP/sbin/fsswcli

and replace shift 2 with shift 3 in line 574.

g In RN5.0 it is possible to install the correction when only one disk is available. To
activate a set on a single hard disk, add --single parameter to the increment
installation command:

# fsswcli --set --activate --single <SW SET NAME>

Example: Activating set on a single hard disk

Execute command:

# fsswcli --set --activate --single R_OMS1_5.26.debug_oms.corr1

32 Id:0900d8058077cd13
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

4.9 Committing System to New Installation

Purpose
To complete the major software upgrade and make the system run with normal redun-
dancy.

Summary
After finalizing the installation, you must observe the system behavior with the new soft-
ware. Alarms and transferred measurements are good sign of successful the upgrade.
If you notice some problems that cannot be fixed, you may have to perform a rollback to
the old installation. For more instructions, see Performing a Major Software Upgrade
Rollback.

Steps

1 If you are convinced that the new installation is running without problems,
commit the system to the new installation.
Enter:
# fsswcli --major --commit
g The rollback is no longer possible after executing the fsswcli --major --
commit command. Please be patient, committing takes about 40 minutes. Do not
close the connection and do not stop the script.

Id:0900d8058078298d 33
DN0968343 Issue 01A
MENU
Performing a Major Software Upgrade Rollback Upgrading OMS from RN4.0 OMS to RN5.0 OMS and
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

5 Performing a Major Software Upgrade

Rollback
Purpose
To perform a rollback to the old software installation after a major software upgrade. This
is done if the new software installation does not work properly.

Summary
During a major software upgrade, when the system is started with the new installation
for the first time, you must observe carefully the system behavior with the new software.
If you notice some problems, a rollback to the old installation might be necessary. This
is done by initiating a cutover from the new installation to the old one and then commit-
ting the system back to the old installation.
The procedure is divided into steps according to the different fsswcli commands
needed. In order to perform the rollback successfully, the commands must be executed
in this particular order.

Steps

1 Execute installation cutover.

In this case, the current live disk is the upgrade disk. Executing installation cutover for
the second time means restarting the system with the old installation; that is, separating
the upgrade disk from the system and cancelling the separation of the other disk that
contains the old installation.
Use the command fsswcli --major --cutover to execute installation cutover.
This command automatically initiates the cluster restart.
# fsswcli --major --cutover
g Steps 2 and 3 are mandatory to run before new upgrade.

2 Unlock the cluster.

The restart brings the system up again with the old installation.
Use the command fshascli -u / to unlock OMS.
# fshascli -u /
Check locked RGs with command:
# zrg -l /
and unlock RGs with command:
# fshascli -u /MeaHandler
# fshascli -u /PMGeneric
Wait until all RGs are enabled. Execute command to check the status:
# zrg -d
There should be no RGs listed in the printout. Enabling RGs takes about 2 minutes.

34 Id:0900d8058079c023
DN0968343 Issue 01A
MENU
Upgrading OMS from RN4.0 OMS to RN5.0 OMS and Performing a Major Software Upgrade Rollback
from RN5.0 OMS 5.24 to RN5.0 OMS 5.26

3 Commit the system to the old installation.

To make the system run again with full redundancy, you must commit it back to the old
installation.
Use the command fsswcli --major --commit to commit the system to the old
installation and finalize the rollback procedure.
For more instructions, see Committing System to New Installation.
# fsswcli --major --commit

Id:0900d8058079c023 35
DN0968343 Issue 01A