At home I’ve got a NAS-system that I’ve built myself in 2017. It’s really stable and is working great now since 7 years back, never had any problems.
It’s running FreeNAS-9.10.2-U2 (e1497f2) so I feel that I really should check out if/how I can upgrade it to a good, modern version.
In the FreeNAS web interface there is a page/tab “Update”, but unfortunately it doesn’t work since FreeNAS 9.10 is really old at this time.
I get the message: “Update server could not be reached HTTP. Error 308: Permanent Redirect”
Some additional information: My usage of this NAS-system is pretty basic. I only use it to serve storage through NFS, plus a jail running rtorrent+rutorrent.
The main storage is just two HDDs in RAID1, one volume and a few datasets. It’s below 80% full with 1.5TB free space.
Another question: Does newer TrueNAS-versions have higher demand on the boot drive?
I’m using two usb-drives. It was a popular practice back in ~2017 with FreeNAS 9.10
That results in this error message: Error: Failed to apply update Command '['/usr/local/bin/freenas-update', '-C', u'/var/tmp/firmware', 'update']' returned non-zero exit status 1
Second attempt I tried was updating from terminal with these commands:
cd /var/tmp
wget https://archive.freenas.org/9.10/STABLE/9.10.2-U6/FreeNAS-9.10.2-U6-manual-update.tar
freenas-update FreeNAS-9.10.2-U6-manual-update.tar
The freenas-update command produces no output to terminal at all.
The next thing I will try is upgrading using a bootable usb-stick. As I understand the documentation it should be no problem to leapfrog directly to v11.1-U7 or v11.2-U8.
Not more so than 9.3 and 9.10. It was indeed a popular option, though by 2017 it had fallen quite a bit out of favor already. USB flash drives, typically, are just too unreliable and/or age too terribly performance-wise.
Not inherently a limitation, but the most obvious issue you’re likely to run into is that updates take forever (over an hour in some cases).
Ok, I have now updated by using bootable usb-stick.
I first updated to 11.1-U7 which went great, no issues or any warnings at all.
Next I updated to FreeNAS-11.2-U8, the update process went pretty well but I did get one weirdness:
During the reboot / “conversion configuration database” the process hanged at this step for a long time: middlewared: setting up plugins (alert) [15/17]
Eventually it continued after some timeout limit was reached (240 seconds I think) and displayed a really serious-looking warning
middlewared did not start correctly
I get no warnings or anything in the web interface, everything looks good there. Should I examine the system closer and if there’s any issues?
My priority now is to setup a new rtorrent+rutorrent iocage jail…
I wonder how much work it will be, package repositories does not seem to be available, so I will have to install everything by building from source…?
An issue I’m facing is that in FreeNAS 11.2-U8 I cannot create jails, because the web interface gives me no option for (FreeBSD) “Release”. (I am of course using the new interface, not the legacy one)
I solved the issue with that I had no option for “Release” in jail creation. I had to run the iocage fetch-command manually like this: iocage fetch --root-dir /pub/FreeBSD-Archive/old-releases/amd64/ --server ftp-archive.freebsd.org
My machine is currently running FreeNAS 11.2. I would like to continue updating to 11.3 but I have an old jail from v9.10 that I really would like to keep and continue using. But v11.3 drops support for the old pre-iocage jails (atleast in the WebUI…)
I have done some examining, and the jail command-line utilities are available in later versions of Free/Truenas. Even TrueNAS 13.0 includes these commands (maybe not really surprising since I guess they’re part of the base operating system)
So I am thinking of updating to 11.3 and managing this old jail from the command line. (I only need to stop/start it)
If I run into problem I can go back to booting 11.2
Any thoughts on how viable it is to keep around an old jail in 11.3 that’s only “supposed” to support iocage jails?
Since FreeBSD 11 is EOL since 2020 you cannot create new jails with FreeBSD 11. You need to run a supported release on your host first. That would be TrueNAS 13.3 with FreeBSD 13.3.
Then you can create a new iocage jail and manually migrate your application. The time window for a seamless migration from warden to iocage is long gone …
I discovered that there is a tool included in FreeNAS for migrating warden jails to iocage, migrate_warden.py .
I want to test this in a FreeNAS virtual machine before doing it on my real system, that means I also need to create a warden jail.
Creating a warden jail is not exactly an easy task in 2024, but eventually I found out and solved how to do that:
I have used the migrate_warden.py script and migrated my old jail created in FreeNAS 9.10 (FreeBSD 10.3-RELEASE).
The new iocage jail fails to start. There seems to be an issue with configuring network / DHCP at startup. If I disable so that the jail will not have a network connection then the jail can start.
Failed startup:
iocage start rtorrent_jail
* Starting rtorrent_jail
+ Started OK
+ Configuring VNET OK
ifconfig: illegal option -- f
usage: ifconfig [-L] [-C] [-g groupname] interface address_family [address [dest_address]]
[parameters]
ifconfig interface create
ifconfig -a [-L] [-C] [-g groupname] [-d] [-m] [-u] [-v] [address_family]
ifconfig -l [-d] [-u] [address_family]
ifconfig [-L] [-C] [-g groupname] [-d] [-m] [-u] [-v]
Traceback (most recent call last):
File "/usr/local/bin/iocage", line 10, in <module>
sys.exit(cli())
File "/usr/local/lib/python3.6/site-packages/click/core.py", line 722, in __call__
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.6/site-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.6/site-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.6/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/iocage_cli/start.py", line 54, in cli
ioc.IOCage(jail=jail, rc=rc).start()
File "/usr/local/lib/python3.6/site-packages/iocage_lib/iocage.py", line 1641, in start
callback=self.callback
File "/usr/local/lib/python3.6/site-packages/iocage_lib/ioc_start.py", line 67, in __init__
self.__start_jail__()
File "/usr/local/lib/python3.6/site-packages/iocage_lib/ioc_start.py", line 467, in __start_jail__
"message": " + Acquiring DHCP address: FAILED,"
UnboundLocalError: local variable 'addr' referenced before assignment
Example of successful startup:
iocage start testjail
* Starting testjail
+ Started OK
+ Configuring VNET OK
+ DHCP Address: 192.168.1.115/24
+ Starting services OK
I have found some mentions of this problem (or something very similar) on the internet:
