'Router running low on free NVRAM' yellow alert notice

[learning_curve]

Switching back to the OP's original query 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

 

[eibgrad]

Switching back to the OP's original query 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.

 

[ColinTaylor]

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.

# 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.

 

[eibgrad]

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.

# 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.

 

[ColinTaylor]

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.

 

[learning_curve]

....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?

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

 

[Igor]

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

 

[Christian_Haitian]

Switching back to the OP's original query 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.

 

[hoang51]

I run this command to free up nvram

for line in `nvram show | grep =$ `; do var=${line%*=}; nvram unset $var; done; nvram commit

Thanks for this, this resolved my low space NVRAM.