Updating a Platinum upgrade pod.

How to refresh your Platinum upgrade pod to hold the latest firmware revision.

Requirements

One or more platinum upgrade pods to be updated; and
A Linux computer with an available USB connector and an internet connection

Procedure

The procedure consists of three steps:

Mount the pod;
Update the content; and
Unmount the pod.

It is not currently possible to perform this procedure from a Windows PC as Windows does not support the required ext3 filesystem and the available drivers all have limitations which it is not possible to overcome. Users of other operating systems may still be able to perform the update - please contact support for further information.

Mounting the pod

Most modern Linux systems will automatically mount a USB memory device, such as the upgrade pod, when it is connected. The precise details vary between distributions. The examples given here are for Ubunutu Desktop but the principals are similar in most cases. Consult your operating system documentation if you are unsure.

It is necessary to know where the pod has been mounted in order to perform the upgrade. Some operating systems will issue an alert telling you the mount point but, if yours does not, the following steps will allow you to discover it. If you know the mount point, you can skip to Updating the content.

When the USB memory device is first inserted, the operating system kernel will assign a device name to it. This is normally something like sdf: "sd" shows that the SCSI disk emulation is being used to address the device and the final letter, 'f' in this case, is allocated dynamically in order to generate a unique device name. Filesystems on the device are allocated numerical suffices so the first filesystem on sdf would be sdf1, the second sdf2 and so forth. The firmware pod typically only has one filesystem on it.

To discover the name, insert the pod into a free USB socket, wait for a few seconds to allow the process to complete, and then type the dmesg command. The output will typically look like this:

[2476881.712064] usb 1-8: new high speed USB device using ehci_hcd and address 12
[2476881.847080] usb 1-8: configuration #1 chosen from 1 choice
[2476881.848095] scsi9 : SCSI emulation for USB Mass Storage devices
[2476881.849091] usb-storage: device found at 12
[2476881.849097] usb-storage: waiting for device to settle before scanning
[2476886.848307] usb-storage: device scan complete
[2476886.849406] scsi 9:0:0:0: Direct-Access     Ut163    USB2FlashStorage 0.00 PQ: 0 ANSI: 2
[2476886.850221] sd 9:0:0:0: Attached scsi generic sg6 type 0
[2476886.854358] sd 9:0:0:0: [sdf] 1974271 512-byte logical blocks: (1.01 GB/963 MiB)
[2476886.855747] sd 9:0:0:0: [sdf] Write Protect is off
[2476886.855754] sd 9:0:0:0: [sdf] Mode Sense: 00 00 00 00
[2476886.855758] sd 9:0:0:0: [sdf] Assuming drive cache: write through
[2476886.859737] sd 9:0:0:0: [sdf] Assuming drive cache: write through
[2476886.859746]  sdf: sdf1
[2476886.991277] sd 9:0:0:0: [sdf] Assuming drive cache: write through
[2476886.991293] sd 9:0:0:0: [sdf] Attached SCSI removable disk
[2476889.761952] kjournald starting.  Commit interval 5 seconds
[2476889.770516] EXT3 FS on sdf1, internal journal
[2476889.770525] EXT3-fs: mounted filesystem with writeback data mode.

From this, it can be seen that the SCSI disk subsystem (sd) has allocated the device name sdf to the memory stick and, from the second-to-last line, that the filesystem on the pod has been allocated the name sdf1. The last line shows us that the pod’s filesystem has been mounted; we now need to discover where.

The command mount lists all mounted filesystems, along with their mount-points. The output typically looks like this:

/dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro)
proc on /proc type proc (rw)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
none on /proc/bus/usb type usbfs (rw)
none on /var/lib/ureadahead/debugfs type debugfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/me/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=me)
/dev/sdf1 on /media/Pt-firmware type ext3 (rw,nosuid,nodev,uhelper=devkit)

Inspection of this output shows us (in the last line) that our sdf1 filesystem has been mounted on the directory /media/Pt-firmware.

Updating the content

To update the contents of the pod, we need to change to the directory on which it is mounted and then use the rsync command to compare the current contents with the latest version on the Güralp server and download any changes.

To do this, issue the following commands (substituting in place of /media/Pt-firmware the mount point as previously determined):

	cd /media/Pt-firmware
	for ARCH in CMG-DCM-mk2x CMG-DCM-mk4 CMG-NAM CMG-NAM64 ; do
	sudo rsync -avz --del rsync://rsync.guralp.com/platinum-stable/$ARCH $ARCH
	done

