Update from 11.2-U7 to 11.3 Release on my Threadripper wasn't straigt forward.
Freenas was installed on a SSD and has been running fine with 11.2-U7 for 59 days 22 hr and 1 minutes or so. I then changed train to the 11.3 Release, downloaded the config file and then updated. Upon rebooting it crashed with "Cannot Load Kernel" error message.
I was stuck. I couldn't even revert back to the previous boot environment as it couldn't proceed to the Freenas CLI logo.
I salvage the install from my backup system which had laready been through with the update to 11.3 Release as I was on RC2 at the time.
I used the SSD on my Threadripper which booted without issue but the backup config was loaded instead.
Once I was able to access GUI, I cloned the boot environment and made it active. I rebooted and then once in GUI again I uploaded the config.
After a while, my encrypted volume was online but iocage where not showing in the list. So I rebooted, loaded previous 11.2-U7 that was used on the backup system, cloned, rebooted and then uploaded the config file. Everything was working as it was prior to the update to 11.3-Release.
I then went to update the train to 11.3-Release and the procedure went smoothly this time.
I noticed a peculiar thing, though. in both attempts, when I tried to access the content of the jails through GUI or CLI using "iocage list" nothing showed up and the command was still unresponsive.
I decided to wait as the system seemed to be operational. I waited and then I saw the fails starting to get populated. All of them where in the OFF state.
I waited as this is a similar behavior I had on my backup and after a few more minutes the jails started turning back on.
All the jails that were in the ON state before the update have retained their status after the update so it is good. They are all functional it seems, but on this system, when I do a clean reboot, the iocage jails are going to be up and running only 15 minutes later.
Also, when I do "iocage list" from CLI, it takes about 30 seconds for the list to be populated. This was never the case prior to the update. It used to be nearly instantaneous.
Performing "iocage console jailname" also takes a moment.
Last, and this as been happening on my backup system as well, when I perform a shutdown from the GUI, I am being asked to confirm and only when I do will the system shutdown or restart, once reboot or shutdown is underway, the Web interface (Firefox in my case) show the
https://IP/UI/Shutdown" page.
When the system has rebooted, the page is still present and if I refresh the page, the system will shutdown once more, and thus without confirmation dialog. The reboot will happen in the background without information being fed back to the user, unless the content of the CLI screen is being looked at. Even then, there is no indication the system is going down until GELI information are popping up.
I spent about 2 hrs working those issues, now system is up and running, but this shouldn't have been the case in the first place.
I am not really impressed with the quality of update process.