Update Firmware and Configuration of Netbotz 250 with a distant Linux

[DCIM_Support]

I am currently working on a system composed of a BOT (automated Linux) piloting the distant Netbotz 250.

The BOT will have to perform automatically an upgrade of the firmware (bootmon, AOS, Application modules) and the configuration.ini automatically. Of course, these files will have been added on its harddrive previously.

in addition, the BOT can only use the commands ssh commands (e.g. scp). It has no ftp and cannot use an executable to perform the action.

I would like to know what is the correct procedure to do, to perform such updates (firmware and configuration). All I have read in the datasheet is about the transfer (scp) of the files on the Netbotz.

Is that really all the BOT need to do ? What is happening on the Netbotz 250 after the files have been copied via scp?

Thank you in advance for your answers to my questions.

Best Regards,

rf2019

(CID:140714202)

[DCIM_Support]

Hi Raphael,

The following k-base explains how to update the firmware on an NMC based product:

http://www.apc.com/us/en/faqs/index?page=content&id=FA156047

For transferring the file manually, yes you simply have to push the file (ftp / scp) and when done, push the next. Again that k-base explains the procedure. You may also want to use the utilities in that k-base instead of recreating the wheel. 

For configuration of users, you may want to check out this k-base:

http://www.apc.com/us/en/faqs/index?page=content&id=FA176542

For other configurations, you can push a config.ini and the procedure is outlined in this k-base:

http://www.apc.com/us/en/faqs/index?page=content&id=FA156117

Thanks,

Steve

(CID:140714222)

[DCIM_Support]

Thank you for your answer. Sadly, I do not understand how the updates are done once the files (firmware, configuration) are copied on the flash of the netbotz.

Is that all we have to do?

As I told you I cannot use an executable on my BOT (autonomous-distant Linux). This BOT can only execute commands predefined (scp or CLI; ftp cannot be used). These are my project/design constraints.

So I kind of have to reinvent the wheel and the knowledge base you provided me does not provide me with answers to my questions.

(CID:140714433)

[DCIM_Support]

Dear Raphael FLAMENBAUM,

Perhaps my experience will be useful to you: for more than five years I have been using the below specified my bash-script for bulk automatic firmware updates (including language packs) of almost all NMC/NMC2 based devices APC/=SE=. It uses ftp client, but I think that it can be remade for scp client, which will be interesting for you.

bashAPC_FW_massUpgrade.shtrue#!/bin/sh # #spezialist Date: 01.09.2014 # while read i; do echo "Step 1/4" echo "$i: upload APC Boot Monitor..." ftp -in $i <If you have more questions, please ask.

With respect.

(CID:140714438)

[DCIM_Support]

Hi Raphael,

maybe spezialist script will help but for understanding the process, you don’t have to do anything other then push the files. They must be done individually and the next file must wait for the previous to complete. Bootmon is not always required and rarely changes so under normal situations, push the AOS and wait for it to complete, then push the APP.  There is no executable to run. 

Steve. 

(CID:140714531)

[DCIM_Support]

Hi Steven, Hi Spezialist,

Thank you for your answers, I can see that it is normal to just copy the files on the non-volatile memory of the NetBotz. I guess the NetBotz checks everything and does the compatibility checks of the different firmware files received.

I understand that the BOT, I have, will have to wait before transferring the next firmware file. But is there any acknowledgement from the NetBotz indicating that the update has been fully performed, which would avoid the BOT to wait a certain amount of time to be defined ?

How can we be sure that the after N upgrade of the firmware, the NetBotz non-volatile memory is not saturated ?

Thank you in advance for your answers.

Best Regards,

Raphaël

(CID:140714969)

[DCIM_Support]

Dear Raphael FLAMENBAUM,

From your comments:

...I guess the NetBotz checks everything and does the compatibility checks of the different firmware files received.

No, it is impossible to hope for it completely.

Indeed, you will not be able to write the firmware made for NMC Gen1 to the NMC Gen2 device in this way (an error will be generated). But, for example, you can write the firmware for the Smart-UPS NMC2 to the Symmetra PX250/500 NMC2 device. There will be no errors, and the NMC2 will function, but you will completely lose the information from the UPS ☹️. There are several more such sad examples. Therefore, all the firmware, that is being prepared for writing should be checked by people 😀.

...But is there any acknowledgement from the NetBotz indicating that the update has been fully performed, which would avoid the BOT to wait a certain amount of time to be defined ?

There are two ways to do this:

• the standard method, that is used by the =SE= utility FW_Upgrade_R2.exe is after each stage of sending the firmware file, wait until the device is rebooted by checking the ping response;

