What's new

'Router running low on free NVRAM' yellow alert notice

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Switching back to the OP's original query :D the content of this post: https://www.snbforums.com/threads/solved-high-nvram-usage.56848/#post-494736 by @sbsnb is structured, safe & works perfectly every time (for me anyway) whilst having a very similar Top 20. It's also very easy to re-use too after say a re-boot etc
NVRAM.png
 
Switching back to the OP's original query :D the content of this post: https://www.snbforums.com/threads/solved-high-nvram-usage.56848/#post-494736 by @sbsnb is structured, safe & works perfectly every time (for me anyway) whilst having a very similar Top 20. It's also very easy to re-use too after say a re-boot etcView attachment 30812

I understand what this is doing; removing variables w/ no currently assigned values. But doesn't that assume that should those variables been needed in the future and are currently missing, the firmware will simply recreate them? If that's the case, then sure, why not. But I'm just a bit skeptical. It certainly wouldn't be my initial assumption.
 
I understand what this is doing; removing variables w/ no currently assigned values. But doesn't that assume that should those variables been needed in the future and are currently missing, the firmware will simply recreate them? If that's the case, then sure, why not. But I'm just a bit skeptical. It certainly wouldn't be my initial assumption.
Indeed. Removing the empty variables will appear free up space immediately but in most, if not all cases they will just be recreated when the router is rebooted.
Code:
# nvram show | grep ^[^=]*=$ | wc -c
6757

I guess it could have a lasting effect if there were some obsolete variables left over from older firmware versions or user scripts. But a more thorough way of getting rid of such variables would be a factory reset and manual configuration.
 
Indeed. Removing the empty variables will appear free up space immediately but in most, if not all cases they will just be recreated when the router is rebooted.
Code:
# nvram show | grep ^[^=]*=$ | wc -c
6757

I guess it could have a lasting effect if there were some obsolete variables left over from older firmware versions or user scripts. But a more thorough way of getting rid of such variables would be a factory reset and manual configuration.

Not sure I've made my point here.

I have no reason to believe that merely rebooting the router will automatically and immediately cause these deleted variables to reappear. Not unless there's some sort of initialization process that's always checking for missing variables. Just seems unlikely.

More likely the variables remain missing until they are *referenced* again, specifically when an update is required. So for example, if the variables for the 5th OpenVPN client are deleted, and I go to that page in the GUI, *hopefully* the GUI doesn't choke on the fact that variables it's expecting to be there are now missing. THAT is my first concern. And if they are missing, any subsequent update attempt will fail. THAT is my second concern.

After all, why would the developer needlessly populate precious nvram w/ uninitialized variables if they could simply be (re)created when needed, i.e., on-demand? My assumption would be they are there out of necessity, and not frivolously and needlessly consuming nvram.

It's not as if I've tested any of this, so the whole process may indeed be benign. But I remain skeptical whether its advocates have gone so far as to eliminate these concerns. But perhaps if I was to do my own verification, I might come to learn it is indeed benign. But until I do, I just don't have a good feeling about it. All my intuition as a longtime software developer tells me something isn't quite kosher about this approach. Hopefully my intuition has betrayed this time.
 
Last edited:
I have no reason to believe that merely rebooting the router will automatically and immediately cause these deleted variables to reappear. Not unless there's some sort of initialization process that's always checking for missing variables. Just seems unlikely.
Yes that's exactly what happens. I've just checked this and after the reboot the only variables that weren't recreated were some of the guest WiFi variables and some wan1 variables (plus 5 other spurious variables)***. Everything else was recreated.

So my free space went from 7723 up to 14424 and then after a reboot back down to 8754.

It's also worth bearing in mind that just because the contents of a variable is a null string that doesn't necessarily mean that it is unused.

*** Obviously different firmware versions have different sets of variables so YMMV.
 
Last edited:
....But doesn't that assume that should those variables been needed in the future and are currently missing, the firmware will simply recreate them? If that's the case, then sure, why not. But I'm just a bit skeptical. It certainly wouldn't be my initial assumption.
Being skeptical is fine, but are you sceptical enough? :D

Joking aside, you've already seen the correct answers now from @ColinTaylor plus, there's quite a lot more discussion (sometimes involving some of the same concerns that you have) in the rest of the thread I posted the link to (and some other threads) and, I did say in my previous post; "...It's also very easy to re-use too after say a re-boot" meaning... that yes, although you not feeling that you can believe / it being unlikely etc, after a re-boot, those changes are indeed revoked, so you will need to make them again in order to achieve the NVRAM savings demonstrated. I've done this many times now without any problems whatsoever, but your current router / firmware / setup will be different than mine so YMMV.

However, that fact alone, should hopefully remove your concerns about running a future update as you can easily re-boot your rooter prior to all your other normal pre-upgrade checks, processes, re-sets etc
 
I think the nvram overflow was after adding a lot of vpn_ * variables (which I don't use):

# nvram show | grep vpn_ | wc -c
size: 64331 bytes (1205 left)
9400

Empty variables:
# nvram show | grep ^[^=]*=$ | wc -c
size: 64331 bytes (1205 left)
12376
 
Switching back to the OP's original query :D the content of this post: https://www.snbforums.com/threads/solved-high-nvram-usage.56848/#post-494736 by @sbsnb is structured, safe & works perfectly every time (for me anyway) whilst having a very similar Top 20. It's also very easy to re-use too after say a re-boot etcView attachment 30812
Hello,

Just reporting that this is working great for me after a dirty upgrade of my rt-ac1900p unit from 384.19. I have it set to run this command at every boot by putting it at the end of my services.start script located in /jffs/scripts. Thank you for this tip as I am not wanting to factory restore my unit at this time. I'm sure I will need to eventually and should eventually do a factory restore. Thanks to all on this forum for always being helpful. This forum and Merlin's firmware are fantastic.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top