10-31-2012 07:29 AM - edited 03-07-2019 09:46 AM
Hi,
I have a WS-C2960S-48PD-L switch that was stacked with a WS-C2960S-24PD-L to form one logical switch.
The 48 port unit gets the error below when trying to boot
Error loading "flash:/update/c2960s-universalk9-mz.122-58.SE2/c2960s-universalk9-mz.122-58.SE2.bin"
According to the config guide - see url below - the only way to recover from this is to copy a new image over XMODEN at 9600 bps!
I have started this and the switch is saying that is will take over four hours to complete!
Is there no there no other way to get the software on to the switch - TFTP, USB????
I cannot believe that Cisco can sell a switch in 2012 that relies upon such ancient technology!
Solved! Go to Solution.
10-31-2012 06:48 PM
According to the config guide - see url below - the only way to recover from this is to copy a new image over XMODEN at 9600 bps!
I've never done XModem on a 2960S ever before (and I've erased alot of IOS).
I "recover" using USB stick.
From ROMmon, you can enter the command "boot usbflash0:IOS.BIN". Enjoy!
10-31-2012 09:24 AM
Hi James,
When Catalyst fixed configuration switches experience boot errors, these conditions can apply:
The error loading flash:
Error loading "flash:/update/c2960s-universalk9-mz.122-58.SE2/c2960s-universalk9-mz.122-58.SE2.bin"
The corrupt or missing image can be the result of a failed download. In this case, the image has a bad checksum or a failed software upgrade, and the upgrade procedure was not followed properly. There is the possibility that the user deleted the image but did not replace the image. A boot variable can have been set incorrectly.
Note: Be sure to verify that you have configured the correct boot statement on the switch.
switch: flash_init
switch: load_helper
switch: boot flash:c2950-i6q4l2-mz.121-13.EA1.bin
Refer:
http://www.cisco.com/en/US/products/hw/switches/ps628/products_tech_note09186a0080169696.shtml
Regards,
Aru
*** Please rate if the post is useful ***
10-31-2012 06:48 PM
According to the config guide - see url below - the only way to recover from this is to copy a new image over XMODEN at 9600 bps!
I've never done XModem on a 2960S ever before (and I've erased alot of IOS).
I "recover" using USB stick.
From ROMmon, you can enter the command "boot usbflash0:IOS.BIN". Enjoy!
11-01-2012 02:10 AM
leolaohoo,
Thanks I will try that.
Not sure why Cisco cannot put this in the software config guide!
11-01-2012 03:03 PM
Not sure why Cisco cannot put this in the software config guide!
Because there are not enough "demand" to put this info in. Think about it: How many Cisco users (worldwide) would ever contemplate using USB to boot from ROMmon?
Every other person has been re-directed to use the "old school" XModem even though this facility has been available since the "-E" series switches and ISR G1 (except the 870).
02-10-2013 05:58 AM
Hi,
The USB method worked fine for me once but a few months later I was adding another 2960S switch to a stack and the sofware in flash managed corrupt itself again (I am really starting to dislike the 2960S).
This time I did not have a USB stick handy (or at least not one that worked) so I did some digging and found that it is possible to recover the switch using TFTP using the process below.
Again epic fail by Cisco for not having this in the configuration guides.
I hope that this saves other people some frustration
08-13-2013 12:56 PM
Thank you both for these posts and thanks James for taking the time to get back on and document the tftp method. And I agree, EPIC fail for not including these methods in the config guides. If you have 3 methods to do this why do you only document the most onerous one? C'mon Cisco!
I just wanted to add a couple of notes.
USB method
I never got this to work. The 15.0(2) config guide states that the largest USB drive the 2960S supports is 1GB and the smallest I have available is 8GB. Where do you find a 1GB USB stick anymore? In any case I used Win7 and diskpart to create a 1GB partion and format it as FAT16. I found the procedure here:
http://superuser.com/questions/202160/how-do-i-format-my-8-gig-usb-drive-to-fat-fat16-in-windows-7
But it is reproduced here:
DISKPART> list disk
Disk ### Status Size Free Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0 Online 298 GB 0 B
Disk 1 Online 7640 MB 0 B
DISKPART> select disk 1
Disk 1 is now the selected disk.
DISKPART> list part
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 Primary 7636 MB 4032 KB
DISKPART> clean
DiskPart succeeded in cleaning the disk.
DISKPART> list part
There are no partitions on this disk to show.
DISKPART> create part primary size =1024
DiskPart succeeded in creating the specified partition.
DISKPART> list part
Partition ### Type Size Offset
------------- ---------------- ------- -------
* Partition 1 Primary 1024 MB 1024 KB
DISKPART> active
DiskPart marked the current partition as active.
DISKPART> format fs=fat quick
100 percent completed
DiskPart successfully formatted the volume.
DISKPART> assign
DiskPart successfully assigned the drive letter or mount point.
DISKPART> exit
Leaving DiskPart...
I then copied a .bin image over and tried to read it with ROMMON but I got these errors:
switch: dir
ERR: !CSWSIGNATURE
ERR: !CSWSIGNATURE
ERR: Device NOT ready
ERR: =PHASE
ERR: Read ERROR start 0 blks 1
ERR: =PHASE
ERR: Read ERROR start 0 blks 1
ERR: =PHASE
ERR: Read ERROR start 0 blks 1
usbflash0: contains unexpected values in partition table or boot sector.
Device needs formatting before use!
Not to be outsmarted, I inserted the USB in a fully booted 2960 and formatted it with the IOS format command. Then I copied the .bin back onto it and inserted it back into the switch in ROMMON mode. I received the same errors. Ok time to move on. I don't like to fail but I don't have all day!
TFTP method
I got this working in fairly short order. The only thing I want to say about this is that after setting the IP address and gateway do NOT try pinging TO the switch that is in ROMMON mode from something else... it will not respond. Instead ping FROM the switch. This caused me a little grief before I figured that out.
-Jeff
08-13-2013 03:36 PM
Then I copied the .bin back onto it and inserted it back into the switch in ROMMON mode. I received the same errors.
Not all USB manufactuers are supported. However, not all manufacturer's models are supported either. Confused? Let me explain ...
1. USB sticks are not made by the same manufacturer. Let's say you have Toshiba 8 Gb. You think they are made my Toshiba? Guess again. How about a Toshiba 16 Gb? But are both 8 Gb and 16 Gb made by the same manufacturer? No they are not.
2. So, let's say you are able to find a compatible USB stick, say an 8 Gb and you wanted to get a bigger one. You go and get a 16 Gb (or a 32 Gb) by the same manufacturer but the same "model" (except for the size, of course). The 8 Gb can be formatted but the rest won't. Why is that?
3. Alot of the REAL USB manufacturers follow rules and standard. Some don't. This is the reason why you get behaviours in #2. The best bet is to get a few from the local electronics shop and test them. Once you have isolated the make, model and size, go back to the electronics shop and buy out their stock.
08-14-2013 07:49 AM
Sure, but the odd thing is that IOS has no problem with this particular USB flash. I formatted it and wrote the .bin image onto it with IOS on a 2960S. The same switch in ROMMON mode refuses to read it. I wonder if I used a different utility to partition the flash if it would make any difference? GPARTED perhaps?
Also the config guide states that maximum supported USB size is 1GB, so there isn't much point in getting anything larger, Where can you buy a 1GB USB stick today? In any case it needs to be formatted as FAT16 which has a 2GB limit anyway. If you insert a flash drive formatted as FAT32 the switch doesn't even acknowledge it.
-Jeff
08-14-2013 03:51 PM
The same switch in ROMMON mode refuses to read it. I wonder if I used a different utility to partition the flash if it would make any difference? GPARTED perhaps?
Never seen or heard of a behaviour like this.
Could I humbly ask if you can post what happens when, in ROMmon, you enter the command "boot usbflash0:IOS.bin"? I want to see the command and output.
Please post the output to the command "dir usbflash0:".
08-14-2013 06:30 PM
The output of the dir usbflash0: in ROMMON mode is identical to the ouput posted above (ERR: !CSWSIGNATURE..). I am pretty sure the output of the boot comand is also identical. I seem to recall that every read attempt resulted in the same result. At some point it stopped recognizing it at all, maybe when I tried to format under ROMMON mode?
I was not booting IOS.bin as that was not the name of the file on the USB flash. I was trying boot usbflash0:c2960s-universalk9-mz.150-2.SE4.bin. I think I got the same output.
If I have time tomorrow (unlikely) I will try it again.
08-14-2013 08:22 PM
ERR: !CSWSIGNATURE
I've never seen this error message before.
Did you try "flash_init" first before doing any other commands?
08-14-2013 08:27 PM
Yes, tried flash_init. Returned "flash already initialized" (or something to that effect). Also tried load_helper, etc.
But again, under fully booted IOS it was no problem. I tried "format usbflash0:" and it came back to the prompt immediately. I then did a "copy ftp://... xxx.bin usbflash0" and it copied the file succesfully. Then I put the switch into rommon mode and it would not read the USB flash.
08-14-2013 09:13 PM
Odd ... So the same switch can read the USB with IOS already loaded but can't read the same USB stick when in ROMmon?
If this is the case, then I think the problem is the USB. I can't explain it.
08-14-2013 11:29 PM
Hi Leo and Jeff,
This suggests to me that the USB driver in the ROMMON (or better said, the bootloader - as these switches do not appear to run a ROMMON similar to routers) is less robust than the USB driver in the IOS itself.
According to the USB Mass Storage Class specification Section 5.2, the CSWSIGNATURE refers to an integer constant that is a part of command packets exchanged between the USB key and the switch. According to comments in the Linux USB mass storage driver source code, some USB mass storage devices present themselves with odd signatures but otherwise work properly, so the Linux driver is more lenient here - it just learns the odd signature and makes sure that the device always uses that, in which case Linux simply "adapts". It is possible that the ROMMON USB driver either does not initialize the USB key properly, or the USB key presents itself with a non-standard signature and the ROMMON USB driver is more stringent than the IOS driver, with the IOS driver being more lenient (similar to my Linux example). This would not be surprising - there are space and complexity restrictions to the ROMMON code, and building a robust code that handles different kinds of non-standard cases gracefully simply adds too much complexity to be reasonable.
In any case, I know this is not really helpful... This particular USB key probably won't be able to work under the ROMMON.
Best regards,
Peter
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide