Pain is a relative thing, so for some people spending 2-3 days tinkering with FreeNAS after an upgrade might not actually feel that painless, but in the grand scheme of things, it probably took less time than I was expecting before I started.
I should probably break this down into at least 2 parts, as the upgrade itself – from 9.10.1-U1 to 11.1-U4 – was pretty painless. It only took about 40 minutes, and whilst that was slightly longer than I expected and a cause for mild concern, most of that time was the server rebooting a couple of times. When it finally came back up, the good news was that everything appeared to be working exactly as it had been before, so:
- my storage was available (the most important thing after an update!)
- my warden jails all started up and worked
- my iohyve/bhyve virtual machine running Ubuntu 16.4 for CrashPlan and Docker started up and worked
- my share appeared to work (although more on that later)
- replication to my 2nd FreeNAS box all looked good, even though that was still on 9.10.1
So from a pure upgrade perspective, it couldn’t really have been any less painless? The main reason for upgrading, other than being quite a long way behind on 9.10.1-U1 (which was approaching 12 months old) was the change to the jail management tool. Before 11.x, jails were created using Warden. I have several jails spanning several years created across the various version of FreeNAS (9.3, 9.3.1 and 9.10.1). Each version of FreeNAS uses a FreeBSD kernel, and when Warden creates a jail this release of FreeBSD is locked into the jail and cannot be upgraded. Even when FreeNAS is updated, the jail remains locked in time which eventually starts to create issues, especially once the FreeBSD release goes end of life (EOL)
To give you some idea of my setup, here’s a table which should make things clearer:
|ownCloud||10.0.4||9.3||9.3||FreeBSD 9.3 was EOL sometime last year. It was still possible to update ownCloud manually until earlier this year where an update required a newer version of OpenSSL which can no longer be updated in the jail. This jail can be updated no further|
|Plex||1.7.5||9.3||9.3||This is actually switched off now, as I’ve been using emby for the past 7-8 months, but couldn’t be updated if I wanted to|
|Calibre||2.x||9.3||9.3||I haven’t updated this since I created the jail, but again couldn’t even if I wanted to (which now I have, I realised I should have wanted to!)|
|WordPress||4.9.5||9.10.1||10.3||I created a new WordPress jail running 10.3 when I upgraded from 9.3.1, and I still have the old one running on FreeBSD 9.3. The WordPress updater allows both to be updated, although the security on the old one is somewhat lacking as the jail can’t be updated (10.3 went EOL in Apr-18, so whilst it can still be updated, it won’t be long before issues arise)|
|emby||184.108.40.206||9.10.1||10.3||I was on 9.10.1 when I switched to emby, so this is still a working jail although it was created manually from the ports tree and I suspect it won’t be too long before this stops being updated|
|unbound||1.6.7||9.10.1||10.3||Like the WordPress jail, I rebuilt this when I upgraded to 9.10.1. I rarely update and it’s very quick and easy to rebuild|
|openvpn||2.4.2||9.10.1||10.3||This was another rebuilt on 9.10.1, but it’s much more of a ball-ache than the unbound DNS server. This was the one giving me the most concern after upgrading to 11.1 (and rightly so, see below…)|
|Nginx Proxy||9.10.1||10.3||This was set-up and created in 9.10.1 so can still be updated, which I do occasionally to get the latest version of certbot. Again, how long this would have continued is in the hands of the ports tree gods!|
I still had a couple of jails running VirtualBox (which works in 9.10.1-U1, but not beyond that) but I’d pretty much replaced their use with iohyve/bhyve so wasn’t concerned about these, and I’ve already deleted them. I also had a couple of FreeBSD jails (mainly created in 9.3) that I’ve replaced through Docker containers, so again I wasn’t concerned about these.
Anyway, as I said above, these all started up in 11.1-U4 allowing me plenty of time to migrate them to the new jail management system, iocage (not to be confused with the VM hypervisor manager iohyve, although the CLI syntax is similar, which is nice!)
So what’s so good about iocage? iocage allows you to choose which release of FreeBSD you want to create the jail with, and also allows this to be upgraded (and even downgraded I think?) and is almost independent of the version of FreeNAS running. This is a big thing and should mean that the new jails I build using iocage won’t ever need to be rebuilt again when I upgrade FreeNAS as I can just upgrade the jails, at the required time and not necessarily at the same time as FreeNAS.
So after a short 40-minute upgrade, the main effort was going to be rebuilding the jails using iocage. I’ve decided to write another blog about that experience here.
Now I’ve been using for a good few days, everything is remarkably stable and I have very few issues. Replication worked fine with both the old periodic snapshots and new ones I’ve added. This is with freenas2 still on 9.10.1-U4, which I’ll need to upgrade at some point. The only real issue I’m having is the AFP share, which seems to drop-out far more often than it did on the previous version. Restarting the AFP service fixes the issue (but I’ve done that more times than I’d really like these last few days) and allows Time Machine to continue backing up, but otherwise, I haven’t found many issues.
So pretty much a Painless FreeNAS Upgrade 🙂