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_188.8.131.52_release_cisco_signed.bin Version: 184.108.40.206 MD5 Digest: 07968d912499cff5e8b07fdc24779854 Date: 18-Jun-2019 Time: 16:49:35 Inactive-image: flash://system/images/image1.bin Version: 220.127.116.11 MD5 Digest: 6f5be217100f34929986f2e93dd2d5e9 Date: 31-May-2018 Time: 02:39:58 kettofszt-top#boot system tftp://18.104.22.168/fw/cisco/image_tesla_hybrid_22.214.171.124_release_cisco_signed.bin 18-Jun-2019 06:49:43 %COPY-I-FILECPY: Files Copy - source URL tftp://126.96.36.199/fw/cisco/image_tesla_hybrid_188.8.131.52_release_cisco_signed.bin destination URL flash://system/images/image_tesla_hybrid_184.108.40.206_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.
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 :
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: 220.127.116.11, however all our switches on Version: 18.104.22.168 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_22.214.171.124_release_cisco_signed.bin
Did you tried with the following:
kettofszt-top# copy tftp://126.96.36.199/fw/cisco/image_tesla_hybrid_188.8.131.52_release_cisco_signed.bin flash://image2
and then :
kettofszt-top# boot system flash://image2
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_184.108.40.206_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
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
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 220.127.116.11, it just doesn't work, not in CLI, not via gui.
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_18.104.22.168_release_cisco_signed.bin flash://image2
switchxxxxxx# dir flash://
switchxxxxxx# boot system flash://image2
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?
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.
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".