sg350x image upgrade with tftp

[cscs]

The currently running (active) firmware was uploaded via the web interface. THEN and NOW the upgrade procedure via cli (tftp) gives the same result:

kettofszt-top#sh ver
Active-image: flash://system/images/image_tesla_hybrid_2.5.0.83_release_cisco_signed.bin
  Version: 2.5.0.83
  MD5 Digest: 07968d912499cff5e8b07fdc24779854
  Date: 18-Jun-2019
  Time: 16:49:35
Inactive-image: flash://system/images/image1.bin
  Version: 2.4.0.94
  MD5 Digest: 6f5be217100f34929986f2e93dd2d5e9
  Date: 31-May-2018
  Time: 02:39:58
kettofszt-top#boot system tftp://148.6.2.9/fw/cisco/image_tesla_hybrid_2.5.0.83_release_cisco_signed.bin
18-Jun-2019 06:49:43 %COPY-I-FILECPY: Files Copy - source URL tftp://148.6.2.9/fw/cisco/image_tesla_hybrid_2.5.0.83_release_cisco_signed.bin destination URL flash://system/images/image_tesla_hybrid_2.5.0.83_release_cisco_signed.bin

Copy: Error occurred when writing file

kettofszt-top#18-Jun-2019 06:49:43 %COPY-W-TRAP: The copy operation has failed

This device is the master unit of a ring-topology stack with 3 devices.

[msaeedi]

For small business switches, it is better to do upgrade using web , however you can upgrade the firmware using cli but to make sure check the below points :

1. check that you've uploaded the image or firmware or binary file to the switch flash.
2. check if the version is the active version or active image.   

[Michael De Vijlder]

Did you ever find a fix for this? I am running into the same issue with a couple of our SG350s, and doing them all one by one via the web gui is not an option..

I have noticed it seems to be on certain versions, it worked perfectly to use the boot system on a switch with Version: 2.3.5.63, however all our switches on Version: 2.4.0.91 just refuse to accept the command. If I try copying the file manually, it says it it instantly downloaded and very small compared to the actual file size:

dir flash:
Permissions
    d-directory
    r-readable
    w-writable
    x-executable
155536K of 224440K are free
Directory of flash://

Permission File Size    Last Modified                   File Name                
---------- --------- -------------------- -------------------------------------- 
   -rw-       512    17-Apr-2018 20:59:59 image_tesla_hybrid_2.5.0.92_release_cisco_signed.bin

[mihail_ip]

Hello CSCS,

Did you tried with the following:

kettofszt-top# copy tftp://148.6.2.9/fw/cisco/image_tesla_hybrid_2.5.0.83_release_cisco_signed.bin flash://image2

 then verify:

kettofszt-top# dir

and then :

kettofszt-top# boot system flash://image2

[Michael De Vijlder]

Hi mihail,

I tried this solution, doesn't seem to work, the copy completes immediately and the file is way too small to be copied correctly (since the actual image is 43M and not 512 bytes..)

29-Apr-2018 01:27:34 %COPY-I-FILECPY: Files Copy - source URL tftp://<snip>/image_tesla_hybrid_2.5.0.92_release_cisco_signed.bin destination URL flash://image2
29-Apr-2018 01:27:34 %COPY-N-TRAP: The copy operation was completed successfully

Copy: 512 bytes copied in 00:00:01 [hh:mm:ss]


dir
Permissions
    d-directory
    r-readable
    w-writable
    x-executable
155196K of 224440K are free
Directory of flash://

Permission File Size    Last Modified                   File Name                
---------- --------- -------------------- -------------------------------------- 
   -rw-       512    29-Apr-2018 01:27:34 image2                                 
   dr--      1168    17-Apr-2018 09:20:04 system                                 

[mihail_ip]

Hello Michael,

We have the same name :)

Check the remote TFTP server with some Linux machine if actually you can get the file. May be there is some ACL or misconfiguration or the file itself is corrupted.

Hope it helps

Regards,

Mike

[Michael De Vijlder]

Hi Michael :D

Well that I have already verified, I can use the exact same command (and it works) on the same type of switch, but with a different version. So the file and the tftp server are definitely ok, we use it for a lot of things.

At this point I think there is a bug in the software, because the exact same command for me on older versions (2.3.x.x), but on Version 2.4.0.91, it just doesn't work, not in CLI, not via gui.

[mihail_ip]

Hi again,

I see - may be you can try with USB Flash drive (if the switch is not remote of course):

switchxxxxxx# copy usb://image_tesla_hybrid_2.5.0.92_release_cisco_signed.bin flash://image2

then verify:

switchxxxxxx# dir flash://

then

switchxxxxxx# boot system flash://image2

[Michael De Vijlder]

Unfortunately all our switches are remote, and I have found ways to actually update them (through the GUI works for example), but we tend to script upgrading our switches so TFTP via CLI is thé way to go for us.

Is there wany way to actually get tftp working?

[mihail_ip]

Hello Michael,

Another thought came to my mind - if the tftp server is on public IP address - may be you can try with internal tftp server.

Also you can mirror the port and capture the traffic to analyze with Wireshark what is breaking and where.

Regards,

Mike

[Jan Rafaj]

Hello Michael,

We're pretty much in the same situation as you, and the problem you describe has recently peeped here too: TFTP server is ok, but the CISCO Sx350 SB firmware stubbornly rejected any attempt to upgrade its firmware via tftp with (indeed very unhelpful)

%COPY-W-TRAP: The copy operation has failed

 as the only clue.

Please check whether your tftp server supports RFC 2349 (reporting the size of the file transferred). If using in.tftpd on linux, you might be able to enable it by adding "-r tsize" as its parameter. It worked on my side. Up to now I've been using "-r blksize" (RFC 2348) and every vendor device seemed to be happy, not just Cisco Sx350 devices. I think Cisco should make this known in its datasheet section pertaining to TFTP as mandatory, or many people might end up pulling their hair as we both did.
Just a sidenote: Cisco Sx300 class devices had no need for RFC 2349, they were happy with "-r blksize".