• the second method is in addition to the first one and is used when updating firmware with DCE software - after restarting the device, read it using the SNMP protocol. For example, to find out which current version of APC OS you need to do:

  $snmpget -v2c -cpublic IP_apc_device enterprises.318.1.4.2.4.1.4.1 enterprises.318.1.4.2.4.1.4.1 = STRING: "v3.7.4" --or-- $snmpget -v2c -cpublic IP_apc_device enterprises.318.1.4.2.4.1.3.1 enterprises.318.1.4.2.4.1.3.1 = STRING: "apc_hw02_aos_374.bin"

  And, to find out which current version of APC Application Module you need to do:

  $snmpget -v2c -cpublic IP_apc_device enterprises.318.1.4.2.4.1.4.2 enterprises.318.1.4.2.4.1.4.2 = STRING: "v3.7.1" --or-- $snmpget -v2c -cpublic IP_apc_device enterprises.318.1.4.2.4.1.3.2 enterprises.318.1.4.2.4.1.3.2 = STRING: "apc_hw02_g2ats_371.bin"

  Again, to find out which current version of APC Boot Monitor you need to do:

  $snmpget -v2c -cpublic IP_apc_device enterprises.318.1.4.2.4.1.4.3 SNMPv2-SMI::enterprises.318.1.4.2.4.1.4.3 = STRING: "v1.0.8" --or-- $snmpget -v2c -cpublic IP_apc_device enterprises.318.1.4.2.4.1.3.3 SNMPv2-SMI::enterprises.318.1.4.2.4.1.3.3 = STRING: "apc_hw05_bootmon_108.bin"

  Or you can read all of the above using only one SNMP command, but with subsequent string parsing (this can be much more difficult):

  $snmpget -v2c -cpublic IP_apc_device sysDescr.0 SNMPv2-MIB::sysDescr.0 = STRING: APC Web/SNMP Management Card (MB:v4.1.0 PF:v6.6.4 PN:apc_hw05_aos_664.bin AF1:v6.6.4 AN1:apc_hw05_sumx_664.bin MN:AP9631CH HR:05 SN: xxxxxxxxxxxx MD:xx/xx/xxxx) (Embedded PowerNet SNMP Agent SW v2.2 compatible)

How can we be sure that the after N upgrade of the firmware, the NetBotz non-volatile memory is not saturated ?

I have never come across this, but for this, you need to do a lot of flashing on the same device. You understand, that it is unlikely to be practical... But even in this case, there is a special command format in APC OS:

apc>format Format FLASH file system Warning: This will delete all configuration data, event and data logs, certs and keys. Enter 'YES' to continue or to cancel : apc>

If you have more questions, please ask.

With respect.

(CID:140715078)

[DCIM_Support]

Hello again,

In the script you have provided in this forum, you did not reboot the NetBotz.

However, in the comment above, you talked about a reboot. What does it mean:

• Does the NetBotz, after during the upgrade, reboots itself?
• Do we have to reboot manually the NetBotz after end of the transfer of Bootmon & AOS & APP ?

When formatting the device, at reboot, does it mean that the configuration.ini and pieces of firmware are erased ? Or is it saved in another section of the memory of the NetBotz which is not impacted by the formatting ?

Bes Regards,

rf2019

(CID:141264737)

[DCIM_Support]

Dear Raphael FLAMENBAUM,

From your comments:

• Does the NetBotz, after during the upgrade, reboots itself?

Absolutely right.

When formatting the device, at reboot, does it mean that the configuration.ini and pieces of firmware are erased ? Or is it saved in another section of the memory of the NetBotz which is not impacted by the formatting ?

As you can see from my screenshot, when formatting the FLASH, the device is reset to the factory default settings. The firmware does not change (erased) and it remains as it was before formatting.

With respect.

(CID:141264742)

[DCIM_Support]

Dear spezialist,

Thank you for your answer.

Maybe I am bothering you with my questions, but sadly, I do not have any NetBotz in front of me, but I have to paper-design this BOT I am talking about.

I was wondering what you think about using the CLI commands:

• dir
• delete

To search for the list of doubloons (old configuration.ini or old firmware modules (aos, app)), by using the "dir" command, look for the oldest ones and remove them by using "delete" command.

Therefore the sequence would be:

• ssh connection
• scp @:
• close ssh
• sleep 1 min (worst case I guess)
• ssh connection
• dir
• if doubloons, delete /
• close ssh

Best Regards,

rf2019

(CID:141265150)

[DCIM_Support]

Dear Raphael FLAMENBAUM,

From your question:

To search for the list of doubloons (old configuration.ini or old firmware modules (aos, app)), by using the "dir" command, look for the oldest ones and remove them by using "delete" command.

This is not necessary: devices never duplicate configuration files or firmware. That is, at the same time on the device there can be only one configuration file and only one version of the firmware. The device itself is worried about this.

With respect.

(CID:141265425)

[DCIM_Support]

Hello spezialist

I have to admit that I am not sure tohave well understood.

Just to be sure, you are saying that the NetBotz will erase automatically the old version firmware.

Therefore, if aosv2 is upgraded to aosv3, the aosv2 is automatically erased from the NetBotz non-volatile memory. Hence, there should be no risk of having the non-volatile memory of the NetBotz being saturated while performing several upgrades.

Best Regards,

rf2019

(CID:141265469)

[DCIM_Support]

Dear Raphael FLAMENBAUM,

You understood correctly. As soon as the new firmware is successfully received and verified by the device, its old firmware is erased.

With respect.

(CID:141265480)

[DCIM_Support]

Dear Raphael FLAMENBAUM,

Tell us, please, did you solve your question or not?

With respect.

(CID:141269197)

[DCIM_Support]

This question is closed for comments. You're welcome to start a new topic if you have further comments on this issue.