While there aren’t as many shiny new knobs to test out this release cycle, one thing is for certain: bugs are being uncovered and killed at an alarming rate. Recently, the team has been on a crusade to avenge fallen systems out in the field with the aid of our Redmine bug tracker.  There’s actually too much to cover here so instead I’ll give you a brief rundown on what my experience was updating FreeNAS 8.2.0 to 9.2.1.

Updating: The Good, The Bad, and the Bugly

There’s a number of reasons why one should update their FreeNAS, however, there are plenty of reasonable fears attributed with updating. Oftentimes, one finds themself in this predicament: should I stay, or should I go?
The answer is: GO update, right now!  It’s good for you and it’s good for your data.  You will not lose your pool, files, or anything like that.  You run the risk of losing some configurations for things like jails and plugins, but you enjoyed setting all of that up the first time around, didn’t you? I know I sure did. And now that I’ve grabbed your attention with some passive-aggressive deadpan wit, let us begin…

How to safely update FreeNAS 8.x to 9.x

I was approached by a co-worker who was still running FreeNAS 8.2.0 on his FreeNAS Mini about updating to 9.2.1, and what the implications of that were. It’s pretty easy to do and mostly safe. Just download the 8.3.1 GUI update txz as well as the one for 9.2.1, then go from 8.x to 8.3.1, then reboot and do the same for 9.2.1. Note: Your IP may change after your first (or second) reboot.
After updating you’ll notice that plugins are each installed into their own jail.  In 8.x all plugins were installed into a single jail. This makes updating plugins challenging, so first things first: back that NAS up.
Thankfully, FreeNAS has an easy button for backing up the web user interface config. What FreeNAS doesn’t have is an easy button for backing up plugin configs or updating old plugins, so here’s what I did:

1. Dropped into a shell and ssh’d into FreeNAS
2. Ran the “jls” command to get a list of jails
3. Ran “jexec plugin_jail csh” to drop into the plugin jail
4. Tar’d up all installed plugins by running: “tar cfv plugins_YYYYMMDD.tar /usr/pbi/”
5. SCP’d the tarball down from FreeNAS onto my local machine
6. Extracted the tarball and then poked around looking for config files using “find . -name “*.ini* -print”
7. Copied the config files located in the “data/” directory in each plugin onto my desktop
8. Removed all plugins from the FreeNAS UI
9. Reinstalled plugins, now available with a slightly different UI
10. Located the new directory for config files: /usr/pbi/pluginName/etc/pluginName/ (no longer found in ‘data/’)
11. Copied each config file to the right place and toggled each plugin on/off

Those 11 “easy steps” are not very easy and at times it was even frustrating (especially when the IP decided to change after an update/reboot, but I digress). For some unknown reason, installing plugins and removing them repeatedly while several hundred miles away from the physical location of the box made things increasingly more lulzy. For instance, sometimes the UI would just hang there while a plugin was installing, meanwhile my ssh session times out and then stops responding. It eventually came back (a few minutes later) each time this happened, except for the last time where it took out my co-workers entire home network. Upon reboot things were back to normal, so I suspect it was a simple IP conflict.  Users of plugins will want to be sure to check all the IP’s in-use on their networks before updating.

But why should I?

Because it’ll make the universe whole and restore peace back to the galaxy. Actually, that’s not true, but it’s probably a good idea to update if you’d like a more stable FreeNAS than ever before with the added bonus of all the amazing work that went into closing all those bugs.  It’ll be painful, but much like life: nothing good comes easy, but if it does, take it!
James Nixon
Webmaster