The sudo command runs the following command as superuser (root). This is neccessary in order to transfer files owned by the user "root". You will be prompted for your password for security reasons.

The line beginning for lists codes for each of the architectures on which Platinum firmware is currently supported. If you know that you will never need one or more of these architectures, simply omit its code from the list. The meaning of each code is given here:

CMG-DCM-mk2x - CMG-DCM data communication modules
CMG-DCM-mk4 - CMG-EAM embedded acquisition modules
CMG-NAM - CMG-NAM network acquisition modules
CMG-NAM64 - CMG-NAM64 64-bit network acquisition modules

Unmounting the pod

It is essential to unmount the pod before removing it: this allows the operating system time to ensure that all files have been written to the device before it is disconnected. You first need to change to a directory other than the mount point: Linux cannot unmount a device if it is the current working directory of a user or process. The cd command changes to your home directory, which will suffice for this purpose. We then use the umount command (note the spelling!) to unmount the pod. The umount command takes, as an argument, either a device name or a mount point. We will use the mount point determined in the first step and issue the commands:

cd
umount /media/Pt-firmware

If successful, neither of these commands will produce any output and you will be returned to the operating system command line prompt. It is now safe to unplug the pod. If you are updating multiple pods, repeat all three steps for each pod.



Home Products Borehole CMG-3TB CMG-5TB CMG-40TB CMG-3T5TB Accessories Featured Articles OBS CMG-3TOBS CMG-40TOBS Accessories Featured Articles Digitisers CMG-DM24 CMG-DM24S3DCM CMG-DM24S6DCM CMG-DM24S12AMS Accelerometers Analogue CMG-5TC CMG-5T CMG-5U CMG-55T Digital CMG-5TD Broadband Seismometers Weak Motion Analogue CMG-3T, 3V CMG-3ESP, 3ESPV CMG-3ESPC Digital CMG-3TD CMG-3ESPD CMG-3ESPCD Medium Motion Analogue CMG-6T, 6V, 6H CMG-40T, 40V, 40H Digital CMG-6TD CMG-40TD CMG-EDU Strong Motion Analogue CMG-5TC CMG-5T CMG-5U CMG-55T Digital CMG-5TD Data Modules CMG-EAM CMG - Serial Server Accessories CMG-GPS Control Units Borehole Accessories OBS Accessories Removable Disks Software Scream! Firmware Updates Product Support "How-to" guides Manuals & Documentation Applications Services Installations Running a Station Training Courses Support Manuals Firmware Calibration How-to Guides Set-up Guides Software Service Centres Technical Support About Us Company Profile Contact Us Distributors Find Us Vacancies News Quality Statement Case Studies	Printable version Updating a Platinum upgrade pod. How to refresh your Platinum upgrade pod to hold the latest firmware revision. Requirements One or more platinum upgrade pods to be updated; and A Linux computer with an available USB connector and an internet connection Procedure The procedure consists of three steps: Mount the pod; Update the content; and Unmount the pod. It is not currently possible to perform this procedure from a Windows PC as Windows does not support the required ext3 filesystem and the available drivers all have limitations which it is not possible to overcome. Users of other operating systems may still be able to perform the update - please contact support for further information. Mounting the pod Most modern Linux systems will automatically mount a USB memory device, such as the upgrade pod, when it is connected. The precise details vary between distributions. The examples given here are for Ubunutu Desktop but the principals are similar in most cases. Consult your operating system documentation if you are unsure. It is necessary to know where the pod has been mounted in order to perform the upgrade. Some operating systems will issue an alert telling you the mount point but, if yours does not, the following steps will allow you to discover it. If you know the mount point, you can skip to Updating the content. When the USB memory device is first inserted, the operating system kernel will assign a device name to it. This is normally something like `sdf`: "sd" shows that the SCSI disk emulation is being used to address the device and the final letter, 'f' in this case, is allocated dynamically in order to generate a unique device name. Filesystems on the device are allocated numerical suffices so the first filesystem on `sdf` would be `sdf1`, the second `sdf2` and so forth. The firmware pod typically only has one filesystem on it. To discover the name, insert the pod into a free USB socket, wait for a few seconds to allow the process to complete, and then type the `dmesg` command. The output will typically look like this: [2476881.712064] usb 1-8: new high speed USB device using ehci_hcd and address 12 [2476881.847080] usb 1-8: configuration #1 chosen from 1 choice [2476881.848095] scsi9 : SCSI emulation for USB Mass Storage devices [2476881.849091] usb-storage: device found at 12 [2476881.849097] usb-storage: waiting for device to settle before scanning [2476886.848307] usb-storage: device scan complete [2476886.849406] scsi 9:0:0:0: Direct-Access Ut163 USB2FlashStorage 0.00 PQ: 0 ANSI: 2 [2476886.850221] sd 9:0:0:0: Attached scsi generic sg6 type 0 [2476886.854358] sd 9:0:0:0: [sdf] 1974271 512-byte logical blocks: (1.01 GB/963 MiB) [2476886.855747] sd 9:0:0:0: [sdf] Write Protect is off [2476886.855754] sd 9:0:0:0: [sdf] Mode Sense: 00 00 00 00 [2476886.855758] sd 9:0:0:0: [sdf] Assuming drive cache: write through [2476886.859737] sd 9:0:0:0: [sdf] Assuming drive cache: write through [2476886.859746] sdf: sdf1 [2476886.991277] sd 9:0:0:0: [sdf] Assuming drive cache: write through [2476886.991293] sd 9:0:0:0: [sdf] Attached SCSI removable disk [2476889.761952] kjournald starting. Commit interval 5 seconds [2476889.770516] EXT3 FS on sdf1, internal journal [2476889.770525] EXT3-fs: mounted filesystem with writeback data mode. From this, it can be seen that the SCSI disk subsystem (sd) has allocated the device name `sdf` to the memory stick and, from the second-to-last line, that the filesystem on the pod has been allocated the name `sdf1`. The last line shows us that the pod’s filesystem has been mounted; we now need to discover where. The command `mount` lists all mounted filesystems, along with their mount-points. The output typically looks like this: /dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro) proc on /proc type proc (rw) none on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) udev on /dev type tmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) none on /proc/bus/usb type usbfs (rw) none on /var/lib/ureadahead/debugfs type debugfs (rw) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) gvfs-fuse-daemon on /home/me/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=me) /dev/sdf1 on /media/Pt-firmware type ext3 (rw,nosuid,nodev,uhelper=devkit) Inspection of this output shows us (in the last line) that our `sdf1` filesystem has been mounted on the directory `/media/Pt-firmware`. Updating the content To update the contents of the pod, we need to change to the directory on which it is mounted and then use the `rsync` command to compare the current contents with the latest version on the Güralp server and download any changes. To do this, issue the following commands (substituting in place of `/media/Pt-firmware` the mount point as previously determined): cd /media/Pt-firmware for ARCH in CMG-DCM-mk2x CMG-DCM-mk4 CMG-NAM CMG-NAM64 ; do sudo rsync -avz --del rsync://rsync.guralp.com/platinum-stable/$ARCH $ARCH done The `sudo` command runs the following command as superuser (root). This is neccessary in order to transfer files owned by the user "root". You will be prompted for your password for security reasons. The line beginning `for` lists codes for each of the architectures on which Platinum firmware is currently supported. If you know that you will never need one or more of these architectures, simply omit its code from the list. The meaning of each code is given here: `CMG-DCM-mk2x` - CMG-DCM data communication modules `CMG-DCM-mk4` - CMG-EAM embedded acquisition modules `CMG-NAM` - CMG-NAM network acquisition modules `CMG-NAM64` - CMG-NAM64 64-bit network acquisition modules Unmounting the pod It is essential to unmount the pod before removing it: this allows the operating system time to ensure that all files have been written to the device before it is disconnected. You first need to change to a directory other than the mount point: Linux cannot unmount a device if it is the current working directory of a user or process. The `cd` command changes to your home directory, which will suffice for this purpose. We then use the `umount` command (note the spelling!) to unmount the pod. The `umount` command takes, as an argument, either a device name or a mount point. We will use the mount point determined in the first step and issue the commands: cd umount /media/Pt-firmware If successful, neither of these commands will produce any output and you will be returned to the operating system command line prompt. It is now safe to unplug the pod. If you are updating multiple pods, repeat all three steps for each pod.