Should I Erase NVRAM

Discussion in 'Tomato Firmware' started by Bill_S, Jul 28, 2013.

  1. Bill_S

    Bill_S Network Guru Member

    I am preparing to update my RT-N66U to the latest version of Tomato Shibby and was wondering if it is necessary to erase all data in NVRAM? I just hate re-configuring the router but if it is necessary, then I will. So, the question is erase or not to erase, can anyone advise?
    Xero5 likes this.
  2. darksky

    darksky Addicted to LI Member

    Dunno if it's necessary. Try it and see if everything works. Did shibby's release notes indicate a mandatory flash? I recommend that you use some screencapture util to record while going through all of the important tabs in the router's web gui. You can then save a single text file containing any scripts, passwords, ssids, etc. etc. you don't want to type again. Then flash to the new version. If you end up needed to clear the settings, you can refer to the video + text file to do so.

    See the following for screencapture on linux. No idea about windows.

  3. Xero5

    Xero5 Serious Server Member

    You don't have to, but it's suggested. You always run risks of running into quirks with mismatched settings. Try updating. And if you are having problems, you can always reset the NVRAM later.

    Also, if your router is running well, you do not have to update it for every release. Unless the latest build has a bug fix or a new feature you need.
  4. jerrm

    jerrm Network Guru Member

    I have never subscribed to the always erase nvram dogma, it's wasted effort 98% of the time.

    I never erase when going between recent releases of the same developer, unless I see something in the changelog or git to make me think it might be necessary.

    That said, if issues pop up after an upgrade, I don't immediately jump to an erase, but it is pretty high up on the list.

    I will erase when moving between developers.
  5. Inkrypted

    Inkrypted Serious Server Member

    I agree with jerrm for the most part unless you are switching versions or branches. If you are upgrading from Shibby VPN version to Shibby BT version or switching from Shibby to Toastman firmware that I say yes you should but if you are just upgrading to the latest version I don't believe it's necessary.
  6. koitsu

    koitsu Network Guru Member

    I should add a footnote clarification point here:

    While the advice given above is "generally okay", meaning "most of the time" it works, if you want to be pedantic you should do a an NVRAM reset after every single firmware update, including between minor versions of the same build/release (e.g. 1.28.0502.2 to 1.28.0502.8) and not just changing builds (e.g. Toastman to Shibby, etc.). Naturally if you change between firmwares (e.g. DDWRT to Tomato) you will need to do such -- I think we all know this one by now.

    The reasoning behind doing an NVRAM clear every time: the ChangeLogs for individual Tomato builds are not as thorough/verbose as one might hope. More specifically: the syntax of an NVRAM variable values could change between builds, and there is absolutely no guarantee that the individual who did the code will retain backwards-compatibility. If you were to upgrade to such a firmware, you might find that some feature relying on that NVRAM variable (and you'd have no idea what used it without looking at the code itself) began to act wonky/oddly or possibly something may even crash. Blindly assuming that the variables syntaxes won't change is a bad habit to get into. Only "key" (important) NVRAM variables are considered untouchable when it comes to their syntax (i.e. changing their syntax could result in the CFE or bootstraps not working correctly, potentially bricking the device, or possibly breaking the switching fabric (so even wired connections might not work)).

    Likewise, there may be NVRAM variables that get deprecated/become unused between releases. A "thorough" NVRAM erase/clear/reset is needed in this case -- unless you know the exact variable name which can be removed (using nvram unset followed by nvram commit).

    Another common issue -- and this has bit many people on this forum, from what I've read -- is that sometimes the statistics gathering bits (cstats and some other one -- I forget what it's called) change the syntaxes of their NVRAM variable values. The end result are statistics that are skewed/broken, or a router that may reboot or act oddly when using those features. It's come up on the forum more than once or twice. So if you use the IP Traffic, Web Usage, or Bandwidth features and don't save the data to a USB flash drive or CIFS share or some other external source and you choose to store it in NVRAM (not the same as RAM!), you should really be doing the Right Thing(tm) every time (back up your data from those two things before doing the upgrade, and restore the data as well).

    My point: there's no guarantee that any of the firmware maintainers will document these changes thoroughly/clearly, not to mention the user of the firmware might not even read the release notes/ChangeLog in the first place (this is incredibly common -- caveat emptor). All in all, it's up to each individual to decide if they want to erase the NVRAM as a precautionary step after every upgrade. If you're the type who would rather erase it only if you think something may be awry, then that's fine. If you're the type who wants to ensure everything works every time, then erase it after every upgrade.

    And finally, I need to be clear about one thing: when going between firmware versions, you should not use the Administration -> Configuration -> Backup Configuration / Restore Configuration features. This is unintuitive, I know. The reason has to do with how the configuration backup works -- it will actually back up all the NVRAM variables, and does not do any kind of "migration" when restoring. So, in the case an NVRAM variable gets deprecated/becomes unused, a Restore Configuration will re-add that variable to NVRAM. The solution for this to keep a text file or some other documentation around that outlines every single GUI setting you tweak/change from the defaults. I've attached an example of what I use to give folks an idea; just a simple text file.

    I guess the short version of the last paragraph is: these firmwares are mostly WIP (Work In Progress), so things may change/get removed/etc. as needed. The main "issue" is that these changes are not well-documented or announced to the community/end users in an effective way, so without an NVRAM erase you could potentially be playing Russian roulette. How one chooses to deal with this is their own choice, and all options/choices are perfectly okay.

    Attached Files:

    SavageCore, Joe A, cobrax2 and 4 others like this.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice