Below is the flash memory Im working with.
I need to upgrade IOS.
The new IOS is over 7 MB, so I dont have enough room in the flash.
So, I will have to delete the directory that is there already. See below.
Directory of flash:/
2 -rwx 856 Mar 1 1993 00:00:35 +00:00 vlan.dat
3 -rwx 19370 Oct 15 2008 11:23:42 +00:00 config.text
4 -rwx 5 Oct 15 2008 11:23:42 +00:00 private-config.text
5 drwx 192 Mar 1 1993 00:06:47 +00:00 c3750-ipbase-mz.122-35.SE5
509 -rwx 2072 Oct 15 2008 11:23:42 +00:00 multiple-fs
15998976 bytes total (6347776 bytes free)
I think the command to use to delete an entire directory (as opposed to just a .bin file) is delete /force /recursive flash:<dir_name>
Am I right?
So, If I issue that command and I kill the directory (which has the existing/running IOS in it), and then there's a problem with the download, I will have no IOS. Is that right??? I will be stuck in ROMMON.
What step by step procedure should I use??
" think the command to use to delete an entire directory (as opposed to just a .bin file) is delete /force /recursive flash:
Am I right? "
Yes you are correct.
And yes if you delete the directory and then have issues with the download then you would be stuck in ROMMON but only if you reload the switch. Everything should be fine until you do that.
I would copy the existing image to a tftp server. Bear in mind that within that dir is a .bin file and you can just copy this to a tftp server. If all goes wrong copy it back to the toplevel ie. not into the dir, set your boot system flash string and you should be fine.
Thats correct thats the command to delete the directory. As long as you don't kill the power and you are sure your tftp server is working correctly before hand you should not have a problem.
I am always very concerned about downloading code through a WAN connection right in the middle of a maintenance window. I have to bring up 2 routers, 11 switches, and 6 WAPs online and the last thing I need is a debacle when upgrading code. I have seen tftp transfers fail so many times in different ways, so I always try to avoid that if I can.
The good news is I got a copy of the IOS to the onsite tech who did a local/pre-cut upgrade.
[EDIT] Last question: How come you sometimes have to execute the 'squeeze' command to actually create the space after you 'delete'? With the 3750s, or perhps its the version of code, that command is not available -- I guess because its not necesarry. Any comments on that?
Re: squeeze vs. delete
Many of the later Cisco flash memory support a DOS file type of memory allocation, so space is reclaimed as soon as you delete a file. (Also on some flash memory you can configured the old style memory allocation if you "erase" flash and the newer style memory allocation if you "format" flash.)
If possible, when doing flash loads over WAN links, you'll find, if it's supported, FTP much faster than tftp. (On some older systems that didn't support TCP, I would use RCP.)
Interesting comment about using RCP (which has been supported in IOS for a looooooong time). Unfortunately RCP is TCP based as is FTP:
"The rcp is a UNIX built-in service. This service uses Transmission Control Protocol (TCP) as the transport protocol" from the link at:
So the comment comparing RCP and FTP should be based on length of time suported and not on the underlying transport protocol.
And I absolutely agree with the comment that FTP performance is much better than TFTP.
Rick, you're only dating yourself when you note RCP "has been supported in IOS for a looooooong time". ;)
Of course, your 100% correct both RCP and FTP run on top of TCP, which is why I recommended one or the other for WAN connections where TCP's transmission windowing usually provides better transfer rate then obtainable with TFTP.
I'm am confused why you think it's unfortunate that both RCP and FTP use TCP, since you agree that "FTP performance is much better than TFTP".
I'm also confused on your comment "comparing RCP and FTP should be based on length of time suported and not on the underlying transport protocol." Are you suggesting usage of RCP rather than FTP since the former has been supported longer? Or, there's some concern with using a TCP based application in preference to TFTP; perhaps (again) implied by the earlier unfortunate?
Probably I am dating myself with my comment. But I was around and I do remember when RCP was supported and FTP was not.
My comment about unfortunate was in reference to your statement "On some older systems that didn't support TCP, I would use RCP". It was unfortunate to suggest that RCP was a viable choice if TCP was not supported. It would have been a good suggestion if it had suggested RCP if FTP was not supported. That may have been what was in your mind.
And my other comment that confuses you was that you seem to be comparing FTP and RCP in terms of their transport protocol (which is the same - as we both agree). My statement was that if you want to compare FTP and RCP the viable comparison is about length of support, since comparison of transport is equal.
Just to set things straight: I endorse the use of either FTP or RCP as performing better than TFTP (especially for large files). And based on FTP being more widely deployed than RCP I endorse the use of FTP more than RCP.
Thank you for your reply!
What a gaff on my part, I had to read several times your "It was unfortunate to suggest that RCP was a viable choice if TCP was not supported. It would have been a good suggestion if it had suggested RCP if FTP was not supported." Finally I "saw" it, i.e. I wrote "On some older systems that didn't support TCP, I would use RCP." where I intended "On some older systems that didn't support FTP, I would use RCP." One of those instances where, at least for me, I don't always see what I wrote but what I intended to write and/or thinking of RCP/FTP using TCP.
I can see where that one word of only 3 letters would be confusing.
I didn't intend any comparison between RCP and FTP, but like you, I would prefer FTP.
Thank you again for finding the error.
no problem. I suspected that your mind thought one thing and your fingers typed something different (which happens to me from time to time). It was a small point but one that I thought should be clarified so that others would not be confused. One of the really good things about the forum is how we collectively improve answers.
Joseph / Rick
"I suspected that your mind thought one thing and your fingers typed something different"
you mean you guys don't answer all your questions like this !! So that's where i have been going wrong :-)
Edit - just reread this and realised it could be misconstrued as an insult to you both. Ermmm it wasn't intended that way at all as i hope you would both know. it was more a self-mocking comment.
And before everyone chimes in about how it shows in my answers.....
Since I have the attention of 3 heavy hitters, can someone explain why I cant change the configuraton register on these 3750 switches??
The 'config-register' command just doesnt appear as an option when in config mode. Right now, the register is set for 0xF.
Im running 12.2(35)SE5 code.
Thanks Victor, i was actually trying to keep a low profile on this thread :)
Can't say for sure but i know that some Catalyst switches such as the 3550 do not have a config-register command ie. you can't change from the default -
I also checked the command reference for your IOS version and there is no config-register command there so i'm guessing the 3650/3750 are like the 3550.
I knew that comment would smoke you out...heeee heeee hoooo hoooo haaaaa haaaaa!
On a serious note, though...ehem, if you cant change the config register, how does one go about performing a password recovery? How do you get the device to ignore the startup config and load a blank running config in its stead?
Your wish is my command :)