Help: startup-config file open failed (Not enough space)

Unanswered Question
Dec 29th, 2009
User Badges:

Who can help me ? I've an uc500 and he stil running. Now i want to change something and want to save the configuration first. But the following message appears : startup-config file open failed (Not enough space)


this is the output from a dir flash:


Directory of nvram:/

  227  -rw-       25897                    <no date>  startup-config
  228  ----        1933                    <no date>  private-config
  229  -rw-       25897                    <no date>  underlying-config
    1  ----          83                    <no date>  persistent-data
    2  -rw-           0                    <no date>  ifIndex-table
    3  -rw-         577                    <no date>  IOS-Self-Sig#1.cer
    4  -rw-         615                    <no date>  IOS-Self-Sig#2.cer
    5  -rw-         660                    <no date>  vlan.dat
    6  -rw-         107                    <no date>  cca.xml
    7  -rw-         586                    <no date>  IOS-Self-Sig#3.cer

262144 bytes total (227094 bytes free)

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Steven DiStefano Wed, 12/30/2009 - 07:53
User Badges:
  • Blue, 1500 points or more

Hmmmm.  Not really sure.  Your running and startup are almost twice the size of mine, but I dont see any size related restrictions for NVRAM and you have plenty of space.


I see the # so I know you are enabled.


If you execute

# wr mem


Does it do the same thing?


Mine compresses as well...

UC520#wr mem
Building configuration...


Compressed configuration from 32926 bytes to 15578 bytes[OK]
UC520#


What exact error do you see?



Thanks

Adriaan Mol Wed, 12/30/2009 - 08:38
User Badges:

if I give a write command then it result in the message : startup-config file open failed (Not enough space). Even i use the write mem command

Steven DiStefano Wed, 12/30/2009 - 11:08
User Badges:
  • Blue, 1500 points or more

OK.

Try this:


conf t

service compress-config


And see if that helps. 


If not, see if you can tftp the running config off the router and TFTP it back to startup-config:

copy run tftp

copy tftp start


Then you can try a reload and see if it is cured.


I googled and found a few cases where alot of ACLs or NAT rules could cause MALOC errors (you would see those in your logs) when implemented and could manifest itself in this condition, which could be cured after the next reload, which is why I suggested that.


Of course, dont be remote when you do this and only do it during a maintenance window.


Steve

dloder Mon, 11/10/2014 - 19:05
User Badges:

I have same problem on a uc540.

Tried the service compress-config, and that did not  fix it.

I work 600 miles from the uc540, so I can't try the other one now.

My error is exactly what  is in the title of this item

jreader125 Sat, 12/06/2014 - 08:14
User Badges:

I have this same issue on a UC540.  The UC540 is currently running, but now I can't write the config.  I'm also far from the device.

igor.nepochatov Tue, 03/11/2014 - 14:55
User Badges:

Issue the followign command:

Switch#sh boot 

BOOT path-list:       flash:/c3550-ipservicesk9-mz.122-25.SED.bin
Config file:          flash:/
Private Config file:  flash:/private-config.text
Enable Break:         no

Pay attention to "Config file". If it does not have file specified, add it using

"boot config-file flash:/config.text"

 

Reboot the switch after adding the command for it to take affect. 

 

 

dloder Mon, 11/10/2014 - 18:53
User Badges:

this command does not work on my uc540

I get invalid output on the first "o" of boot

show b? gives me backup beep bridge and buffers

Dan Lukes Mon, 01/23/2017 - 12:01
User Badges:
  • Red, 2250 points or more
  • Cisco Designated VIP,

    2017 Small Business

Bug report in question is dedicated to Cisco 2600 Series Multiservice Platforms and it's claimed to be corrected in 12.* firmware, but this thread is dedicated to UC5xx platform and  @dloder  has reported the issue even with uc500-advipservicesk9-mz.151-4.M6. So it seems the bug in question has not been patched on UC*

Moreover, no one is allowed to download latest UC* images because of EOL - thus no one can verify it's patched in most recent firmware.

Actions

This Discussion