Contents

Instructions for upgrading from build 3801 (or earlier)

On any Guralp Systems module running Platinum, you can check the system type (to ensure it is an EAM) and the release currently installed by following the Version and serial numbers link in the Summary menu in the left-hand menu pane of the web interface. If your system does not have this menu item, the information is displayed in the Linux system tab of the status page.

In order to upgrade from release 3801 (or earlier) of Platinum to the most recent stable release, there is an extra step required on EAM units. This is because of a change to the Linux system architecture (ABI), which necessitates replacing each file on the unit. A script has been added to the release to do this but the process must be started manually.

Please note this change only applies to CMG-EAM units. CMG-DCM units and CMG-NAM or CMG-NAM64 units are not affected and will upgrade to the most recent Platinum release without intervention.

Preparation

It is highly recommended that this upgrade procedure is not carried out in the field. As part of the process, each system file on the EAM filesystem is replaced, and there is a window of a few seconds during which this replacement cannot be interrupted (e.g. by a power outage). Any interruption at this point will require a more complex recovery procedure which will require contacting . The procedure will take place on the EAM's command line. Please see the EAM manual (section First steps) for instructions on connecting this way. The rest of this document assumes you are connected either over a serial port or over SSH. If you are connected to a remote system using SSH, then it is advisable to use GNU screen to protect your connection. Simply run the command:
screen
and press Enter to clear its banner screen. If your connection is interrupted, whatever is running inside screen will continue to run in your absence, and you can reconnect to it by reconnecting to the system again and running:
screen -r
Ensure the EAM can reach the rsync server for performing the upgrade, and that it is at build 3801, by running the command:
upgrade
Verify at the end of the output that you see the message:
Upgrade complete. Now at platinum-stable build 3801.

Disk space

The upgrade will require approximately 64Mbytes of free space in the EAM's internal flash filesystem. Normally, this amount of space will indeed be free, but it is possible to configure the EAM to use more of its flash for buffering and backfill purposes. Therefore, it is important to verify how much space is available before starting the final upgrade procedure. To do this, run the command:
df -h
(the Unix command "disk free", with "human-readable" units). This will print a summary of how much space is free on the flash filesystems. On some example systems, this command produced the following outputs:
Filesystem                Size      Used Available Use% Mounted on
/dev/root               512.0M    184.3M    327.7M  36% /
/dev/mtdblock3            2.0G    862.3M      1.2G  42% /media/flash_module

Filesystem                Size      Used Available Use% Mounted on
/dev/root               512.0M    141.4M    370.6M  28% /
The line mentioning /dev/root is the important one. It should have at least 64MByte in the Available column. If it does not, some space must be freed; the simplest way to do this is to reconfigure one of the services that stores backfill (gdi2gcf, gdi2miniseed, data-mux-cd11 or gdi-link-tx). Please contact support if you require assistance discovering where space has been used and how to free it.

Performing the upgrade

With the system prepared, it is now time to perform the EABI upgrade. This is done with the command:
EAM-upgrade-to-eabi.sh
This will copy the files from the rsync server onto the EAM, displaying its progress as it goes. This process will take only 2 or 3 minutes if you have a fast connection but depends primarily on connection speed. Once this is done, the files are moved into place, and you will see some messages:
(you can safely ignore Segmentation fault messages above)

:::: Rebooting to complete upgrade.
At this point the system will reboot itself automatically and complete the upgrade process (part of which is automatically migrating all the existing configuration to the new system).

Notes for advanced users

If you use /etc/conf.d/upgrade.local

The EABI upgrade mechanism will also work with systems using local rsync mirrors set up through the file /etc/conf.d/upgrade.local . There are several points to check:
  1. Make sure RSYNC_ADDITIONAL_OPTS is not set in /etc/conf.d/upgrade.local. This variable is used by the EABI upgrade script and must not be overridden.
  2. Check that the rsync module being referred to contains (at least) the directories CMG-DCM-mk4 and CMG-DCM-mk4-eabi .
  3. Check that the firmware version in the CMG-DCM-mk4 directory is up to date: i.e. cat (read) the file CMG-DCM-mk4/etc/build.version to verify that the build number is 3801.

EABI background

The ABI (application binary interface) of a machine specifies common conventions such as the purpose of each CPU register, how functions are called, how data structures are laid out in memory and so on. It is a contract between the operating system (Linux) and the applications that run on it (Platinum). In the last few years, an improved ABI for the ARM architecture has been developed. This brings some incremental advantages to the system itself but the primary user-visible change will be faster floating point emulation. This newly-developed ABI is called the GNU EABI. The EAM was developed before EABI was stable, but the older ABI (now dubbed the OABI for "Old ABI") has slowly been phased out, to the point that more recent compiler and C library versions are difficult (if not impossible) to use with it. This has necessitated a change. Unfortunately, this involves changing all library and executable files on the system, since EABI and OABI are not at all compatible. Along with the change to EABI, Guralp Systems have also upgraded to using the latest stable releases of gcc (4.5 branch) and eglibc (2.12 branch). The CMG-DCM is not affected by this change as, unfortunately, it uses such an old version of the ARM instruction set (ARMv5) that it simply is not supported (the earliest supported instruction set is the ARMv5T). This means that the CMG-DCM is not using an upgraded compiler or C library. However it is running nearly an identical application layer.